**** BEGIN LOGGING AT Wed Apr 06 02:59:58 2016 Apr 06 03:21:26 azkay: does it mount manually? Apr 06 03:29:52 formatted it to fat32 in gparted, put it in and "mount /dev/mmcblk1p1 /mnt" gives me "invalid argument" Apr 06 03:31:07 Unrelated, but damn this n900 that I got seems to have a much softer digitiser than my old one Apr 06 03:31:18 Every day I'm seeing more scratches on it, my last one didn't have any Apr 06 03:34:56 Weee, after a restart (for the 10th time) it's now working :) Apr 06 05:04:26 About ready to shoot myself over bleeding radare2. >_> Apr 06 05:10:59 DocScrutinizer05: Thank you for the response. You too sixwheeledbeast. Is there a proper PDF I can scour so I can disassemble properly? Apr 06 07:33:58 stryngs: try searching service manual from google or maemo wiki. Apr 06 07:48:41 uhm Apr 06 07:48:42 so Apr 06 07:48:46 how is maemo's support for java? Apr 06 07:50:16 still... i'm not willing to record yappari in java Apr 06 07:58:55 https://github.com/WhisperSystems/libsignal-protocol-c Apr 06 07:58:57 there is this Apr 06 07:59:11 that may be a little easier to use with yappari's gui Apr 06 07:59:45 although i think it's basically the same thing as the qt5/4 implementation i got from coderus Apr 06 07:59:55 who, by the way, has decided not to continue developing his whatsapp client Apr 06 08:00:42 i think the way, really, is to make a telepathy plugin that supports whatsapp Apr 06 08:01:00 ceene: there is a purple plugin Apr 06 08:01:07 that supports encryption? Apr 06 08:01:24 https://github.com/davidgfnet/whatsapp-purple Apr 06 08:01:29 ah, not sure Apr 06 08:01:42 maybe they do Apr 06 08:02:01 there's a libaxolotl-cpp dir in that repo Apr 06 08:02:07 so they should, yeah Apr 06 08:02:08 it does use axolo Apr 06 08:02:10 yeah ;) Apr 06 08:02:13 well, that's a good thing Apr 06 08:02:18 so... Apr 06 08:02:31 remove all protocol related things from yappari Apr 06 08:02:37 and make it a purple user? Apr 06 08:03:01 hmm, dunno, I suspect we'd still deps issues regarding libpurple Apr 06 08:03:10 (and newer libpurple needs newer glib iirc) Apr 06 08:03:14 +have Apr 06 08:03:17 aargh Apr 06 08:03:21 yeah, deps hell Apr 06 08:03:41 no wonder coderus is fed up with all this Apr 06 08:03:45 actually the way to go would be telepathy->haze->whatsapp-purple Apr 06 08:04:02 haze is a telepathy-purple thing, isn't it? Apr 06 08:04:05 yeah Apr 06 08:04:15 i had a company once, named hazent :) Apr 06 08:04:23 but deps hell still apply Apr 06 08:04:39 we didn't do shit except lose money, time and throw business cards like we were important or something Apr 06 08:04:46 fun times those Apr 06 08:04:56 better than this whatsapp thing Apr 06 08:05:05 haha Apr 06 08:06:55 so Apr 06 08:07:01 is there any feasible way then? Apr 06 08:07:08 or should i just announce that i retire from this? Apr 06 08:10:18 I guess you could start by sending a few emails around (to coderus, and/or to whatsapp-purple author) Apr 06 08:12:54 Depends: ${shlibs:Depends}, ${misc:Depends}, libpurple0 (>= 2.3.0), libfreeimage3, libprotobuf8 Apr 06 08:12:59 ii libpurple0 2.10.11-0maemo1 multi-protocol instant messaging library Apr 06 08:13:08 looks like it might actually work o.O Apr 06 08:13:29 still need protobuf, but... Apr 06 08:14:54 the libprotobuf thing i think i can work around Apr 06 08:15:09 as i got coderus' libs to compile on scratchbox Apr 06 08:15:09 yeah looks like libprotobuf is pretty much standalone Apr 06 08:15:14 i don't remember how, but i did Apr 06 08:16:17 i.imgur.com/Qyek0aY.jpg Apr 06 08:16:21 Login finally down Apr 06 08:16:40 that's an uber client? Apr 06 08:16:43 on console Apr 06 08:16:45 cool :) Apr 06 08:16:45 yeah Apr 06 08:17:10 It's been a week since I started using my new n900, and a week since I've been able to get an uber :P Apr 06 08:17:14 E: Couldn't find package libfreeimage-dev Apr 06 08:17:42 azkay: oh, nice Apr 06 08:17:43 what is does thing and why does a library need to manipulate images Apr 06 08:18:08 s/does/this/ Apr 06 08:18:09 ceene meant: what is this thing and why does a library need to manipulate images Apr 06 08:18:46 processing/converting images before sending I guess (?) Apr 06 08:19:03 maybe, yeah Apr 06 08:19:04 ok Apr 06 08:19:04 so Apr 06 08:19:14 now i need to port this libfreeimage to maemo Apr 06 08:19:18 yeah Apr 06 08:19:50 packages.debian.org/search?keywords=libfreeimage-dev Apr 06 08:19:55 Can't just use the armel one from there? Apr 06 08:20:25 almost yeah Apr 06 08:20:26 and this freeimage thing depends on a bunch of other image processing libraries that we don't have Apr 06 08:20:43 err we won't just take in the binary though Apr 06 08:20:54 but we can fetch their package and adapt the debian/ Apr 06 08:21:01 I seeee Apr 06 08:21:03 we have most of it Apr 06 08:21:23 lcms2 is missing (we have lcms1) Apr 06 08:21:47 libraw5 might be missing (not sure about the version we have) but I suspect we won't need it for a whatsapp client :) Apr 06 08:22:37 we might get away without lcms as well Apr 06 08:23:14 Offtopic: Once I get the console version pretty much working, I should look at how to implement it into the maemo plugins stuff (like skype, facebook, etc). Send an SMS or something to Uber and it requests it, maybe Apr 06 08:36:40 And this is why I hate oauth API stuff, they say not to distribute the client_secret. Well, how are people supposed the client if they can't login without it? Apr 06 08:36:54 supposed to use the client* Apr 06 08:39:31 Anyone know what I should be looking for for coding something that works with Maemo? (Like skype, facebook, etc). Where you add your account, change it to online/offline in the top menu etc Apr 06 08:41:23 https://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Using_Data_Sharing/Sharing_Plug-in#Account_Setup_User_Interface_Flow Apr 06 08:41:26 mmm Apr 06 08:41:29 i don't think this is it Apr 06 08:41:46 i think that's for apps that share files through some service Apr 06 08:42:15 but it's related nonetheless Apr 06 08:43:12 Thanks :), I just found some examples too https://vcs.maemo.org/svn/maemoexamples/trunk/hildon-examples/ Apr 06 09:37:20 maybe it could be implemented as pidgin plugin? Apr 06 09:53:18 that's purple, basically Apr 06 12:16:30 it would be nice to have on maemo some kind of transport like spectrum2 that would allow to connect many other IM protocols: http://spectrum.im/documentation/about.html. Now i'm using it as gateway transport for whatsapp with the setup: openfire/spectrum2/tranwhat/yowsup Apr 06 12:17:40 never heard about that Apr 06 12:27:53 https://github.com/stv0g/transwhat Apr 06 12:44:20 zxspectrum2? ;-) Apr 06 12:45:05 http://www.ebay.co.uk/bhp/zx-spectrum-2 Apr 06 12:48:45 robotanarchy_: did you try it with mdbus2 Apr 06 12:49:39 mickeyL's dbus \o/ Apr 06 12:49:58 ported from Openmoko Apr 06 12:50:09 Yes. written in .... vala Apr 06 12:50:11 and I have no valac Apr 06 12:50:14 *shrug* Apr 06 12:50:15 hehe Apr 06 12:50:37 vala? duh! I thought it's python Apr 06 12:50:44 it requires valac Apr 06 12:51:12 I'm almost sure it's python. Maybe the *1 version Apr 06 12:51:19 let me look. Apr 06 12:51:47 ah. Apr 06 12:51:53 https://github.com/freesmartphone/mdbus2 404 Apr 06 12:52:44 http://paste.opensuse.org/75378034 Apr 06 12:53:33 taking the debian pkg Apr 06 12:53:46 thanks Apr 06 12:54:07 prolly mdbus2 is vala then Apr 06 12:54:35 not prolly, obviously Apr 06 12:55:56 https://github.com/freesmartphone/mdbus WFM Apr 06 12:57:30 # ./mdbus2 -s org.ofono / org.ofono.Manager.GetModems Apr 06 12:57:30 ([],) Apr 06 12:57:31 hm Apr 06 12:58:14 OK, will continue a tad later. Apr 06 13:01:59 complete FSO was python and then version 2 rewrite in vala Apr 06 13:02:35 I liked the python variant more Apr 06 13:02:56 but alegedly for performance reasons Mickey went to vala Apr 06 13:03:11 btw vala is just a C preprocessor, basically Apr 06 13:03:52 DocScrutinizer05: zxspectrum2? It would be nice.. Spectrum2 &CO is a big undocumented mess .. Apr 06 13:04:03 ouch Apr 06 13:05:36 Wizzup: anyway if you are interested in FSO, Mickey is a very nice guy and always willing to help Apr 06 13:06:28 unlike ofono folks, reportedly Apr 06 13:06:41 I'm just trying to do what the linux ML post says on how to test this... Apr 06 13:06:47 sre is none of the ofono folks though Apr 06 13:15:01 robotanarchy_: have you managed to successfully probe nokia-modem? Apr 06 13:16:08 I think that is the main reason it fails Apr 06 13:16:16 I get this: Apr 06 13:16:16 [ 100.532379] nokia-modem n900-modem: Could not get gpio 0 Apr 06 13:16:16 [ 100.532501] nokia-modem n900-modem: Could not probe GPIOs Apr 06 13:16:16 [ 100.532806] nokia-modem: probe of n900-modem failed with error -16 Apr 06 13:22:22 hmm GPIOs not in mainstream kernel? Apr 06 13:22:58 I seem to recall sth like that Apr 06 13:23:48 either not available at all, or (more likely) massively changed API Apr 06 13:58:20 GPIO 0 ??? CMT_EN is GPIO_74 Apr 06 13:59:13 DocScrutinizer05: well, sre can get it to work on some mainline version Apr 06 13:59:22 and apparently also a few others. so there's likely something odd Apr 06 14:01:05 APE_RST_RQ and CMT_RST_RQ are on GPIO_72 and 73, CMT_RST on GPIO_75 Apr 06 14:02:53 we also got APESLEEPX to CMT/RAPUYAMA on GPIO_70 which I got NFC what it does Apr 06 14:04:28 ooh, sorry I missed: APE_RST_RQ Input, CMT_RST_RQ Output, all others output too Apr 06 14:04:32 from APE view Apr 06 14:05:34 HTH Apr 06 14:05:43 Wizzup: which kernel? Apr 06 14:05:55 and for which userapace? Apr 06 14:06:45 (booting now) Apr 06 14:07:03 Pali: userspace is gentoo, do you want to know udev version? kernel is 4.5-rcX from your branch (sec) Apr 06 14:07:27 above error message is there if you gpio_switch kernel driver want to use those GPIOS together with nokia-modem driver Apr 06 14:07:46 hehe Apr 06 14:07:48 Linux gentoo900 4.5.0-rc5+ #1 PREEMPT Wed Mar 9 18:58:02 CET 2016 armv7l Nokia RX-51 board GNU/Linux Apr 06 14:07:49 so only one kernel driver should control Apr 06 14:07:59 # lsmod | grep gpio Apr 06 14:07:59 gpio_keys 8404 0 Apr 06 14:08:13 gpio switch is static linked into zImage Apr 06 14:08:17 Ah. Apr 06 14:08:25 Yep. I see it now in dmesg. Apr 06 14:08:35 and is available only in my linux-n900 tree (not in upstream) Apr 06 14:08:44 that's what I meant Apr 06 14:08:50 What is the best thing to do? Make it a module? Disable it? Apr 06 14:08:57 so depends on how you want to control those GPIOs Apr 06 14:09:01 via gpio switch? Apr 06 14:09:17 or via generic gpio sysfs (exported by nokia modem)? Apr 06 14:09:28 I guess that depends what ofono is doing ;-) Apr 06 14:09:34 this is without ofono starting Apr 06 14:09:42 ofono should support both methods :-) Apr 06 14:09:43 This is just me trying to probe the module :) Apr 06 14:09:49 but preferred is second via nokia modem Apr 06 14:10:01 What would you recommend I do? Apr 06 14:10:11 (I'm trying to get this to work and have no preference) Apr 06 14:10:29 you need: 1) disable gpio switch when compiling kernel or either 2) load nokia-modem.pm=0 Apr 06 14:11:15 emphasis on "or either" Apr 06 14:11:31 which one is better? Apr 06 14:11:39 depends on userspace Apr 06 14:11:44 :-) Apr 06 14:11:45 maemo needs 1) Apr 06 14:12:01 err 2) Apr 06 14:12:19 Maemo sscd and csd can work only with pm=0 and with gpio switch Apr 06 14:12:41 Pali: pm=0 worked when probing Apr 06 14:12:50 pm=0 just skip exporting gpios Apr 06 14:12:50 you're such a smart bunch, guys :-)) Apr 06 14:13:03 so gpio switch can control gpios Apr 06 14:14:38 anybody ever checked that weird stuff around APE_RST_RQ CMT_RST_RQ APESLEEPX ? Apr 06 14:15:06 I suspect the former two are about a mutual watchdog Apr 06 14:17:36 third *maybe* to tell cellmo to suspend watchdog since APE went asleep Apr 06 14:17:58 http://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c#n207 Apr 06 14:18:10 APESLEEPX is for flash mode Apr 06 14:18:38 n900 has rapu type 1 Apr 06 14:18:40 wow, weird. Many thanks Apr 06 14:23:40 OK, so nokia-modem probes successfully. My next plan is to make gprs work Apr 06 14:24:05 OUCH! http://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c#n272 missing a usleep() Apr 06 14:24:36 how much usleep Apr 06 14:24:44 minimum 100us Apr 06 14:24:51 or what Apr 06 14:24:52 raher 1000 Apr 06 14:25:13 or modem might miss IRQ due to too short 0-time Apr 06 14:25:17 rip Apr 06 14:25:26 there's also two rst close togheter in the next function Apr 06 14:26:30 yep, http://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c#n310 same issue Apr 06 14:27:40 pretty anti-EE/hw approach I see in ofono Apr 06 14:27:48 ignorant Apr 06 14:28:27 I mean you can't rely on CPU clock without even probing/knowing it to shape a hw electrical signal Apr 06 14:29:59 I bet my skinny ass the pulsewidth of a GPIO_WRITE(cmt_rst, 0); GPIO_WRITE(cmt_rst, 1); is significantly shorter than 1us Apr 06 14:30:09 shorter than 0.1us even Apr 06 14:30:29 can you even usleep in the kernel, though Apr 06 14:30:39 or would that need to be refactored Apr 06 14:30:42 Pali: halp us Apr 06 14:30:48 dunno, use NOPs if you can't do smarter things Apr 06 14:30:52 no i mean Apr 06 14:30:58 wouldn't it freeze the everything Apr 06 14:31:18 I think there's a delay or sleep kernel function Apr 06 14:31:49 and yes it freezes the system for the sleeptime Apr 06 14:32:02 that's why yiu usually avoid it Apr 06 14:32:28 not here though, here you must use it Apr 06 14:32:56 I mean it's one millisecond Apr 06 14:33:39 you may quote me when upstreaming the patch - I'll even sign it off Apr 06 14:34:27 robotanarchy_: I also think that your udev rename is not correct / bogus path to go down to Apr 06 14:34:36 robotanarchy_: when you properly modprobe the nokia modem, you get a phonet0 Apr 06 14:34:55 I'm rebuilding ofono now with tools and some other use flags Apr 06 14:34:57 yes, that's the ISI interface basically Apr 06 14:34:59 Let's hope they are useful Apr 06 14:35:29 I want to see if I can get the gprs0 interface up Apr 06 14:35:38 Wizzup: please already apply my patches ;-) Apr 06 14:35:56 usleep(1000) Apr 06 14:36:28 I will do that when I installed it and it doesn't work - not that I don't trust your patches, but I want to reproduce what others did before Apr 06 14:36:33 I need a solid base to work/test from Apr 06 14:36:44 k Apr 06 14:37:13 though the usleeps only take out unpredictable behaviour from a fringe case Apr 06 14:37:37 without them it may or may not work, with them it must work Apr 06 14:37:55 ack Apr 06 14:37:59 thanks for noticing it Apr 06 14:38:04 yw :-) Apr 06 14:42:55 ofono guys had diect help from Nokia and still they coded such mess Apr 06 14:50:28 * DocScrutinizer05 idly wonders about cmd pipelining in ARM Apr 06 14:51:06 dunno if GPIO access is pipelined Apr 06 14:52:21 worst case pulsewidth is 1/600E6 seconds, or completely optimized out Apr 06 14:53:20 ~1/600*10**6 Apr 06 14:53:20 1666.666666666667 Apr 06 14:53:30 wut? Apr 06 14:53:44 ~1/(600*10**6) Apr 06 14:53:45 0.000000001667 Apr 06 14:54:31 17ns Apr 06 14:56:14 robotanarchy_: have you configured ofono in any way? like in /etc/ofono/ Apr 06 15:19:59 Pali: could we get dmesg early kernel boot msgs copied to syslog early during boot? Apr 06 15:21:13 wait, what's that? Apr 06 15:22:12 syslog copy it (after it start) Apr 06 15:22:55 yeah think so, thanks and sorry for the noise Apr 06 15:24:57 but very early kernel stuff still seems to be missing Apr 06 15:27:51 size of dmsg buffer? Apr 06 15:28:14 or is it just ne getting puzzled? Apr 06 15:28:17 me Apr 06 15:28:37 http://paste.opensuse.org/60705118 Apr 06 15:31:15 DocScrutinizer05: that paste is missing some early log messages, yes Apr 06 15:32:06 hmm, "i2c_omap i2c_omap.2: controller timed out" Apr 06 15:32:28 and yep, we could get those if that lazy ashole here had already soldered the wires to the debug port ;-) Sorry! Apr 06 15:32:53 DocScrutinizer05: is that stock kernel? Apr 06 15:32:59 err yup Apr 06 15:33:12 no need for debug port, you should have evrything in syslog Apr 06 15:33:18 IroN900:~# uname -a Apr 06 15:33:19 Linux IroN900 2.6.28-omap1 #1 PREEMPT Fri Aug 6 11:50:00 EEST 2010 armv7l GNU/Linux Apr 06 15:34:45 >stock kernel in 2016 Apr 06 15:35:11 DocScrutinizer05: no idea why those are missing, reboot once again and check Apr 06 15:35:47 I rebooted and checked several times and same Apr 06 15:35:53 will redo nevertheless Apr 06 15:36:11 weird Apr 06 15:40:52 http://paste.opensuse.org/36151160 Apr 06 15:41:22 freemangordon: still no thumby openssl 0.9.8zh? :( Apr 06 15:41:24 http://paste.opensuse.org/21127879 Apr 06 15:42:55 looks pretty much same, no? Apr 06 15:45:29 wpwrak and me both think dmsg buffer too small for chatty kernel Apr 06 15:45:59 resizing dmsg buffer shouldn't be too hard, no? Apr 06 15:46:26 dmesg even Apr 06 15:47:17 -s bufsize Apr 06 15:47:18 Use a buffer of size bufsize to query the kernel ring buffer. This is 16392 by default. (The default kernel syslog buffer size was 4096 at first, 8192 since 1.3.54, Apr 06 15:47:20 16384 since 2.1.113.) If you have set the kernel buffer to be larger than the default then this option can be used to view the entire buffer. Apr 06 15:47:27 robotanarchy_: ofono doesn't seem to detect any modem for me, yet Apr 06 15:47:37 robotanarchy_: the symlink as suggested in sre's mail and your wiki makes no difference Apr 06 15:51:09 seems kernel ringbuffer is a pathetic 16kB per default, could it get resized by a kernel cmdline parameter on boot, or do we need a kernel rebuild? Apr 06 15:52:23 you can change it by kernel cmdline Apr 06 15:52:29 kewl! Apr 06 15:52:54 log_buf_len= Apr 06 15:53:18 so let's make it 64k and fix the dmesg -s used for copying to syslog(?) Apr 06 15:53:49 at least with uBoot that should work, no? Apr 06 15:54:07 and what is problem? Apr 06 15:54:12 could we binary patch kernel hardcoded default size? Apr 06 15:54:12 I have full dmesg in syslog Apr 06 15:54:25 err see above, I don't Apr 06 15:54:34 stock kernel Apr 06 15:55:02 musb spams too much... Apr 06 15:55:15 I prolly should finally switch to PK ;-) Apr 06 15:55:39 yeah, kernel* too chatty Apr 06 15:56:14 but actually I prefer chatty over too silent Apr 06 15:58:27 depends if it is a program or person Apr 06 15:58:28 ;-) Apr 06 15:59:03 hehehe Apr 06 16:00:30 don't we have a plaintext kernel default cmdline hardcoded into kernel? Apr 06 16:01:14 is it actually evaluated by kernel? or just provided to /proc and no matter what's inside? Apr 06 16:15:28 who does copying of dmesg to syslog? Apr 06 16:16:14 syslog should just pick it up Apr 06 16:17:34 aah builtin, with no options? Apr 06 16:17:57 meh, RTFM Apr 06 16:20:46 no manpage for /etc/syslog.conf Apr 06 16:21:31 usage: syslogd [-drvh] [-l hostlist] [-m markinterval] [-n] [-p path] Apr 06 16:22:01 how the heck I tell syslog about larger kernel ringbuffer, similar to dmesg -s ? Apr 06 16:22:15 or does it simply know the size? Apr 06 16:24:21 btw would jr@saturn:~/mymaemo-workdir/maemo_flasher-3.5_2.5.2.2> ./flasher-3.5 -b="$blabla log_buf_len=64K" work? I guess it's not sticky anyway, in that NOLO would store it to NAND permanently and use it for further boots Apr 06 16:32:15 flasher-3.5 -b="`ssh root@iron900 cat /proc/cmdline` log_buf_len=64K" Apr 06 16:39:41 -b is temporary just for current boot Apr 06 16:39:56 no permanent solution except recompiling kernel Apr 06 16:42:30 uboot! Apr 06 16:43:39 Pali: ack Apr 06 16:43:53 or binary patching kernel ;-D Apr 06 16:44:14 or uBoot as kerio said? Apr 06 16:44:45 for testing flasher -b is just fine I'd guess Apr 06 16:44:55 yeah, uboot Apr 06 16:45:21 seriously, stock kernel and no uboot... what the hell are you doing? :p Apr 06 16:50:08 kerio: I am waitng for merlin1991 to issue new cssu, -thumb will follow shortly Apr 06 16:54:33 ~rescueos Apr 06 16:54:33 somebody said rescueos was http://n900.quitesimple.org/rescueOS/ Apr 06 16:56:01 is there any reason why we don't have a cssu target (or several) with autobuilder Apr 06 16:56:09 ? Apr 06 16:56:38 I mean, a repository where cssu maintainers could push source packages and autobuilder would generate binary packages Apr 06 16:56:41 just like with extras Apr 06 16:57:26 bencoh: nobody wants to take the decision :) Apr 06 16:57:48 take? make? whatever Apr 06 16:58:39 I'm happy to donate arm hw Apr 06 16:58:53 Wizzup: hmm? Apr 06 16:59:03 for build machines Apr 06 16:59:03 is it just about "deciding", or is there any ...obstacle? Apr 06 16:59:09 if that is helpful Apr 06 16:59:25 Wizzup: it shouldn't be considering we use scratchbox, but thx anyway :) Apr 06 16:59:32 ack Apr 06 16:59:42 offer will stand for considerable future :P Apr 06 17:00:10 bencoh: I am not aware of any obstacle Apr 06 17:01:21 freemangordon: so we could have both -testing and -stable? Apr 06 17:02:04 and still have usual extras* packages built against stock PR? Apr 06 17:03:03 I see no problem with that Apr 06 17:03:13 we can even have -thumb target Apr 06 17:03:22 that'd be great as well Apr 06 17:03:55 hmm ... who's admin on autobuilder/package infra? Apr 06 17:04:47 bencoh: CSSU is a layered supplementary repo which nevertheless overrides base packages Apr 06 17:05:01 DocScrutinizer05: yeah, I'm aware of that Apr 06 17:05:03 bencoh: me and merlin1991 Apr 06 17:05:26 me(autobuilder), merlin1991(package interface) Apr 06 17:05:33 there are no regular build targets like CSSU for 'ordinary' packages Apr 06 17:05:57 all maemo-etras is supposed to work on CSSU as well Apr 06 17:06:30 freemangordon: think you could add one of those (-testing or -devel maybe?) just to check if it works/things don't break? Apr 06 17:06:35 DocScrutinizer05: no build targets - it is a matter of setting them up Apr 06 17:07:05 bencoh: I am a kind of maintainer, not a decision-maker Apr 06 17:07:06 DocScrutinizer05: CSSU-* stuff shouldn't interfere with extras*, yeah Apr 06 17:07:19 no, there's no need for such. There's aneed for thumb build target though Apr 06 17:07:21 freemangordon: which means this question should go to council? Apr 06 17:07:30 or HiFo Apr 06 17:07:36 huhu Apr 06 17:07:54 not sure what is the official "structure" lately :) Apr 06 17:08:12 DocScrutinizer05: well, I dunno if there is a need but I feel silly everytime I read fmg/merlin having to fiddle with building packages for release Apr 06 17:08:37 it just doesn't feel right to loose time on that and do a manual build while we could just send source package to some auto process Apr 06 17:08:50 DocScrutinizer05: all the packages in Nokia and SDK repos are build by a kind of autobuilder Apr 06 17:09:28 yeah ok Apr 06 17:09:40 besides this remind me of something you asked lately regarding neo900 and a working, buildable from scratch maemo ;) Apr 06 17:09:44 +s Apr 06 17:09:50 bencoh: well, usually building is not a problem and we don;t have *that* much new packages with every release Apr 06 17:10:08 but then this needs to be a sort of restricted autobuilder, with special care taken about who can upload stuff Apr 06 17:10:11 freemangordon: well, see merlin's fight against autotools a few days ago :) Apr 06 17:10:20 DocScrutinizer05: deffinitely Apr 06 17:10:21 DocScrutinizer05: indeed Apr 06 17:10:37 build TARGETS are x86, ARM, (new:) thumb. In extras etc Apr 06 17:11:13 freemangordon: would they be repositories, targets, something else? Apr 06 17:11:21 a new autobuilder and repo could be very useful for CSSU but only when access is limited to CSSU members Apr 06 17:11:26 those* Apr 06 17:11:29 and under final control of merlin1991 Apr 06 17:11:31 bencoh: I know what you meant, but that happens relatively rarely. and I guess one of the reasons it has happened this time is because it was a while since merlin1991 had done it for the last time ;) Apr 06 17:11:48 maybe yeah :) Apr 06 17:12:14 oh and, another cool thing is we could benefit from the promoting system Apr 06 17:12:21 -devel -> -testing -> -stable Apr 06 17:12:21 hmm? Apr 06 17:12:35 no, no Apr 06 17:12:44 won;t work Apr 06 17:12:52 ah, why? Apr 06 17:13:04 see extras :) Apr 06 17:13:10 hmm? Apr 06 17:13:25 I'm not talking about users voting Apr 06 17:13:41 but about admins/maintainers promoting packages Apr 06 17:13:44 but who? Apr 06 17:13:56 there is one maintainer - merlin1991 Apr 06 17:14:19 exactly Apr 06 17:14:44 CSSU works because it's a strict hierarchy with benevolent dictators Apr 06 17:14:56 and when we used to have regular updates, there were regular meeting of the CSSU team members, where we discussed what to be included in the next update Apr 06 17:15:11 DocScrutinizer05: haha Apr 06 17:15:13 *meetings Apr 06 17:15:22 nah, no haha, see freemangordon ^^^ Apr 06 17:15:29