| 00:03.08 | *** join/#maemo-ssu MrPingu (~MrPingute@86.92.226.97) |
| 00:28.54 | *** join/#maemo-ssu arcean (~arcean@aacy22.neoplus.adsl.tpnet.pl) |
| 01:11.21 | *** join/#maemo-ssu joshgillies (~josh@124-171-115-220.dyn.iinet.net.au) |
| 02:05.00 | *** join/#maemo-ssu joshgillies (~josh@124-171-115-220.dyn.iinet.net.au) |
| 02:12.59 | *** join/#maemo-ssu Jade (~jade@Jade.broker.freenet6.net) |
| 02:12.59 | *** join/#maemo-ssu Jade (~jade@unaffiliated/jade) |
| 02:47.14 | *** join/#maemo-ssu jon_y_ (~enforcer@2002:af8e:2a52::af8e:2a52) |
| 03:29.21 | *** join/#maemo-ssu AndrewX192 (~andrew@131.191.23.122) |
| 03:29.21 | *** join/#maemo-ssu AndrewX192 (~andrew@unaffiliated/andrewx192) |
| 03:54.43 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 04:04.09 | *** join/#maemo-ssu DocScrutinizer06 (~HaleBopp@openmoko/engineers/joerg) |
| 05:14.22 | *** join/#maemo-ssu jon_y (~enforcer@2002:af8e:2a52::af8e:2a52) |
| 05:47.12 | jon_y | freemangordon: is the formatting correct? http://paste.debian.net/219994/ |
| 05:48.17 | jon_y | this should really be done with Perl reporting :) |
| 06:52.29 | *** join/#maemo-ssu zogg__ (~zoggrules@bzq-109-64-186-173.red.bezeqint.net) |
| 07:31.56 | *** join/#maemo-ssu kolp (~quassel@212.255.19.228) |
| 08:10.55 | *** join/#maemo-ssu joshgillies (~josh@124-171-115-220.dyn.iinet.net.au) |
| 08:24.35 | *** join/#maemo-ssu luf (~luf@ip-89-102-208-114.net.upcbroadband.cz) |
| 08:24.46 | jon_y | anybody has the source for kp52? |
| 08:36.35 | merlin1991 | jon_y: Pali has ;) |
| 08:37.23 | merlin1991 | jon_y: or you go here: https://garage.maemo.org/plugins/ggit/browse.php/?p=kernel-power |
| 08:37.29 | jon_y | merlin1991: I just got it via git |
| 08:37.40 | jon_y | and now I'm wondering how to build it |
| 08:37.42 | merlin1991 | so I'm too late :D |
| 08:37.58 | merlin1991 | dpkg-buildpackage -rfakeroot -us -uc (inside scratchbox) ? |
| 08:38.16 | jon_y | I'm using a plain cross compiler |
| 08:38.25 | merlin1991 | uh oh |
| 08:38.27 | jon_y | pali says he did not use scratchbox |
| 08:38.42 | jon_y | so I went and put up a VM for that :) |
| 08:39.07 | merlin1991 | hm well you can probably run the makescript |
| 08:39.32 | jon_y | no make script, I think it uses dpkg |
| 08:39.48 | jon_y | well, I wonder if dpkg-cross can come in and help |
| 08:40.06 | merlin1991 | oh it has a makescript |
| 08:40.18 | merlin1991 | just look it up in debian/rules ;) |
| 08:40.30 | merlin1991 | bah this git clone takes forever |
| 08:40.45 | jon_y | make -f debian/rules?? |
| 08:40.51 | merlin1991 | nah |
| 08:40.56 | jon_y | ah wait, I'll just look in it |
| 08:41.06 | merlin1991 | yep, and find the build call in there :) |
| 08:41.46 | jon_y | ok, found it, now to guess where the working directory should be |
| 08:43.47 | jon_y | merlin1991: where do you run dpkg-buildpackage at? |
| 08:44.11 | merlin1991 | that is run at the level where the debian folder ist |
| 08:44.26 | merlin1991 | s/ist/is inside/ |
| 08:44.38 | jon_y | ok |
| 08:47.27 | merlin1991 | but the rules file builds in kernel-power-2.6.28/debian/build/kernel-power/ |
| 08:48.43 | jon_y | ? |
| 08:49.53 | merlin1991 | well the debian/rules dls original maemo kernel (with wget), extracts it into said folder |
| 08:50.00 | merlin1991 | applies patches and then runs make in there |
| 08:50.11 | jon_y | looks like I really do need scratchbox |
| 08:50.20 | merlin1991 | nah you can do pretty much the same thing |
| 08:50.33 | merlin1991 | just need to throw your cross compiler in instead of host gcc |
| 08:50.49 | jon_y | ok, I'll try that |
| 08:51.21 | merlin1991 | you're not going to get fancy .deb ofc :D |
| 08:51.25 | merlin1991 | just a proper zImage |
| 08:51.30 | *** join/#maemo-ssu dhbiker (~dhbiker@APN-122-252-216-gprs.simobil.net) |
| 08:51.31 | merlin1991 | (and modules) |
| 08:51.54 | jon_y | yes, I just need the zImage and modules |
| 08:52.14 | jon_y | I thought it was as simple as make menuconfig && make |
| 08:52.31 | jon_y | now to figure out how to apply the patches |
| 08:53.07 | merlin1991 | quilt |
| 08:53.53 | jon_y | ok, installing that too |
| 08:54.14 | merlin1991 | it's that line from debian/rules: cd $(KSRC) && ( QUILT_PATCHES=$(CURDIR)/debian/patches quilt push -a -q || test $$? = 2 ) |
| 08:54.44 | jon_y | ok, will do that |
| 08:56.33 | jon_y | I was under the impression the quilt was deprecated |
| 08:57.43 | merlin1991 | look at the version of debhelper maemo is using (5) |
| 08:57.55 | merlin1991 | there's loads of old cruft in various maemo packages .D |
| 08:58.19 | merlin1991 | current debian-testing is using debhelper 9 :D |
| 08:59.08 | jon_y | so stable it is stagnant |
| 08:59.15 | luf | merlin1991: is the libxml2 dsc file in cssu devel? |
| 08:59.24 | luf | merlin1991: or where can I find it? |
| 08:59.38 | merlin1991 | libxml2 dsc file for which version |
| 08:59.49 | luf | latest cssu (from gitorious) |
| 08:59.50 | jon_y | well, at work, my company uses kernel 2.6.12 <- that is the most bleeding edge :) |
| 09:00.13 | merlin1991 | I'm soon going to see what kernel I'll have to base my userspace stuff I'll be doing at work |
| 09:00.20 | merlin1991 | I bet it's in the 2.6.* range aswell |
| 09:00.56 | merlin1991 | btw luf why do you need the .dsc? |
| 09:01.41 | luf | merlin1991: I need to patch libxml2 and I want to rebuild the package. |
| 09:02.05 | merlin1991 | luf: it's here: http://repository.maemo.org/community-testing/pool/fremantle/free/libx/libxml2/ |
| 09:02.13 | luf | thx |
| 09:02.21 | merlin1991 | but why don't you simply clone the git repo? |
| 09:02.42 | jon_y | eek, where kernel config file |
| 09:02.50 | merlin1991 | rx51-something |
| 09:02.54 | merlin1991 | look it up in rules :D |
| 09:03.01 | merlin1991 | also sorry luf, there's only the debs |
| 09:03.02 | luf | merlin1991: I want dsc file not the .deb |
| 09:03.09 | merlin1991 | silly maemo repo is non standard layout |
| 09:03.11 | luf | I cloned the git. |
| 09:03.21 | merlin1991 | luf: you want http://repository.maemo.org/community-testing/pool/fremantle/free/source/libx/libxml2/ |
| 09:03.41 | luf | I think I need the dsc file to build the package (am I wrong?) |
| 09:04.16 | merlin1991 | nope |
| 09:04.24 | merlin1991 | you need the content of the debian/ folder |
| 09:04.43 | merlin1991 | more exactly you need at least debian/control debian/changelog and debian/rules |
| 09:04.56 | jon_y | readme mentions rx51power-defconfig |
| 09:05.05 | jon_y | can't find it :| |
| 09:05.11 | luf | merlin1991: I see. Hmmm next lesson for me :D |
| 09:05.34 | merlin1991 | jon_y: rules file has DEFCONFIG := rx51_defconfig |
| 09:05.41 | merlin1991 | and it's using that later on for the make calls |
| 09:06.01 | merlin1991 | or rather the make call (which prepares the source) |
| 09:06.45 | jon_y | ok |
| 09:07.41 | luf | merlin1991: I need this patch: http://git.gnome.org/browse/libxml2/commit/?id=a7e79f28689c574e0bbef17f4cb3da00249181ff |
| 09:08.12 | merlin1991 | luf: just as a general note, the dsc file has definite information on a specific version of a package, it says that packages build from $source with $version had a source consisting of $tar.gz and possible $diff.tar.gz with certain checksums |
| 09:09.15 | jon_y | what is this rx71 board? |
| 09:09.18 | merlin1991 | luf: you can either pull that branch into your repo and use git cherry-pick $commithash or you just redo what it does and reference the original |
| 09:09.37 | luf | merlin1991: I know but I thought that it's prerequisite (and I see it isn't). |
| 09:10.01 | luf | merlin1991: come on it's just 4 lines ... It's faster to write it :) |
| 09:10.13 | merlin1991 | hence the "or" section of my line ;) |
| 09:10.50 | merlin1991 | make commit msg of something like backported upstream commit a7e79f28689c574e0bbef17f4cb3da00249181ff |
| 09:11.14 | merlin1991 | maybe include that url aswell |
| 09:11.41 | merlin1991 | and as always test if shit explodes with the patch ;) |
| 09:12.47 | luf | merlin1991: sure the test are the first thing ... |
| 09:16.56 | jon_y | I wonder if selinux and friends will be useful on the n900 :) |
| 09:19.13 | luf | jon_y: I see no good reason for it. |
| 09:19.35 | luf | jon_y: in case of phone usage ;) |
| 09:21.15 | luf | Good zlib 1.2.7 is now working on my phone ... next step is to patch it with neon optimizations. |
| 09:24.31 | luf | merlin1991: how to create merge request on gitorious from my local git repo? |
| 09:25.01 | merlin1991 | you need to "clone" the repo on the webui, push your changes into the cloned repo and then use the webui again |
| 09:25.11 | luf | :( |
| 09:26.06 | luf | I suppose it's the preferred way for pushing changes into libxml2 ... |
| 09:31.47 | jon_y | hmm git checkout lists 2.6.28.10-power51r1 |
| 09:40.43 | luf | merlin1991: ok, I creted the merge request |
| 09:42.52 | luf | BTW I tested libxml2 with stock zlib and also newer zlib. |
| 09:45.12 | luf | merlin1991: I have dependency question :) |
| 09:46.57 | luf | libxml2 is depending on zlib and newer zlib crash older libxml2 ... I don't want to create cycle in dependency tree. Is there some way I don't see or have I to use also Depends: libxml2 (>= some_version) in zlib? |
| 09:49.32 | kerio | luf: no, Conflicts: libxml2 (<= some_version) |
| 09:49.45 | kerio | or, i suppose, (< some_version) |
| 09:49.55 | kerio | but to be fair, it should be in libxml2 |
| 09:50.28 | kerio | also, check every package listed in apt-cache rdepends libxml2 |
| 09:54.06 | kerio | gregoa: packaging help please - newer version of a package doesn't work properly with an older package it's depended upon - is it right to use Conflicts on the new package? |
| 09:55.24 | freemangordon | luf: did you find a wat to benchmark libpng? |
| 09:55.29 | freemangordon | *way |
| 09:59.43 | merlin1991 | luf: could you elaborate on what does not work with what? |
| 10:00.00 | merlin1991 | I'm not sure I got the whole newer older thing right in my head :D |
| 10:00.01 | luf | freemangordon: no I didn't :( |
| 10:00.41 | luf | merlin1991: (from zlib homepage) If you are using libxml version 2.7.6 or earlier, you will need to update libxml to version 2.7.7 or later before installing zlib version 1.2.4 or later. libxml 2.7.6 and earlier made unnecessary assumptions about the undocumented internal structure of zlib that were changed in zlib 1.2.4 and result in libxml crashing. This was fixed in libxml 2.7.7. |
| 10:01.24 | merlin1991 | which version of libxml do we ship? |
| 10:01.30 | luf | merlin1991: and the N900 ends in never ending boot loop when I upgrade just zlib (no widgets displayed and it reboots in few seconds after boot) |
| 10:01.43 | luf | libxml2-2.6.32... |
| 10:02.20 | merlin1991 | well then libxml needs a dependency on zlib <= something |
| 10:02.30 | merlin1991 | or a conflict on zlib >= 1.2.4 |
| 10:02.58 | merlin1991 | though I'd love to hear gregoa on what's the proper debian way |
| 10:03.09 | luf | merlin1991: I need to upgrade zlib but it's impossible with current libxml2. For sure I have to change something in zlib package. |
| 10:03.29 | merlin1991 | why do you need to upgrade zlib? |
| 10:04.31 | freemangordon | luf: yes, why? |
| 10:05.04 | luf | memleaks, some fixes and I want to use neon patches (from meego againist 1.2.7). |
| 10:05.06 | merlin1991 | the dependency system works the other way around, libxml needs zlib so any incompatabilities with zlib have to be modeled in libxmls control |
| 10:05.24 | freemangordon | luf: memleaks? link please |
| 10:05.59 | freemangordon | luf: BTW can't you just use harm zlib? |
| 10:06.26 | luf | what is harm zlib? do you mean from meego? |
| 10:06.30 | freemangordon | (I assume it already contains neon patches) |
| 10:06.37 | freemangordon | I mean from harmattan |
| 10:06.46 | freemangordon | harmattan != meego |
| 10:07.01 | luf | http://zlib.net/ChangeLog.txt: Changes in 1.2.4 (14 Mar 2010) - Fix memory leaks in gzclose_r() and gzclose_w(), file leak in gz_open() |
| 10:08.06 | freemangordon | harmattan is what runs on n9/50. meego is what runs nowhere |
| 10:08.19 | luf | where can I find harmattan zlib? |
| 10:08.29 | freemangordon | luf: are you sure those patches are not backported by nokia in fremantle zlib? |
| 10:09.22 | luf | I'm not sure. But what is the problem with libxml2 patch? |
| 10:10.29 | freemangordon | it is possible not only zlib depends on those internal functions |
| 10:11.01 | merlin1991 | freemangordon: other way around |
| 10:11.08 | freemangordon | aah, sorry |
| 10:11.21 | freemangordon | I am still having my first coffee for the day :D |
| 10:11.44 | merlin1991 | but we still could have $application crash suddenly because of this |
| 10:12.12 | luf | libxml older 2.7.7 depends on zlib internals what is wrong behaviour. |
| 10:12.31 | kerio | dammit, adding a conflict in zlib sucks :s |
| 10:12.38 | kerio | we don't really know it's the only package affected by this |
| 10:12.52 | freemangordon | luf: correct. but how to check if there isn't another lib/app doing the same? |
| 10:13.14 | kerio | freemangordon: check every package in apt-cache rdepends zlib |
| 10:13.28 | luf | Yes we can have application which failed because of change in obexd. |
| 10:13.52 | kerio | freemangordon: to be fair, it's a bug in libxml |
| 10:13.58 | luf | It's zlib internal which shouldn't be used at all. |
| 10:14.00 | kerio | and in every package that did that |
| 10:14.31 | freemangordon | ok, ok :D |
| 10:15.04 | freemangordon | luf: do we know those function names? |
| 10:15.32 | luf | freemangordon: I don't understand. Please rephase "those" |
| 10:16.24 | merlin1991 | he's asking if we know what changed, so we can look for the structure/function calls in other sw |
| 10:16.26 | freemangordon | the names of the internal function which libxml2 uses wrongly. we can grep for them in /usr/... |
| 10:16.34 | merlin1991 | jon_y: any luck building the kernel? |
| 10:16.59 | kerio | freemangordon: if it's a struct access, how can you fix that? |
| 10:17.11 | freemangordon | kerio: fix? |
| 10:17.35 | kerio | i assume you wanted to add some patches to zlib so that the old stuff still worked |
| 10:17.39 | freemangordon | no |
| 10:17.44 | freemangordon | you got me wrong |
| 10:18.08 | freemangordon | I want to check if there is other sw but libxml which is buggy |
| 10:18.56 | freemangordon | so we can either fix it (somehow) if it is FOSS or declare "we can't upgrade to newer zlib" if the sw in question is closed source |
| 10:19.15 | luf | http://pastebin.com/vAtHs08S |
| 10:19.20 | merlin1991 | or find nothing and be superhappy :D |
| 10:19.34 | kerio | freemangordon: can we really limit ourselves to check the reverse dependencies of zlib, though? |
| 10:20.03 | kerio | is there a way to check which libraries are referenced by binaries? |
| 10:20.06 | merlin1991 | kerio: fremangordon wants to grep over ALL the files |
| 10:20.11 | merlin1991 | not just stuff in dependencies |
| 10:20.11 | kerio | oic |
| 10:20.46 | luf | merlin1991, freemangordon: have you took a look into the patch? |
| 10:21.17 | merlin1991 | luf: you move too fast for me :D |
| 10:21.18 | freemangordon | luf: yes, but I don;t see a patch |
| 10:21.29 | freemangordon | merlin1991: you are slow :P |
| 10:22.07 | merlin1991 | freemangordon: http://gitorious.org/community-ssu/libxml2/merge_requests/1 |
| 10:22.09 | freemangordon | luf: which is the buggy code, the part with gzread/gzunwind? or gzdirect? |
| 10:22.25 | luf | else part is buggy. |
| 10:22.48 | luf | I think because of this: (z_stream *)context |
| 10:22.58 | freemangordon | ok, i'll greap for those function in /usr/lib and usr/bin |
| 10:23.34 | luf | gzread and gzunwind is ok |
| 10:23.45 | freemangordon | luf: I see |
| 10:23.49 | kerio | heh, pointer conversions |
| 10:24.06 | freemangordon | so we can;t really verify that |
| 10:26.09 | merlin1991 | which zlib version do we have? |
| 10:26.11 | luf | kerio: nearly everything is depending on zlib :D |
| 10:26.16 | kerio | yay! :D |
| 10:26.19 | luf | zlib-1.3.3 |
| 10:26.22 | luf | Sorry. |
| 10:26.27 | luf | zlib-1.2.3 |
| 10:26.27 | kerio | that means that making it faster will make everything faster! |
| 10:26.34 | freemangordon | for sure |
| 10:26.54 | freemangordon | yep, it is 1.2.3 |
| 10:27.04 | luf | Changes in 1.2.3 (18 July 2005) |
| 10:27.34 | merlin1991 | according to this bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=675207 1.2.3 is enough to apply the fix and be happy |
| 10:27.36 | povbot | Bug 675207: was not found. |
| 10:28.39 | freemangordon | hmm, seems to me that only libxml is abusing those |
| 10:29.37 | luf | yeah some zlib developer without enough coffee wrote that ... |
| 10:30.17 | merlin1991 | hm so where's the actual problem now? |
| 10:30.28 | merlin1991 | we apply that fix, then we are free to upgrade zlib to whatever we want |
| 10:30.47 | merlin1991 | luf: or does it bootloop even with the fix applied? |
| 10:31.06 | freemangordon | merlin1991: my concern was that there could be another piece of sw abusing zlib |
| 10:31.06 | luf | No bootloop after installing fixed libxml2. |
| 10:31.20 | freemangordon | it torns out it is onli libxml to do ti |
| 10:31.25 | freemangordon | *turns |
| 10:31.46 | merlin1991 | okay so let's fix libxml :) |
| 10:31.51 | freemangordon | is still having his first coffee |
| 10:32.17 | merlin1991 | so your not one of those people who down the whole first mug in a splitsecond? |
| 10:32.24 | merlin1991 | *you're* |
| 10:33.49 | freemangordon | it is double esspresso, I can't just drink it up |
| 10:33.53 | freemangordon | :D |
| 10:34.16 | luf | freemangordon: close your eyes and drink! :D |
| 10:34.19 | merlin1991 | well I don't drink coffee at all :P |
| 10:35.18 | freemangordon | merlin1991: bad decision. except if your health stops you |
| 10:35.41 | merlin1991 | hm why is it that bad? |
| 10:36.01 | merlin1991 | my reason not to drink it is the taste, I don't like it |
| 10:36.04 | merlin1991 | ducks |
| 10:38.21 | freemangordon | merlin1991: it contains a lot of good stuff. And I like the taste, I have mine without sugar :D:D:D |
| 10:38.54 | freemangordon | ok, lets try to find a way to benchmark libpng and zlib (when it is ready) |
| 10:39.05 | luf | freemangordon: drinking coffe is the same as drinking hot asphalt ... |
| 10:39.26 | freemangordon | never tried hot asphalt :P |
| 10:40.38 | freemangordon | DocScrutinizer05: please, step in and explain about the coffee :D:D:D |
| 10:40.47 | luf | freemangordon: no neon opts in harmattan code (https://build.pub.meego.com/package/files?package=zlib&project=home%3ACaCO3) or I'm unable to find right sources/git |
| 10:40.53 | kerio | ~coffee |
| 10:40.54 | infobot | it has been said that coffee is the reason the net exists, the drug of choice for a GNU generation, http://www.chez.com/emarsden/downloads/coffee.el, /usr/share/doc/HOWTO/en-html/mini/Coffee.html, geiseri's favorite beverage |
| 10:41.04 | freemangordon | kerio: thanks |
| 10:41.37 | freemangordon | hands kerio a cup of double esspresso, black as moonless night |
| 10:41.45 | luf | Another visit :( I have to leave now ... |
| 10:41.50 | luf | afk |
| 10:41.54 | merlin1991 | benchmarking zlib should be easy, stream fixed data through a really dumb programm and time that |
| 10:42.56 | freemangordon | merlin1991: does zlib has a binary? |
| 10:43.05 | freemangordon | *have |
| 10:43.11 | freemangordon | i mean executable |
| 10:43.16 | freemangordon | besides .so file |
| 10:43.50 | luf | gzip? |
| 10:43.52 | freemangordon | so we can pipe /dev/random | compress | uncompress | /dev/null |
| 10:44.15 | luf | or compress is better :) I always forget it. |
| 10:44.34 | merlin1991 | there's zlib-bin with "sample programs" according to the package description |
| 10:44.45 | luf | freemangordon: if /dev/random is fast enough (usually urandom is better) |
| 10:45.13 | merlin1991 | also you don't pipe random into a compression engine and the time that vs other random data |
| 10:45.15 | freemangordon | btw I doubt neon in zlib will make it bette, |
| 10:45.23 | freemangordon | *better |
| 10:45.31 | merlin1991 | you dd some random into a file and pipe that to both incarnations |
| 10:45.52 | freemangordon | pure ARM memcpy is faster than NEON optimized memcpy AFAIK |
| 10:46.22 | freemangordon | for small chunks that is |
| 10:52.19 | freemangordon | hmm, there is pngtest in libpng |
| 10:56.04 | freemangordon | yep, pngtest will do the job |
| 10:56.17 | freemangordon | merlin1991: do you still have stock device? |
| 10:56.31 | freemangordon | aah, scratch that, i'll use mine |
| 11:03.43 | *** join/#maemo-ssu dhbiker (~dhbiker@APN-123-28-99-gprs.simobil.net) |
| 11:06.07 | jon_y | merlin1991: yeah, build complete |
| 11:06.24 | jon_y | trying to figure out how to build the injection drivers |
| 11:06.29 | jon_y | or if I need it at all |
| 11:06.41 | kerio | freemangordon: have you ever played gyakuten saiban 3? |
| 11:06.56 | kerio | (phoenix wright: ace attorney - trials and tribulations) |
| 11:07.04 | freemangordon | NFC what that is |
| 11:07.20 | kerio | then this is going to be a bit less meaningful |
| 11:07.20 | kerio | https://www.youtube.com/watch?v=HMnrl0tmd3k |
| 11:08.04 | jon_y | kerio: that finger pointing game? :) |
| 11:08.18 | kerio | jon_y: >:C |
| 11:08.30 | kerio | one could say that i object to that classification |
| 11:08.48 | jon_y | :) |
| 11:08.59 | jon_y | I haven't actually played it, just seen screenshots of it |
| 11:09.26 | kerio | it's a really nice adventure game |
| 11:10.06 | jon_y | anybody know if the wireless inject modules are tied to a kernel version? |
| 11:11.05 | kerio | they're kernel modules, ofc they are |
| 11:11.18 | jon_y | I was wondering how to build them |
| 11:11.29 | jon_y | since Pali's git checkout has them empty |
| 11:11.33 | kerio | the version string has to match, or you can try forcing them to load but it's not guaranteed to not make everything asplode |
| 11:11.47 | jon_y | kernel and modules are already built |
| 11:12.07 | jon_y | just need the wireless injection drivers |
| 11:14.11 | freemangordon | luf: did you upload neon libpng .deb somewhere? |
| 11:19.48 | jon_y | any ideas where these files come from? compat-wireless-2.6.tar.bz2 compat.tar.bz2 wireless-testing.tar.bz2 |
| 11:19.53 | merlin1991 | jon_y: well the rules file extracts compat-wireless-2.6.tar.bz2 compat.tar.bz2 and wireless-testing.tar.bz2 then touches $(COMPAT_WIRELESS_TREE)/compat_version runs cd $(COMPAT_WIRELESS_TREE) && GIT_TREE=$(WIRELESS_TESTING_TREE) GIT_COMPAT_TREE=$(COMPAT_TREE) GIT_COMPAT_WIRELESS_TREE=$(COMPAT_WIRELESS_TREE) ./scripts/admin-update.sh and cd $(COMPAT_WIRELESS_TREE) && ./scripts/driver-select wl12xx |
| 11:20.09 | merlin1991 | and then builds with $(MAKE) -C $(COMPAT_WIRELESS_TREE) $(NJOBS) KLIB_BUILD=$(KSRC) |
| 11:20.10 | jon_y | hmm |
| 11:20.35 | jon_y | I can't find any script called admin-update.sh eitger |
| 11:20.38 | jon_y | *either |
| 11:20.52 | merlin1991 | it's in one of those tar.bz2s |
| 11:21.08 | jon_y | so, where are those files from? |
| 11:21.52 | merlin1991 | hm good question |
| 11:22.25 | merlin1991 | wl1251-maemo-source is a package |
| 11:22.28 | merlin1991 | prob contains them |
| 11:22.40 | merlin1991 | it's listed in the build depends of kernel-power |
| 11:22.54 | jon_y | getting it now |
| 11:28.12 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 11:29.22 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
| 11:34.50 | jon_y | merlin1991: yup it's in there |
| 11:36.44 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28112.dip0.t-ipconnect.de) |
| 11:50.54 | jon_y | huh, building the wireless modules will call modprobe |
| 11:51.00 | jon_y | I wonder what was it about |
| 12:02.14 | *** join/#maemo-ssu FIQ (~fiq@unaffiliated/fiq) |
| 12:18.58 | freemangordon | luf: http://pastebin.com/jFQGBX58 |
| 12:19.03 | freemangordon | does not look good |
| 12:19.21 | freemangordon | either my benchmark is flawed, or neon optimizes nothing |
| 12:25.19 | freemangordon | yes, it is my benchmark that sucks :( |
| 12:25.50 | ShadowJK | wouldn't really be surprised if there was no performance difference |
| 12:26.33 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
| 12:26.34 | freemangordon | too |
| 12:27.11 | ShadowJK | most of png cpu time would be in the entropy coding things, so basically in the equivalent of gzip |
| 12:42.42 | DocScrutinizer05 | I have a slight feeling of deja-vu |
| 12:43.22 | DocScrutinizer05 | optimizing ong, heard that before |
| 12:43.27 | DocScrutinizer05 | png that is |
| 12:43.50 | DocScrutinizer05 | with same results |
| 12:44.17 | DocScrutinizer05 | or I dream it up |
| 12:47.35 | freemangordon | damn, too much jitter :( |
| 12:50.28 | luf | freemangordon: I uploaded. _you_know_who/~luf/libpng |
| 12:50.58 | freemangordon | luf: BTW __ARM_NEON__ is nowhere defined ;) |
| 12:51.08 | luf | freemangordon: what's wrong with benchmark? |
| 12:51.18 | ShadowJK | jpeg would be interesting, the dct could benefit from a neon dct :) |
| 12:51.28 | freemangordon | I can't make a deffinitive conclusion |
| 12:51.59 | jon_y | when booting a new test kernel, it said something about modules.dep and then quickly rebooting |
| 12:52.02 | jon_y | any ideas? |
| 12:52.23 | freemangordon | build it in scratchbox/madde |
| 12:53.10 | jon_y | hmm ok |
| 12:53.36 | luf | freemangordon: why I'm able grep the function name in that case from .so? |
| 12:53.48 | luf | grep png_read_filter_row_neon .libs/libpng12.so.0.49.0 |
| 12:53.49 | luf | Binary file .libs/libpng12.so.0.49.0 matches |
| 12:55.52 | DocScrutinizer05 | jon_y: depmod ? |
| 12:57.13 | jon_y | DocScrutinizer05: ? |
| 12:57.32 | DocScrutinizer05 | iirc there's a nice cmd called depmod |
| 12:57.44 | DocScrutinizer05 | usually called like `depmod -a` |
| 12:57.56 | DocScrutinizer05 | it might be related |
| 12:58.05 | jon_y | depmod -a before booting the new kernel? |
| 12:58.13 | DocScrutinizer05 | man depmod |
| 12:59.52 | jon_y | ok, will try that |
| 13:01.13 | luf | freemangordon: I think the question is if the function png_read_filter_row is called in the benchmark. |
| 13:02.12 | freemangordon | luf: if it is not called for images in /usr/share/backgrounds, i'd say the patch is useless |
| 13:02.22 | freemangordon | but i bet it is called |
| 13:02.40 | *** join/#maemo-ssu arcean (~Arcean@aacy22.neoplus.adsl.tpnet.pl) |
| 13:07.56 | freemangordon | luf: I am doing another set of benchmarks, lets see |
| 13:10.28 | DocScrutinizer05 | coffee? just having my first one today :-) |
| 13:11.00 | jon_y | DocScrutinizer05: looks like it booted |
| 13:11.16 | jon_y | btw, does /lib/module/current need updating too? |
| 13:12.14 | DocScrutinizer05 | good question |
| 13:12.23 | DocScrutinizer05 | I think somebody nuked it |
| 13:12.41 | jon_y | it was complaining about symbol mismatches but loaded anyway |
| 13:12.41 | DocScrutinizer05 | (the semantics of this symlink that is) |
| 13:12.48 | jon_y | I thought it might be related |
| 13:13.14 | DocScrutinizer05 | well, did you build your modules for current kernel? |
| 13:14.00 | jon_y | yes, all the modules are rebuilt |
| 13:15.00 | DocScrutinizer05 | since multiboot (real multiboot, not the friggin package) /lib/module/current is kinda obsolete |
| 13:15.31 | DocScrutinizer05 | aiui all kernels directly refer to their /lib/modules/<version>/ |
| 13:15.34 | jon_y | is it related if I use u-boot? |
| 13:15.50 | DocScrutinizer05 | ask pali |
| 13:16.05 | jon_y | ok, will ask when he comes in |
| 13:19.12 | *** join/#maemo-ssu Martix (~martix@4.177.broadband3.iol.cz) |
| 13:23.23 | freemangordon | luf, ShadowJK: http://pastebin.com/yEep06UB |
| 13:23.36 | freemangordon | does not look good :( |
| 13:24.59 | freemangordon | luf: i used "gcc pngtest.c `pkg-config --cflags --libs libpng` -DPNGTEST_TIMING -o pngtest" for pngtest binary |
| 13:25.51 | freemangordon | still, that way of benchmarking could be totally wrong, but I can;t think of a better one |
| 13:26.24 | freemangordon | though it clearly shows gcc4.7.2 is better :D |
| 13:26.38 | luf | I'm trying to get results from callgrind but I'm not successful |
| 13:28.48 | freemangordon | luf: ofc it is up to you and merlin1991 to assess whether this neon patch makes any sense, having in mind it is not much tested. |
| 13:29.00 | freemangordon | TBH I was hoping for better results |
| 13:30.21 | DocScrutinizer05 | did you google for results of similar efforts some years back? |
| 13:31.13 | luf | DocScrutinizer05: they told 20-30% |
| 13:31.46 | DocScrutinizer05 | hmm, I have a feeling at best, of contrary results |
| 13:32.17 | DocScrutinizer05 | for the life of mine can't recall where and when I heard of png optimization |
| 13:32.20 | ShadowJK | For the specific function(s) or for decoding entire image? :) |
| 13:33.01 | luf | ShadowJK: http://lists.linaro.org/pipermail/linaro-multimedia/2011-September/000074.html - it should be enough even for the specific function ;) |
| 13:33.08 | DocScrutinizer05 | but I seem to have a record in a dark corner of my mind, that those efforts were basically futile |
| 13:33.20 | luf | DocScrutinizer05: it should be true. |
| 13:33.46 | luf | I'm just trying to find if it's called or not during benchmark. |
| 13:34.18 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
| 13:34.58 | ShadowJK | ah, Måns Rullgård :) |
| 13:35.00 | DocScrutinizer05 | it also reminds me of the glamo disaster |
| 13:35.21 | ShadowJK | Did he write the neon patch for libpng too? |
| 13:35.25 | luf | ShadowJK: ? |
| 13:35.35 | DocScrutinizer05 | which in fact might be related, at least for my cloudy memory |
| 13:35.41 | ShadowJK | The author of the email you linked |
| 13:35.45 | luf | freemangordon: can you try callgrind? |
| 13:36.06 | freemangordon | luf: what for? |
| 13:36.10 | luf | ShadowJK: I know but I think there should be some message behind the name? |
| 13:36.20 | luf | freemangordon: to see if the _neon is called. |
| 13:36.37 | freemangordon | luf: just put g_warning before calling that function, along with static counter |
| 13:36.49 | freemangordon | and you'll be fine ;) |
| 13:36.56 | luf | As you cen see in the last link I posted not all images is using the png_read_filter_row |
| 13:37.22 | luf | freemangordon: ok, I'll do it the hard way. Strange that callgrind is failing on my N900 ... |
| 13:37.23 | ShadowJK | luf; well I'm just seeing that he's saying "in principle" and making an assumption that the function could be sped up 4X? |
| 13:37.47 | luf | ShadowJK: It's not proove. It's just 26.12% pngbench pngbench [.] png_read_filter_row |
| 13:37.52 | DocScrutinizer05 | anyway, in all your evaluations don't forget about the overhead for setup you usually introduce. Often once you count that in, you don't need benchmarks to see it's useless since overheat outweighs the speed boost of the core |
| 13:38.14 | DocScrutinizer05 | overhead* |
| 13:38.18 | DocScrutinizer05 | not heat |
| 13:38.19 | luf | ShadowJK: and even more for the third image (however nearly nothing for the second image) |
| 13:38.53 | freemangordon | where is that pngbench? |
| 13:39.29 | luf | freemangordon: no idea. http://lists.linaro.org/pipermail/linaro-multimedia/2011-September/000074.html |
| 13:39.38 | freemangordon | :( |
| 13:40.03 | ShadowJK | luf; he estimated 4X for that function, if someone were to try optimize it. What happened later, did someone try to write optimized filter function, did they achieve mru's 4X guess? |
| 13:40.30 | freemangordon | ooh, is that my friend mru? |
| 13:40.43 | ShadowJK | mru is Måns, yes |
| 13:41.02 | luf | ShadowJK: I'm trying neon optimized patch for png_read_filter_row |
| 13:41.12 | freemangordon | aah, I see. well, i'll take everything he says with a grain of salt ;) |
| 13:41.37 | luf | ShadowJK: I didn't say it has to work ... just I'm trying. |
| 13:41.46 | freemangordon | luf: pngtest counts filter functions call counts |
| 13:42.05 | freemangordon | Filter 1 was used 102 times |
| 13:42.07 | freemangordon | Filter 2 was used 422 times |
| 13:42.09 | freemangordon | Filter 3 was used 206 times |
| 13:42.12 | freemangordon | Filter 4 was used 14 times |
| 13:42.17 | ShadowJK | I'd say that if he sys 4X is possible, it's only possible for a superhuman coder to reach 4X :) |
| 13:43.08 | freemangordon | ShadowJK: mru was the one ta say "no matter what you say about stable thumb2 on n900, I say it is impossible, period" :D |
| 13:43.18 | ShadowJK | lol |
| 13:43.38 | freemangordon | yeah, DocScrutinizer05 was on the same channel by that time, he can confirm |
| 13:43.45 | freemangordon | however |
| 13:44.13 | ShadowJK | He also doesn't actually use or program any CPU that more than 500 people have access to ;) |
| 13:44.24 | freemangordon | :D:D:D |
| 13:45.21 | DocScrutinizer05 | well, iirc he said "don't use it. period" |
| 13:45.28 | ShadowJK | And his thought process is proobably "why even bother with that stupid early buggy omap3 cpu, this omap5 is better in every way" |
| 13:45.31 | ShadowJK | :) |
| 13:45.36 | freemangordon | exactly |
| 13:46.02 | freemangordon | I was adviced o change the CPU :D:D:D |
| 13:46.07 | freemangordon | *to |
| 13:46.27 | DocScrutinizer05 | ShadowJK: +1 |
| 13:47.12 | freemangordon | is out for cigarettes |
| 13:47.24 | ShadowJK | He's actually discovered alot of the known hw bugs in omap hw too |
| 13:48.36 | DocScrutinizer05 | and maybe he doesn't like to see his "babies" getting smashed ;-D |
| 13:49.34 | ShadowJK | Might've actually been why nobody used omap4 much, he discovered the ram controller is so slow and bad, that two Cortex-A9 cores perform worse than a single Cortex-A8 core of omap3 |
| 13:50.06 | jon_y | DocScrutinizer05: new kernel killed the camera :( |
| 13:50.11 | DocScrutinizer05 | btw about OMAP bugs, did I tell about that non-public silicon error in omap4 WONTFIX, that causes IRQ misses? |
| 13:50.11 | jon_y | fcam won't load |
| 13:50.25 | jon_y | ah well, will try __BUG() some more |
| 13:51.10 | DocScrutinizer05 | jon_y: aiui it is like it ever been: new kernel renders fcam broken |
| 13:51.26 | DocScrutinizer05 | we've seen that with every single KP rev |
| 13:52.10 | jon_y | so, normally fcam comes with a new build per kp release? |
| 13:52.35 | DocScrutinizer05 | this IRQ detection flaw is a valid reason to not use OMAP4 |
| 13:52.35 | kerio | i think that kp ships the modules |
| 13:52.46 | jon_y | hmm |
| 13:52.50 | kerio | DocScrutinizer05: what do you mean by IRQ misses? |
| 13:52.51 | jon_y | kerio: really? |
| 13:53.04 | kerio | ~pkg |
| 13:53.04 | infobot | i heard pkg is http://maemo.org/packages/ |
| 13:53.21 | freemangordon | DocScrutinizer05: what? IRQ misses? |
| 13:53.32 | jon_y | kerio: I didn't see anything about fcam in the kernel build rules |
| 13:53.47 | DocScrutinizer05 | when e.g. OMAP4 is playing video with hw accel, it may miss hw-IRQ that's meant to wake up HSI interface to modem. ->result: you miss inbound calls |
| 13:53.57 | kerio | hm, apparently not, fcam just has to build a version for each KP release |
| 13:54.05 | freemangordon | great :D |
| 13:54.09 | DocScrutinizer05 | comment TI: will get fixed in OMAP5 |
| 13:54.18 | kerio | DocScrutinizer05: what the shit |
| 13:54.27 | jon_y | fcam is made of binary blobs? |
| 13:54.36 | kerio | jon_y: no, it's open |
| 13:54.56 | jon_y | ok, I'm trying to look for the modules |
| 13:55.00 | jon_y | *source |
| 13:55.30 | DocScrutinizer05 | "work-around" the peripherals have to send IRQ over and over again, hoping for it to eventually maybe take effect X-P |
| 13:56.35 | kerio | DocScrutinizer05: i seem to repeat myself, but what the shit |
| 13:57.12 | DocScrutinizer05 | a big modem chip manuf had at least 2 customers who blamed the modem chip to not go active when it should, it turned out it always been OMAP4 to not go active when modem asked for it |
| 13:59.41 | freemangordon | luf: you said you backported linaro libpng neon optimisation as well, ain't? |
| 14:01.29 | DocScrutinizer05 | ^^^ the "workaround" (c) TI |
| 14:02.23 | kerio | DocScrutinizer05: TI is just ahead of the game |
| 14:02.24 | DocScrutinizer05 | and of course you don't find THAT in any public SiErr-list |
| 14:02.27 | luf | So the neon filter is used ... but Filter cound doesn't correspond to the count ... |
| 14:02.30 | kerio | nobody really wants to answer calls anyway |
| 14:02.44 | kerio | it's a way to increase battery life and reduce annoyances! |
| 14:03.06 | freemangordon | luf: well, it seems this optimisation does not really optimize |
| 14:03.21 | freemangordon | luf: do you have linaro code backported? |
| 14:03.46 | luf | what is linaro code? from libpng upstraem? |
| 14:03.52 | freemangordon | i guess |
| 14:04.00 | freemangordon | https://launchpad.net/linaro-multimedia-project/+milestone/2011.10 |
| 14:04.06 | luf | What libpng are you using for non-neon? |
| 14:04.18 | freemangordon | luf: the same |
| 14:04.36 | luf | How you get it? |
| 14:04.42 | freemangordon | recompile |
| 14:05.05 | luf | So you used neon enabled both? Or how you disable the neon opts? |
| 14:05.21 | freemangordon | master branch on gitorious does not have __ARM_NEON__ defined |
| 14:05.36 | luf | Right. Ok. |
| 14:05.59 | freemangordon | so when I want neon, i add -D__ARM_NEON__ in debian/rules CFLAGS |
| 14:06.12 | luf | It's not needed. |
| 14:06.22 | luf | __ARM_NEON__ is defined somewhere else. |
| 14:06.31 | freemangordon | according to grep it is not |
| 14:06.51 | luf | Strange it is here ... |
| 14:06.56 | freemangordon | where? |
| 14:07.17 | kerio | "#ifdef __ARM_NEON__" "1 / 0;" "#endif" somewhere? |
| 14:07.22 | kerio | and then try to compile |
| 14:07.36 | freemangordon | kerio: been there,... |
| 14:07.42 | kerio | (is there a better way to cause a compilation failure?) |
| 14:07.45 | freemangordon | no |
| 14:07.47 | luf | I'm using SDK from nokia without thumb enabled and I don't need to define __ARM_NEON__ |
| 14:07.58 | luf | And regarding grep I have neon optimized code. |
| 14:08.20 | freemangordon | luf: you have neon function compiled, but it is not called |
| 14:08.29 | luf | It's called for sure. |
| 14:09.00 | freemangordon | luf: hmm, it could be this is compiler define |
| 14:09.23 | freemangordon | however, i used libpng from repos to test ARM only |
| 14:09.39 | freemangordon | and libpng from thumb repo to test -thumb |
| 14:10.04 | luf | ARM only from cssu-devel and neon opts from master. |
| 14:10.16 | luf | Ok. That's correct for sure. |
| 14:10.29 | freemangordon | ARM only - stock libpng, the one in nokia repo |
| 14:10.42 | freemangordon | still correct |
| 14:12.18 | freemangordon | luf: so, do you have upstream neon patches backported? |
| 14:12.24 | luf | can you test the one from cssu-devel? |
| 14:12.32 | freemangordon | ok |
| 14:12.33 | luf | freemangordon: No I don't have. |
| 14:14.07 | luf | freemangordon: BTW pngtest read and write the png so maybe the benchmark isn't very good for testing the read part ... |
| 14:14.38 | freemangordon | but it test read times, we can ignore write times |
| 14:14.43 | freemangordon | *tests |
| 14:19.42 | gregoa | kerio, merlin: in debian I would add "Breaks: libxml2 (<= 2.7.7)" to a newer zlib; but I don't know if the ancient packaging toolchain on maemo understands Breaks. Conflicts should do the same, more or less. |
| 14:20.09 | kerio | what's the difference between Breaks and Conflicts? |
| 14:21.10 | gregoa | kerio: http://www.debian.org/doc/debian-policy/ch-relationships.html 7.3 and 7.4 |
| 14:21.30 | freemangordon | iirc Breaks is supported |
| 14:22.58 | *** join/#maemo-ssu arcean_ (~Arcean@aacs56.neoplus.adsl.tpnet.pl) |
| 14:23.19 | kerio | ah yes, Breaks should be the case here |
| 14:23.32 | gregoa | ok, Breaks was added (in debian) to dpkg in 1.14.6 (2007) and we have 1.14.25maemo3+0m5 |
| 14:23.49 | kerio | the old libxml and the new zlib can coexist while the new libxml is installed |
| 14:24.11 | freemangordon | hmm, no |
| 14:24.21 | kerio | freemangordon: during the upgrade process |
| 14:25.26 | freemangordon | should be ok, yes |
| 14:25.42 | freemangordon | luf: CPU time used = 80.980 seconds (decoding 2.590, |
| 14:25.42 | freemangordon | encoding 78.260 , other 0.130 seconds) |
| 14:28.24 | luf | freemangordon: so it's quite same for decoding? |
| 14:28.37 | freemangordon | yep |
| 14:28.49 | DocScrutinizer05 | hey gregoa, long time no see! :-D |
| 14:29.01 | freemangordon | luf: going to try to backport linaro patch |
| 14:30.13 | gregoa | DocScrutinizer05: long time no packaging question :) besides that I'm always here |
| 14:30.20 | DocScrutinizer05 | :-D |
| 14:33.59 | DocScrutinizer05 | gregoa: you ever had a discerning look at the optional/alternative "specs" for CSSU? http://maemo.merlin1991.at/cssu/meetings/2012-05-14.txt |
| 14:34.17 | jon_y | ugh, fcam should really load by uname -a |
| 14:34.28 | DocScrutinizer05 | we could use any comments and help available on that |
| 14:34.59 | gregoa | DocScrutinizer05: not really. I vaguely remember the meeting but haven't thought about it further (and forget the details in the meantime) |
| 14:35.13 | gregoa | DocScrutinizer05: ok, tab open in my browser for reading later |
| 14:35.25 | DocScrutinizer05 | many thanks, much appreciated |
| 15:08.57 | luf | freemangordon: ping |
| 15:09.40 | luf | How to set the exact cpu speed for the CPU? |
| 15:14.48 | luf | I get it. |
| 15:15.25 | freemangordon | kernel-config lock 500 |
| 15:26.52 | luf | freemangordon: I have better results with comparing ARM versus NEON libpng ... |
| 15:27.15 | freemangordon | luf: link? |
| 15:27.35 | luf | ARM is in all test faster then the fastest NEON :D |
| 15:27.48 | freemangordon | :D:D:D |
| 15:27.50 | luf | I re-run it ten times for both. |
| 15:29.46 | luf | So ARM is around 5-20% faster againist NEON :D :D :D |
| 15:30.07 | luf | I don't want to backport the linaro part ... |
| 15:30.16 | luf | I don't think it'll be faster. |
| 15:31.13 | luf | OMG why I think that developers are testing their code before thay say it's faster ... |
| 15:31.46 | freemangordon | luf: I am packporting it |
| 15:31.54 | freemangordon | but it seems broken :( |
| 15:31.59 | luf | :D :D |
| 15:32.11 | freemangordon | actually I backported it |
| 15:32.20 | freemangordon | but pngtest fails :D:D:D |
| 15:32.43 | luf | Do you have some benchmark for zlib? I want to test zlib-1.2.3 versus zlib-1.2.7 |
| 15:32.48 | freemangordon | no |
| 15:33.27 | ShadowJK | mru said 6X before anyone had written any code, let alone tested it ;) |
| 15:35.15 | DocScrutinizer05 | coding is voodoo |
| 15:35.30 | DocScrutinizer05 | well, estimations on coding are, a lot |
| 15:36.04 | ShadowJK | vectorizing stuff is even more voodoo |
| 15:36.06 | DocScrutinizer05 | you never know what the final code will look like, or perform. Until it's finished and tested |
| 15:36.43 | ShadowJK | you take the mathematical algorithm, turn it inside out in 6 Dimensional space, then write the neon code for it |
| 15:37.12 | DocScrutinizer05 | and more often than not coders implement a 'smart' algo that looks great but does nasty things (e.g. re-instantiating objects in a loop) |
| 15:39.00 | DocScrutinizer05 | and generally overhead for setup of any runtime environment is neglected |
| 15:43.41 | DocScrutinizer05 | see glamo disaster. This critter *could* do pretty fast gfx operations, but only on max 512*512, and you need to pump all the data from CPU thru a terribly slow hw if to the glamo chip, and possibly results back via same way |
| 15:44.19 | DocScrutinizer05 | the hw results of genuine coder thinking |
| 15:44.41 | freemangordon | what worries me is that upstreamed neon code does not wokr :( |
| 15:44.46 | freemangordon | *work |
| 15:44.47 | luf | freemangordon: I can write even faster libpng with failed tests (just function which returns error) :D |
| 15:44.57 | DocScrutinizer05 | for NEON et al be prepared to face similar minor inconveniences |
| 15:44.59 | freemangordon | I know |
| 15:45.28 | freemangordon | DocScrutinizer05: not sure, that is suposed to result in the same bits |
| 15:47.06 | DocScrutinizer05 | I know on several processors it's not worth using the math coprocessor since setting up stuff there is slower than doing the same thing in software on the main processor, even in 16bit |
| 15:47.42 | freemangordon | aah, I see now, it is my fault |
| 15:47.58 | freemangordon | I need the memory aligned on 16byte boundary |
| 15:48.31 | luf | Yes .There is a #define for it ... |
| 15:48.40 | freemangordon | yep, i saw it |
| 15:48.47 | freemangordon | lets see if i can backport that |
| 15:49.07 | luf | It's quite easy. |
| 15:49.26 | luf | Just it reduced the buffer from 64 to 48 bit (as I understand) |
| 15:51.32 | DocScrutinizer05 | how is alignment reducing buffer sizes? |
| 15:52.23 | luf | DocScrutinizer05: alignment is also done by another thing. But in that part code is also used smaller buffer (in newer libpng). |
| 15:52.45 | freemangordon | luf: i don;t think it is that easy |
| 15:53.02 | freemangordon | if I read the code correct, we have 64 byte aligment in 1.2 |
| 15:53.03 | jon_y | welp, fcam drivers can kill a system boot |
| 15:53.18 | jon_y | switched back to stock kp for now |
| 15:53.47 | jon_y | apparently loaded at boot |
| 15:55.02 | jon_y | I'll need to also find out if uboot loads the previous kernel for act-dead |
| 15:55.12 | DocScrutinizer05 | jon_y: sure, camera-ui gets preloaded |
| 15:55.24 | DocScrutinizer05 | by dsme |
| 15:55.30 | jon_y | dsme? |
| 15:55.46 | DocScrutinizer05 | device state management entity, or whatever |
| 15:55.57 | DocScrutinizer05 | dsmetool --help |
| 15:56.10 | DocScrutinizer05 | ps|grep camera |
| 15:56.13 | jon_y | somehow fbcon showed up even after selecting stock kp52 for boot |
| 15:56.27 | jon_y | curse you incompatible symbols |
| 15:57.03 | DocScrutinizer05 | the joy of multiboot systems: each kernel needs its own modules |
| 15:57.29 | jon_y | the dumb thing about fcam is that it is not using uname -a |
| 15:57.31 | DocScrutinizer05 | #1 bootloop reason, by far |
| 15:57.39 | jon_y | it would be all cool if it did that |
| 15:58.11 | jon_y | it only had "vanilla" and "power" |
| 15:58.45 | jon_y | doesn't even say which kp version, but it is really for kp52 as now it is working again |
| 15:59.15 | jon_y | DocScrutinizer05: you see what I'm getting at? |
| 15:59.23 | *** join/#maemo-ssu dhbiker (~dhbiker@APN-122-226-198-gprs.simobil.net) |
| 16:00.25 | kerio | jon_y: so it just forcefully loads them? :s |
| 16:00.32 | jon_y | DocScrutinizer05: also, is the formatting OK? http://paste.debian.net/220113/ |
| 16:00.40 | kerio | also, uboot doesn't have any special coding for ACT_DEAD i think |
| 16:00.55 | jon_y | kerio: it would be easier to keep multiple kernels if it used uname |
| 16:01.08 | jon_y | right now it only has "vanilla" and "power" |
| 16:01.28 | kerio | yeah but the module for the "power" kernel can't be cleanly loaded on kp52 if it was compiled for kp51 |
| 16:01.32 | kerio | the version string is different |
| 16:01.39 | kerio | so it's loaded forcefully |
| 16:01.46 | jon_y | yes, this is the stupid part |
| 16:02.03 | jon_y | just use uname to keep them separate |
| 16:02.28 | kerio | you'd have to ship a shitton of modules |
| 16:02.54 | jon_y | kerio: just have the modules ship as part of the kernel or something |
| 16:03.06 | jon_y | like what kp does with wireless inject drivers |
| 16:03.23 | kerio | they were included with the fifty-first release of kernel-power |
| 16:03.26 | kerio | not before |
| 16:03.39 | jon_y | which is a good step |
| 16:03.59 | jon_y | on uboot, somehow the previous kernel was still loaded after selecting the boot entry |
| 16:04.03 | jon_y | fbcon! |
| 16:04.12 | kerio | wat |
| 16:04.16 | jon_y | no idea what was going on |
| 16:04.34 | kerio | hm, i wonder if it actually *does* have a way to handle ACT_DEAD mode in a sensible way |
| 16:04.35 | jon_y | kp52 does not have fbcon loaded by default, but it was showing all the console boot up messages |
| 16:05.00 | jon_y | my previous selection had fbcon builtin |
| 16:05.11 | jon_y | so no module loading there either |
| 16:05.30 | kerio | jon_y: didn't you add fbcon to /etc/modules? |
| 16:05.37 | jon_y | no, I removed them |
| 16:05.45 | kerio | are you suuure? |
| 16:06.01 | jon_y | yes, I couldn't get fbcon to show up reliably anyway |
| 16:06.32 | jon_y | when it does show, it is a mystery |
| 16:12.06 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 16:24.33 | DocScrutinizer05 | jon_y: some formatting oopsies in that pastebin bq27k-detail remake |
| 16:24.48 | DocScrutinizer05 | e.g for temperature in °C |
| 16:24.57 | DocScrutinizer05 | has two decimal separators |
| 16:25.12 | jon_y | yeah, I haven't had the time to test it on the n900 yet |
| 16:26.24 | jon_y | DocScrutinizer05: ok, fixed the dot |
| 16:26.26 | DocScrutinizer05 | if you wanna make sure it's identical, just use a i2cdump >file and use that file as input, then do a diff on output from bash bq27k-detail and your version |
| 16:26.47 | jon_y | ok |
| 16:43.59 | luf | freemangordon: I'm using zpipe for the zlib benchmark and using /dev/(u)random isn't very good as it generate the numbers so it use quiet a lot of CPU. |
| 16:44.19 | freemangordon | luf: use a lile |
| 16:44.22 | freemangordon | *file |
| 16:44.32 | luf | Sure I'm using ... |
| 16:44.41 | freemangordon | luf: backporting aligned memory in libpng is not trivial |
| 16:44.46 | luf | It's just and idea I see so I want to share ... |
| 16:45.30 | freemangordon | it uses a new png_struct_def member ;) |
| 16:45.39 | luf | freemangordon: ok I don't think it helps so much ... I'll see with zlib. But I'm affraid it will be another loose of my time. |
| 16:47.15 | luf | And also it seems it's not good to do compress/uncompress at once as compress use around 90% of cpu and uncompress just below 5% ... |
| 16:49.46 | jon_y | DocScrutinizer05: did the diff, fixed most of them |
| 16:49.54 | jon_y | now differences are mostly whitespace |
| 16:56.58 | jon_y | DocScrutinizer05: perl version http://paste.debian.net/220129/ |
| 17:01.26 | luf | zlibs 1.2.3 and 1.2.7 seems to have same behaviour (times). |
| 17:13.33 | freemangordon | luf: upstream results for libpng, gcc 4.2.1: |
| 17:13.35 | freemangordon | CPU time used = 52.020 seconds (decoding 1.990, |
| 17:13.35 | freemangordon | encoding 49.910 , other 0.120 seconds) |
| 17:14.07 | freemangordon | the same benchmark as for the previous runs |
| 17:14.57 | freemangordon | about 1 second down, i'd say this one is ok |
| 17:23.48 | luf | This is faster? |
| 17:24.08 | luf | Are you just count deconding? |
| 17:24.39 | freemangordon | stock is 2.840 this one 1.990. decoding only |
| 17:25.30 | luf | Hmmm but the question is if neon helps or just the align or whatever changes you did. |
| 17:26.01 | freemangordon | aligment on 16 bytes should not make change for ARM |
| 17:26.33 | luf | Did you checked my previous work that it has no impact while this have so big impact? |
| 17:26.54 | freemangordon | hmm, no |
| 17:27.39 | luf | Maybe I made some mistake in Makefile ... |
| 17:35.30 | luf | freemangordon: can you check it? |
| 17:35.55 | freemangordon | I will |
| 17:36.43 | luf | Again with zlib I have slower result with neon asm code. |
| 17:43.26 | luf | freemangordon: is your code somewhere accessible so I can check it too? |
| 17:45.39 | freemangordon | no. I am using an ugli hack for backport, so will try to fix "your" patch to achieve the same speed |
| 17:45.45 | freemangordon | *ugly |
| 17:47.25 | luf | freemangordon: https://gitorious.org/0xdroid/external_zlib/commit/5d42d250693f443ba3ad0f663d269177b2d02300/diffs - this slowdown the zlib reading from aprox. 0.57 to 0.61; I have to do something wrong. |
| 17:48.32 | freemangordon | luf: ARM memcpy is faster than NEON memcpy |
| 17:49.20 | freemangordon | luf: I think i see whay "your" libpng patch is slow, it uses 32bits, not 128 |
| 17:49.24 | freemangordon | *why |
| 17:50.56 | luf | freemangordon: is it general or just for N900? |
| 17:51.28 | DocScrutinizer05 | ha, native datatypes are kinda important, yes |
| 17:51.43 | freemangordon | luf: the 4bpp code path |
| 17:52.18 | freemangordon | upstream is using 128 bit SIMD, "your" loops 4x32bits for the same data |
| 17:52.35 | freemangordon | no matter it is using NEON in that loop |
| 17:52.35 | luf | freemangordon: :D |
| 17:52.46 | DocScrutinizer05 | a 686 is slower than a 386 when running in 16bit mode (made up example) |
| 17:53.11 | freemangordon | DocScrutinizer05: well, not the same, but still |
| 17:53.14 | luf | freemangordon: as I wrote I don't know asm ... it's too low for me :) |
| 17:53.27 | luf | I understand 32-bit versus 128-bit ... |
| 17:53.42 | freemangordon | luf: I know, I am explaining what is going on in higher-level language |
| 17:54.04 | freemangordon | so, instead 4 pixels per instruction we are doing 1 |
| 17:54.34 | freemangordon | luf: but this is in 3/4 bpp paths |
| 17:54.51 | freemangordon | I expext for >4 bpp we'll have better results |
| 17:54.58 | freemangordon | I need .png to test with |
| 17:55.08 | freemangordon | anyone? |
| 17:55.48 | luf | freemangordon: don't you have one as you tested it with upstream backport? |
| 17:56.04 | freemangordon | it falls in 4bpp path |
| 17:56.26 | freemangordon | where bpp is BYTES per pixel, don;t ask me why |
| 17:58.55 | freemangordon | hmm, you know what. I think I can make that much better ;) |
| 18:00.38 | freemangordon | I can call C function until the remaning bytes align to 16 |
| 18:00.56 | freemangordon | then use neon untill there are < 16 bytes to process |
| 18:01.04 | freemangordon | then again C function |
| 18:02.31 | luf | :D |
| 18:02.55 | luf | You can also ask user for some help (with some dialog) :D |
| 18:04.37 | DocScrutinizer05 | freemangordon: well, that's how any simple silly memcpy and similar stuff works |
| 18:04.47 | freemangordon | DocScrutinizer05: I know |
| 18:04.53 | DocScrutinizer05 | so it's probably a proven concept |
| 18:06.34 | freemangordon | luf: sorry to tell you, but "your" patch is useless :(. just compare path code with upstream. NEON has paeth insctruction ;) |
| 18:06.36 | DocScrutinizer05 | just amazing "upstream" didn't know of those standard design patterns |
| 18:06.50 | freemangordon | DocScrutinizer05: they did aligned memory |
| 18:06.55 | DocScrutinizer05 | aah |
| 18:06.56 | freemangordon | which is better |
| 18:07.18 | freemangordon | but I cannot backport it cleanly, as there is ABI change for that |
| 18:07.35 | freemangordon | additional member in one of the structures |
| 18:07.55 | DocScrutinizer05 | :-/ |
| 18:08.04 | DocScrutinizer05 | understood |
| 18:09.30 | freemangordon | i did some hackish tricks in memory allocation routines, just to check if is makes sense to use NEON |
| 18:09.41 | freemangordon | but I wont push that in CSSU :P |
| 18:13.39 | DocScrutinizer05 | meanwhile thinks freemangordon has changed his mind towards a more conservative notion regarding CSSU changes, and appreciates that change very much |
| 18:14.05 | freemangordon | DocScrutinizer05: wrong :P |
| 18:14.27 | freemangordon | It's been always the case |
| 18:17.15 | luf | finally adler is quiet faster ... aprox 0.56 -> 0.54 (so 5% faster) |
| 18:17.32 | freemangordon | adler? |
| 18:17.41 | luf | https://build.pub.meego.com/package/view_file?file=zlib-1.2.7-adler32_vec_kaffeemonster.patch&package=zlib&project=home%3Astskeeps%3Acheck-zlib&rev=c0999fc2e13c75f801849437bed4f9ea |
| 18:18.19 | freemangordon | luf: aah, you find a patch that actually works? |
| 18:19.50 | luf | freemangordon: yes :D |
| 18:24.18 | luf | freemangordon: so if I understand well no patch for libpng (even it's 30% faster) |
| 18:24.39 | freemangordon | luf: there will be |
| 18:24.44 | freemangordon | but I need time |
| 18:25.40 | luf | ok. |
| 18:28.01 | *** join/#maemo-ssu NIN102 (~NIN@p5DD291F9.dip0.t-ipconnect.de) |
| 19:09.16 | merlin1991 | freemangordon: is your sb x86 or x64? |
| 20:02.23 | *** join/#maemo-ssu bsdmaniak (~bsdmaniak@std93-20-88-120-139-80.fbx.proxad.net) |
| 20:20.14 | gregoa | DocScrutinizer05: I had a look at the log from the May meeting about the optional stuff. technically speaking, I think merlin1991's sketched proposal should work, and I agree that some extra field+HAM-specific changes are a bad idea. |
| 20:20.47 | gregoa | DocScrutinizer05: in general, I'm not so sure I'm excited about the idea. it seems a bit over-engineered and complicated and adds another layer of complexity |
| 20:21.41 | gregoa | DocScrutinizer05: my impression nowadays is that maemo has more repositories than developers (exaggerating, but 3x extra + 3x devel + defunct nokia repos), and I'd rather see them merged / reduced to a lower number |
| 20:23.07 | gregoa | DocScrutinizer05: I'm also not so sure we need to so "shy" of shipping new versions that will overwrite existing packages. after all, that's what all linux distros do; a maintainer decides and users get the updated packages without any decision about having 3 alternatives |
| 20:24.28 | kerio | gregoa: i think the issue is that cssu wants to avoid the "all or nothing" situation as much as possible |
| 20:25.52 | gregoa | kerio: right, that's my impression too. and I have some doubts about that strategy. both from the concept (although I accept it) and from reality (current + future manageability) |
| 20:26.30 | kerio | DocScrutinizer05: you heard the man - upgrade *all* the things! _ò/ |
| 20:29.08 | ShadowJK | Originally Mer (Maemo reconstructed) went the route of reconstructing maemo into more normal linux |
| 20:29.53 | ShadowJK | in the process it broke everything and eventually when it's today working again, it pretty much needs 4X the hardware resources of N900 :/ |
| 20:32.11 | kerio | ShadowJK: does it run fine on four n900s? |
| 20:32.41 | ShadowJK | One for calls, one for sms, one for music, one for homescreen |
| 20:32.44 | ShadowJK | yeah maybe |
| 20:33.08 | kerio | brilliant |
| 20:33.34 | kerio | isn't that what those weird modular proof-of-concept phones do? |
| 20:41.53 | DocScrutinizer05 | gregoa: I seem to find a magic threefold of repositories in almost every arbitrary distro around |
| 20:42.12 | DocScrutinizer05 | gregoa: 3 * devel? |
| 20:42.36 | gregoa | DocScrutinizer05: sorry, s/devel/cssu/ (stable, testing, devel) |
| 20:42.54 | DocScrutinizer05 | cssu-devel is no official repo by any means |
| 20:43.09 | gregoa | DocScrutinizer05: right, the tree-step is fine, but we have at least 2x 3 repos -- the length of the sources.list on my n900 is impressive :) |
| 20:43.13 | DocScrutinizer05 | cssu-stable and cssu-testing are complementary |
| 20:43.58 | kerio | gregoa: meh, i have 7 repos |
| 20:44.13 | DocScrutinizer05 | gregoa: then you're doing sth wrong, since you're not supposed to have extras, extras-testinf, and extras-devel acive all 3 concurrently |
| 20:44.43 | kerio | you're not supposed to have any one of those active at all, you're supposed to use extras-devel-light! |
| 20:45.09 | DocScrutinizer05 | and while CSSU-T/S is kinda like the update-repo usually found on every distro, the extras packages are more like packman |
| 20:45.46 | kerio | DocScrutinizer05: nokia ssu&cssu is one repo divided in two |
| 20:45.59 | kerio | nokia apps&maemo extras(-whatevs) is one repo |
| 20:46.02 | DocScrutinizer05 | and btw cssu optianla/alternative packages won't even introduce a new repo |
| 20:46.04 | kerio | and those could be merged, anyway |
| 20:46.10 | gregoa | DocScrutinizer05: right; I have 2 of the active, and 1 would be enough. maybe I was confused by the sheer amount :) but still those exist, and I'm just wondering if this huge infrastructure is really the best way to go |
| 20:46.25 | kerio | gregoa: debian has stable/testing/unstable/experimental |
| 20:46.26 | DocScrutinizer05 | kerio: nokia ssu repo is a hoax |
| 20:46.40 | kerio | DocScrutinizer05: meh, it has its uses i think |
| 20:46.50 | kerio | for dependencies, at least |
| 20:47.04 | kerio | nokia apps is definetely used for dependencies |
| 20:47.42 | gregoa | DocScrutinizer05: I understand that the optional idea wouldn't introduce new repos; it's just that looking at the log reminded me of these thoughts I had earlier |
| 20:48.07 | gregoa | kerio: oh really? :) but in debian that's one "tree" not like 3 as in maemo (nokia / extras / cssu) |
| 20:48.08 | kerio | ...i think, at least |
| 20:48.17 | kerio | gregoa: yeah, that situation is a bit stupid |
| 20:48.29 | kerio | let's actually change situation |
| 20:48.30 | kerio | linux mint |
| 20:49.25 | DocScrutinizer05 | the point of CSSU is: we can't ship that stuff via nokia repos, though they would belong there |
| 20:49.46 | gregoa | btw, the split between extras-* and cssu-* has the negative side effect that I can't build/upload a package for/to extras* that (build)depends on something in cssu (new qt e.g.) |
| 20:50.01 | kerio | mint, ubuntu, ubuntu-updates, ubuntu-security, ubuntu partner |
| 20:50.05 | DocScrutinizer05 | otoh we don't want to get completely rid of nokia repos since that would introduce *real* unmanageable overhead in maintenance |
| 20:50.15 | kerio | DocScrutinizer05: meh, a mirror wouldn't cause that |
| 20:50.29 | kerio | i'm not sure it would be legal, though |
| 20:50.31 | gregoa | DocScrutinizer05: right. maybe this whole changes now can help to consolidate the old nokia repos and the cssu repos. would kill one "tree". and then the question is if we should "force" all users to cssu ... |
| 20:50.47 | merlin1991 | gregoa: nah |
| 20:50.59 | merlin1991 | cssu in no way is as "functional" as a stock image |
| 20:51.03 | kerio | gregoa: <DocScrutinizer05, on TMO> CSSU stable is now recommended for all N900 users |
| 20:51.09 | merlin1991 | we introduce regressions with every step |
| 20:51.12 | DocScrutinizer05 | again: cssu is not the alternative repo for extras |
| 20:51.33 | merlin1991 | DocScrutinizer05: cssu technically should live together with extras in one repo |
| 20:51.34 | gregoa | merlin1991: easy solution: don't introduce regressions :) |
| 20:51.43 | kerio | DocScrutinizer05: normal distros only have one repo, is the point that gregoa is making, aiui |
| 20:52.04 | merlin1991 | gregoa: easier said than done with all those fancy closed source foobar applications (c) nokia that don't work like everything else has to |
| 20:52.09 | gregoa | merlin1991: I mean, that's what all linux distros do: upload new stuff to unstable or rawhide or whatever. yes, things can break there and have regressions. bugs get fixed, and packages migrate to testing |
| 20:52.19 | DocScrutinizer05 | kerio: ORLY? |
| 20:52.42 | DocScrutinizer05 | shall I send you a list of repos I got enabled on a pretty default OpenSuse? |
| 20:52.56 | merlin1991 | debian has 1 repo |
| 20:52.57 | kerio | that could mean that opensuse is a bad distro |
| 20:52.58 | kerio | flees |
| 20:53.06 | merlin1991 | + the backports repo |
| 20:53.16 | kerio | + the security repo |
| 20:53.55 | merlin1991 | kerio: I don't really count the main repo as independend of the scurity repo because they basically ship the same :D |
| 20:54.03 | merlin1991 | only + security patches |
| 20:54.06 | tadzik | + multimedia repo |
| 20:54.14 | gregoa | nah, that's _not_ debian |
| 20:54.15 | merlin1991 | which multimedia repo? |
| 20:54.15 | kerio | tadzik: why? |
| 20:54.16 | merlin1991 | o_O |
| 20:54.30 | tadzik | I have an deb http://www.deb-multimedia.org/ testing main non-free |
| 20:54.31 | kerio | he means medibuntu, probably, but that's been discontinued or at least not encouraged anymore |
| 20:54.37 | tadzik | tbh, I'm not sure why it's there ;) |
| 20:54.46 | tadzik | nah, that's plain debian testing |
| 20:55.04 | merlin1991 | wtf is that repo |
| 20:55.10 | gregoa | that's a private repo by christian marillat. not more not less. |
| 20:55.20 | gregoa | (and partly useful) |
| 20:55.27 | tadzik | must be that I needed something from it |
| 20:55.48 | tadzik | but yeah, that's not likely upstream debian repo |
| 20:57.47 | DocScrutinizer05 | FWIW http://wstaw.org/m/2012/12/29/yast2-000.png |
| 20:58.50 | merlin1991 | madness |
| 20:58.51 | DocScrutinizer05 | I don't think many finegrained repos are sth negative, au contraire |
| 20:58.56 | kerio | DocScrutinizer05: that's not fair, a ton of those would be merged in the same repo in apt |
| 20:59.02 | kerio | in different components |
| 20:59.29 | DocScrutinizer05 | mad gigantic one-for-everything repos like extras-devel *are* something negative |
| 20:59.42 | kerio | debian has free non-free contrib, ubuntu has main restricted universe multiverse |
| 20:59.45 | merlin1991 | dafaq source has it's own repo |
| 20:59.56 | merlin1991 | kerio: don't forget source |
| 20:59.56 | kerio | if you count those as separate repos, the count becomes huge |
| 21:00.06 | kerio | nobody actually uses source repos |
| 21:00.11 | kerio | :P |
| 21:00.16 | merlin1991 | fu ;-) |
| 21:00.30 | kerio | source is separate in debian repos though |
| 21:00.38 | kerio | a deb-src entry instead of a deb entry in sources.list |
| 21:01.18 | merlin1991 | from the repository side it has it's own index files (one per component) |
| 21:02.33 | merlin1991 | funny to abstract the "source" away at the same level as different architectures |
| 21:03.00 | kerio | it makes sense, really |
| 21:03.25 | merlin1991 | only if you can build each and every arch from the same source package |
| 21:03.36 | kerio | why shouldn't you be able to? |
| 21:03.40 | kerio | file a bug! |
| 21:03.55 | merlin1991 | special patches needed here and there for foobar things in various cpus? |
| 21:04.13 | kerio | the source tarball should not be architecture-specific |
| 21:04.26 | merlin1991 | I hate it when a package does all kinds of crazy for different architectures in order to build properly |
| 21:04.34 | merlin1991 | you never find the part that builds what you want :D |
| 21:04.41 | kerio | heh, have you ever looked at the gmp source? |
| 21:04.59 | DocScrutinizer05 | merlin1991: well, that's the linux way however |
| 21:05.34 | merlin1991 | well there's a difference between calling ./configure with arch flags and doing all kinds of tricker at a higher level |
| 21:05.43 | kerio | "higher level"? |
| 21:06.03 | merlin1991 | above the plain building |
| 21:06.12 | DocScrutinizer05 | even higher than .configure? |
| 21:06.21 | merlin1991 | yep |
| 21:06.25 | kerio | autoconf level? |
| 21:06.33 | merlin1991 | I've seen things ;) |
| 21:06.36 | DocScrutinizer05 | couldn't figure any further abstraction level |
| 21:06.41 | kerio | why didn't you file them as bugs? |
| 21:06.41 | merlin1991 | still got bad dreams |
| 21:06.59 | kerio | merlin1991: ever compiled nethack without the autoconf patch? |
| 21:07.16 | merlin1991 | kerio: because sometimes you just want to get something running and never think about it again |
| 21:07.27 | DocScrutinizer05 | next higher abstraction level would be actual separate repos for each arch |
| 21:08.56 | DocScrutinizer05 | linux main branch per definition should build on all arch |
| 21:09.07 | DocScrutinizer05 | aiui |
| 21:09.21 | merlin1991 | DocScrutinizer05: I'm talking about abstraction in the build process, you usually have debian/rules - debhelper / cdbs / custom - autotools / cmake / whatever |
| 21:09.32 | merlin1991 | i hate it when the arch hacks live @ debian/rules level |
| 21:09.44 | kerio | gmp does specific multiarch in the right way |
| 21:10.15 | DocScrutinizer05 | whatever, maemo isn't multi-arch right now |
| 21:10.22 | DocScrutinizer05 | and probably won't ever be |
| 21:10.37 | DocScrutinizer05 | also it's not a child of main |
| 21:10.37 | merlin1991 | it's hard enough to follow those with all the implzit things that happen (imo cdbs is worse than debhelper because it does even more without being asked specifically) |
| 21:11.30 | merlin1991 | or rather asked visibly, because yeah you import some make file and it does stuff for you, but you don't see from the import what will happen |
| 21:11.35 | gregoa | merlin1991: be happy if you never saw a package using yada as its build system :) (I hope they are all gone from debian by now) |
| 21:12.31 | merlin1991 | gregoa: do you also find it funny when you find a package that does most things in the rules file itself |
| 21:12.57 | gregoa | merlin1991: well, it can cause headaches, but sometimes it might be necessary |
| 21:13.17 | merlin1991 | there are a few packages in maemo extras written like that |
| 21:13.40 | merlin1991 | it feels so weird to look at their buildscripts after messing with debhelper all the time |
| 21:13.43 | gregoa | merlin1991: or do you mean doing things manually instead of using dh_*? yes, that's a spleen of some people but annyoing for alle others |
| 21:13.55 | merlin1991 | yep I mean that |
| 21:14.53 | gregoa | well, a problem in maeno in general is from my POV that most people are more experienced in programming than in packaging, they just have to press their code into a .deb somehow, and that's how the packages look like |
| 21:15.30 | gregoa | including packages that don't have source code in the "source package" but compiled stuff that they "cp" in d/rules |
| 21:15.37 | merlin1991 | but hey I'm one of them thanks to aegis in harm I wrote this hack: https://github.com/kelvan/gotoVienna/blob/master/bdist_hdeb.py#L43 |
| 21:15.40 | kerio | gregoa: isn't that the reason why maintainers are usually separate people from the developers? |
| 21:15.44 | gregoa | and cargo-culted d/rules files that look like from 2005 |
| 21:16.03 | gregoa | kerio: ack, at least that's how linux distros work |
| 21:16.29 | gregoa | I mean, having debhelper 5 (and a separate debhelper7) version and dpkg from 2009 etc. also doesn't help |
| 21:16.43 | kerio | gregoa: and no debconf! |
| 21:17.04 | gregoa | ii debconf 1.4.70.osso3+0m5 Debian configuration management system |
| 21:17.20 | kerio | s/no/no interfaces for/ |
| 21:17.29 | kerio | so no package uses it |
| 21:17.48 | gregoa | oh yes. - I guess I have some package installed that needs/uses debconf :) |
| 21:18.08 | kerio | not installed here |
| 21:18.19 | kerio | fakedebconf is installed |
| 21:18.25 | kerio | oh god why |
| 21:19.06 | merlin1991 | probably to get debconf stuff run through ham? |
| 21:19.19 | kerio | it doesn't actually run through, though |
| 21:19.22 | gregoa | hm, not sure why I have it. maybe I tried to port something from debian at some point. |
| 21:20.16 | merlin1991 | kerio: yeah well fake it through so dpkg is happy |
| 21:20.32 | merlin1991 | oh yes the user said DO it to everything, trust me! |
| 21:20.43 | kerio | you might think he's happy, but he's crying on the inside |
| 21:20.53 | kerio | longing for an end of suffering that will never come |
| 21:21.03 | merlin1991 | but hey we have a ham specific ask dialog |
| 21:21.19 | merlin1991 | that is very helpful when you install something via ssh and the device is somewhere else |
| 21:21.25 | kerio | indeed |
| 21:21.31 | gregoa | oh, yes |
| 21:21.47 | kerio | it's especially annoying when the phone is in your room and you're in the bathroom, pooping |
| 21:22.08 | merlin1991 | kerio: actually in that case I'd rather take the phone with me instead of ie a laptop :D |
| 21:22.22 | gregoa | it's also annoying when it's on your desk, and you just don't look at it :) |
| 21:22.46 | merlin1991 | after flashing I usually install extra decoders support |
| 21:22.49 | kerio | gregoa: most recent preinst/postinst scripts that do that usually print "Confirm the information on the n900 screen" on the terminal |
| 21:23.02 | kerio | merlin1991: hold on, then why would i have a laptop? |
| 21:23.02 | merlin1991 | and the fsckd flac/ogg package has a "this might take a while" dialog |
| 21:23.06 | gregoa | kerio: yup, that's a bit less insane |
| 21:23.21 | kerio | merlin1991: i wonder if you can ^c maemo-confirm-text |
| 21:23.34 | merlin1991 | nah you'd ^c dpkg / apt in that case |
| 21:23.49 | merlin1991 | because there are layers at work and you only have control over the top layer :/ |
| 21:23.51 | kerio | ok, killall maemo-confirm-text from a separate shell |
| 21:23.59 | kerio | what's the return code of a sigkilled program? |
| 21:24.05 | merlin1991 | well that would give it a non0 exit status |
| 21:24.10 | merlin1991 | thus making dpkg abor |
| 21:24.11 | merlin1991 | t |
| 21:24.20 | gregoa | in a loop! hey, we need a new dbus interface and hal could care for it !!111 |
| 21:24.47 | gregoa | with settings stored in a looong gconf key |
| 21:24.58 | kerio | gregoa: plz add debconf support to the whole of maemo |
| 21:25.06 | gregoa | :) |
| 21:26.55 | gregoa | kerio: works for me. I can run "dpkg-reconfigure debconf" and answer it's debconf questions. and in /var/lib/dpkg/info I see some maintainer scripts using debconf |
| 21:27.47 | kerio | gregoa: only upstream packages though |
| 21:29.09 | gregoa | kerio: you mean "properly done packages"? :) |
| 21:29.15 | *** join/#maemo-ssu arcean (~arcean@aacs56.neoplus.adsl.tpnet.pl) |
| 21:29.46 | kerio | gregoa: i can't run dpkg-reconfigure, weird |
| 21:29.56 | gregoa | kerio: https://paste.debian.net/220183/ |
| 21:30.32 | gregoa | kerio: well: which dpkg-reconfigure ==> /usr/local/sbin/dpkg-reconfigure *cough* |
| 21:30.43 | kerio | and what's that? |
| 21:30.57 | gregoa | /usr/local/sbin is managed by the local admin |
| 21:31.02 | kerio | i know |
| 21:31.11 | gregoa | i.e. I've copied it there from a debian machine manually, I guess |
| 21:31.33 | kerio | you disgust me |
| 21:32.06 | gregoa | s/you/maemo/, I suppose :) |
| 21:32.12 | kerio | yep :( |
| 21:32.43 | kerio | hm, do you also get error message about debconf eventually falling back to the Teletype frontend? |
| 21:32.58 | kerio | or maybe you have a proper perl install |
| 21:33.20 | kerio | considering your fetish for badly-designed languages that are indistinguishable from line noise |
| 21:34.53 | gregoa | kerio: that might be libterm-readline-perl-perl (usually I prefer libterm-readline-gnu-perl, not sure why I have the other one on the n900) |
| 21:35.16 | kerio | gregoa: it would still try and fail to use Dialog |
| 21:35.24 | kerio | which is a suggested package but it's not in the repos |
| 21:35.49 | gregoa | if you dpkg-reconfigure debconf you can chosse between dialog, whatever, readline |
| 21:35.54 | gregoa | *choose |
| 21:36.01 | kerio | i can't dpkg-reconfigure :( |
| 21:40.32 | gregoa | what happens? have you tried "dpkg-reconfigure -plow debconf"? |
| 21:40.40 | kerio | i don't have a dpkg-reconfigure |
| 21:40.44 | kerio | it's nowhere in the repos |
| 21:40.59 | kerio | ...what the hell is -plow anyway |
| 21:41.04 | gregoa | oh, I thought you copied it in the meantime :) |
| 21:41.13 | gregoa | priority low, as in "show me all questions" |
| 21:41.17 | kerio | oh |
| 21:41.31 | kerio | http://static.tvfanatic.com/images/gallery/mr-plow-picture.jpg |
| 21:41.51 | kerio | to be fair i do have a sheevaplug with debian |
| 21:42.12 | gregoa | kerio: http://paste.debian.net/220187/ (the version I'm using on the n900, a bit older than what I have on unstable) |
| 22:34.38 | *** join/#maemo-ssu tg (~irc@sch-1526621511.sch.bme.hu) |
| 22:36.23 | DocScrutinizer05 | ~dict plow |
| 23:32.19 | *** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm) |
