IRC log for #maemo-ssu on 20131125

00:21.45*** join/#maemo-ssu zumbi (zumbi@pasanda.collabora.co.uk)
02:53.15*** join/#maemo-ssu M13 (~Miranda@83.149.35.4)
02:56.02*** join/#maemo-ssu M13 (~Miranda@83.149.35.4)
03:29.06*** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn)
05:40.09*** join/#maemo-ssu okias (~okias@berger.cust.centro-net.cz)
05:40.34okiasHey guys, did anyone using Charger Manager in linux kernel? (except samsung)
05:41.52*** join/#maemo-ssu LaoLang_cool (~LaoLang_c@183.32.191.181)
05:54.01*** join/#maemo-ssu freemangordon_ (~freemango@46.249.74.23)
06:28.24DocScrutinizer05huh? charger manager?
06:32.22*** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali)
07:49.21*** join/#maemo-ssu LauRoman (~LauRoman@5-14-86-200.residential.rdsnet.ro)
09:01.02*** join/#maemo-ssu freemangordon (~freemango@46.249.74.23)
09:02.53*** join/#maemo-ssu raccoon_ (user@ghs/raccoon)
09:27.38*** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net)
09:47.09*** join/#maemo-ssu Pali_ (~pali@Maemo/community/contributor/Pali)
09:48.25*** join/#maemo-ssu kolp (~quassel@212.255.244.29)
11:00.17*** join/#maemo-ssu Wikiwide (~chatzilla@101.164.32.121)
11:23.25*** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali)
12:16.45*** join/#maemo-ssu lizardo (lizardo@nat/indt/x-mqzrgggaoluckuww)
12:32.39*** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali)
12:41.14*** join/#maemo-ssu Mark__T (86630288@foresight/developer/mark)
13:16.42*** join/#maemo-ssu okias (~okias@berger.cust.centro-net.cz)
13:27.27*** join/#maemo-ssu dos1 (~dos@unaffiliated/dos1)
13:29.11*** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de)
14:29.30*** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172)
15:06.52Palifreemangordon: wl1251 crash in monitor mode with 3.12-rc5 is reproducable
15:07.18Palinow looking at crash dump and trying to fix it
15:18.48Palifreemangordon: here is crash dump: http://pastebin.com/5DQdgdKi
15:20.57Palifreemangordon: I think that in function wl1251_event_process variable wl->vif is NULL and then there is NULL dereference in function ieee80211_beacon_loss
15:21.30Paliso if this is truth then this is problem in wl1251 driver and not in monitor/packet injection patches
15:21.42Paliand patch could be simple, just do not call that function if vif is NULL
15:31.58Palifreemangordon: rigth, it fixing that kernel crash
15:32.01Palipatch is here: http://pastebin.com/YJWZUtY7
15:32.11Paliwill write later to felipec
15:34.47*** join/#maemo-ssu NishanthMenon (~nmenon@nat/ti/x-bgahpkgpkaztyraf)
16:29.08keriofreemangordon: omg omg omg updatez omg
16:29.26freemangordonkerio: hmm?
16:29.38freemangordontoldya, no more thumb for you :P
16:29.41kerioi upgraded stuff
16:30.01freemangordonkerio: what stuff?
16:30.06freemangordonfrom -devel?
16:30.26keriono, thumby stuff i think
16:30.34keriomaybe old stuff tho
16:30.46freemangordonmaybe there were 2 updates for the last month
16:30.53freemangordon*maybe,
16:32.12keriomh, it appears that i can't install the -pr
16:32.21keriowhy can't those dependencies be met?
16:32.34keriooh
16:32.38kerioOH
16:32.42freemangordonkerio: hmm?
16:32.50keriofreemangordon: apparently you're hosting libmaemosec0 0.2.2
16:32.58keriothere's now a 0.2.3
16:33.08keriobut i've given priority to your repository
16:33.09keriocuz of -thumb
16:33.26freemangordonkerio: make sure to refresh
16:33.44kerio...yes
16:33.49freemangordonthe latest is 0.2.3
16:33.52kerioi'm using HAM
16:33.55keriohonest
16:33.57freemangordonand -thumb depends on it
16:34.16freemangordonalso, make sure you have enabled cssu-testing catalog
16:34.20kerioto be fair, pinning isn't really supported
16:34.27keriono, i've got all the repos
16:34.43keriobut i've pinned community-thumb to 600 priority
16:34.48kerioinstead of 500
16:35.42keriocould you remove non-thumby packages? :3
16:35.44freemangordonkerio: hmm, I don;t thik there is libmaemosec0 in the thumb repo. could be wrong as well
16:35.50keriodefinetely wrong
16:36.01freemangordonkerio: no, I can't
16:36.19kerio._.
16:36.26freemangordonjust apt-get install whatever is broken on your side
16:36.29kerioyou're also hosting osso-systemui-alarm 0.3.3+0cssu0
16:36.37kerioi have to install manual versions
16:36.45freemangordonme? no, it is merlin1991 :P
16:36.45kerioand i'm also not sure if it's complete
16:37.02kerioremoving the priority will also make me upgrade from the thumby packages to the stuff in -devel
16:37.08kerioand i don't know if i want to
16:37.23freemangordondon't keep -devel ebnabled
16:37.36kerio#yolo
16:38.23kerio...the fuck, my n900 just... rebooted?
16:38.28kerioi wasn't expecting that
16:38.34freemangordonwhat?
16:38.43freemangordonwhat did you do?
16:38.51keriomh, upgraded hildon-desktop
16:38.57kerioi think it's cuz of that
16:39.04*** join/#maemo-ssu NIN101 (~NIN@p5DD2823F.dip0.t-ipconnect.de)
16:39.08freemangordonhmm, shouldn't happen
16:39.17kerioi don't have syslog enabled sadly
16:39.28freemangordonpray for the device to boot fine
16:39.30keriomh
16:39.36kerio/proc/bootreason says sw_rst
16:39.48kerionot sure what happened, really
16:40.12freemangordonweird
16:40.23kerioit's seriously weird
16:40.32kerioto be fair i was also using g_ether
16:40.43keriobut still
16:40.54freemangordonhmm, sometimes it happens when you have executable pages re-read from the storage, and in the meantime the storage contents have changed
16:41.10keriowhy would they change tho?
16:41.57freemangordonkerio: because you've overwritten it with apt-get ;)
16:42.12keriowhat?
16:42.30freemangordonnew executable overwrote the old one
16:42.58kerioshouldn't it count as an open file though?
16:43.08freemangordonyes
16:43.20freemangordonbut I guess there might be some bug in the kernel
16:43.35freemangordonthe same happens if you copy some .so by hand
16:44.00freemangordonyou got a segfault
16:44.12freemangordonin the process using that library
16:44.41keriothat's awful! D:
16:44.57kerioi am shocked and appalled! D:
16:45.09kerioalso i think my face got stuck D:
16:45.15freemangordonyes, that is why you should upgrade by using HAM ;)
16:45.31freemangordonkerio: slap it, that will fix the things :D
16:51.00keriothere *is* quite a lot of stuff in -devel
16:51.23kerioooh i didn't know you thumbified dosfstools
16:51.44freemangordone2fsprogs should be too
16:51.44freemangordoniirc
16:52.50freemangordonor maybe only on my device
16:53.26freemangordonyep, only on my device, will include them in the next update
17:07.22*** join/#maemo-ssu arcean (~Tomek@apn-95-40-174-198.dynamic.gprs.plus.pl)
17:20.33DocScrutinizer05bug in kernel ??? :-O
17:20.40DocScrutinizer05WTF?!
17:21.05DocScrutinizer05that must be a pretty nasty bug
17:21.21DocScrutinizer05that would affect about EVERYTHING
17:22.09DocScrutinizer05fs MUST NOT unlink a file that has a handle open to it
17:22.15DocScrutinizer05~2119
17:22.16infobotThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
17:49.55*** join/#maemo-ssu BCMM (~BCMM@unaffiliated/bcmm)
17:51.30*** join/#maemo-ssu okias (~okias@berger.cust.centro-net.cz)
18:25.52*** join/#maemo-ssu miha_ (~miha@170.133-224-87.telenet.ru)
18:43.31*** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali)
19:00.29PaliDocScrutinizer05: this is another problem: application X has mmaped file Y. And by default replacing file means: truncate(0); write(new_file_data);
19:01.04Paliso if Y is library in that X, then application crash immeditately if exeucting that code
19:01.31Palicorrect way is to rm (unlink) file Y and then create new with that name of Y
19:01.38Paliand dpkg doing this
19:01.45Palicp (from busybox) not
19:02.05Palinot bug in kernel, but feature in userspace
19:02.21*** part/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de)
19:03.08Paliyou cannot unlink from FS itself if is opened (you can just unlink it from directory structure), but you can erase it or rewrite it
19:03.33Paliand truncate to zero size too...
19:06.08DocScrutinizer05Pali: by default "replacing" a file means to create a new file under same name and unlink the old file's inode entry
19:06.48Palinot by scp/ssh or busybox cp
19:06.59Pali(and maybe also not by gnu cp)
19:06.59DocScrutinizer05what you mean is overwriting an existing file content, not replacing the file
19:07.24Paliyes, but this cp doing
19:07.35Paliso this is reason for segfaults
19:07.36DocScrutinizer05no way
19:09.01DocScrutinizer05a cat $originafile >$newfile would do that
19:09.25Paliscp doing it too!
19:09.29PaliI tested it
19:09.31DocScrutinizer05a cp $originalfile $newfile should always unlink old file for all I know
19:09.41Paliit is busybox!!!
19:10.34DocScrutinizer05meh, fuck busybox
19:12.10DocScrutinizer05busybox is evidently buggy like hell
19:12.52DocScrutinizer05if we would want to sanitize CSSU, we shoukd kick busybox for everything but initscripts
19:13.47DocScrutinizer05while for initscripts we should keep original messybox with all the original flaws and bugs, since something might (and evidently did) need them
19:19.11DocScrutinizer05strace cp x y
19:19.29DocScrutinizer05stat("y", 0x7fffca3aba00)               = -1 ENOENT (No such file or directory)
19:19.31DocScrutinizer05stat("x", {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
19:19.32DocScrutinizer05stat("y", 0x7fffca3ab780)               = -1 ENOENT (No such file or directory)
19:19.34DocScrutinizer05open("x", O_RDONLY)                     = 3
19:19.35DocScrutinizer05fstat(3, {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
19:19.37DocScrutinizer05open("y", O_WRONLY|O_CREAT|O_EXCL, 0644) = 4
19:19.38DocScrutinizer05fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
19:19.40DocScrutinizer05read(3, "Mo 25. Nov 20:17:28 CET 2013\n", 32768) = 29
19:19.41DocScrutinizer05write(4, "Mo 25. Nov 20:17:28 CET 2013\n", 29) = 29
19:20.08DocScrutinizer05.
19:20.10DocScrutinizer05strace cp x y
19:20.29DocScrutinizer05stat("y", {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
19:20.30DocScrutinizer05stat("x", {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
19:20.32DocScrutinizer05stat("y", {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
19:20.33DocScrutinizer05open("x", O_RDONLY)                     = 3
19:20.35DocScrutinizer05fstat(3, {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
19:20.36DocScrutinizer05open("y", O_WRONLY|O_TRUNC)             = 4
19:20.38DocScrutinizer05fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
19:20.39DocScrutinizer05read(3, "Mo 25. Nov 20:17:28 CET 2013\n", 32768) = 29
19:20.41DocScrutinizer05write(4, "Mo 25. Nov 20:17:28 CET 2013\n", 29) = 29
19:21.53DocScrutinizer05jr@saturn:~> cp --version
19:21.54DocScrutinizer05cp (GNU coreutils) 8.16
19:21.56DocScrutinizer05Copyright © 2012 Free Software Foundation, Inc.
19:24.08DocScrutinizer05so yes, you're right regarding O_TRUNC
19:24.42DocScrutinizer05I stand corrected
19:36.18DocScrutinizer05while a mv x y does
19:36.21DocScrutinizer05access("y", W_OK)                       = 0
19:36.22DocScrutinizer05rename("x", "y")                        = 0
19:39.37DocScrutinizer05I'd expect proper install tools like apt or dpkg to do an unlink() befoer the open()
19:41.08DocScrutinizer05and scripts to do a rm $newfilename before any cp $original $newfilename
19:41.46freemangordonDocScrutinizer05: keep in mind those files (libs and bins) are mmaped
19:42.07DocScrutinizer05err yes, exactly because of that
19:42.34freemangordonyou can't move anonymous pages
19:42.43freemangordonwell, the kernel can't
19:42.45DocScrutinizer05hmm?
19:43.12freemangordonfrom the kernel POV, those are anonymous mapped pages, iirc
19:43.22freemangordonand those are unmovable
19:43.42DocScrutinizer05well, then everything absolutely fine, no cp $original $new will have any effect on them
19:44.07DocScrutinizer05but you got it wrng
19:45.02DocScrutinizer05when a process has a .so opened and I want to update that .so, then I need to first rm old.so, so it actually becomes an anonymous file
19:45.19DocScrutinizer05only THEN I may cp $new old.so
19:45.33freemangordonsure, but cp is not supposed to rm
19:45.37freemangordoniiuc
19:45.55DocScrutinizer05since that way the process keeps a handle to an unaltered mmaped file with old .so content
19:46.13DocScrutinizer05see what I wrote above
19:46.20freemangordonotherwise I agree that the correct way to replace an opened .so is to rm it first
19:47.00DocScrutinizer05since cp is not doing rm, I said [2013-11-25 20:41:08] <DocScrutinizer05> and scripts to do a rm $newfilename before any cp $original $newfilename
19:48.52DocScrutinizer05or, even better: you do a cp $new tmp; mv tmp $original
19:49.25DocScrutinizer05since mv does a rename() which implies a unlink()
19:49.43DocScrutinizer05(unless you mv across volume boundaries)
19:50.58DocScrutinizer05(in which case IIRC mv actually does a cp + rm SOURCE)
19:51.59DocScrutinizer05anyway would be interesting what apt and dpkg do
20:06.24Palidpkg calling unlink for sure
20:06.47Paliotherwise we would see couple of crashed apps on all debian systems
20:06.54Pali(when you are upgrading glibc)
20:07.07Palidpkg/apt also using libc.so
20:07.24Palievery non static elf using libc.so
20:08.23*** join/#maemo-ssu M4rtinK (~M4rtinK@ip-89-177-125-59.net.upcbroadband.cz)
20:09.53DocScrutinizer05:nod:
20:10.04DocScrutinizer05Pali: thanks
20:20.20*** join/#maemo-ssu kolp_ (~quassel@212.255.247.70)
21:39.42*** join/#maemo-ssu LauRoman (~LauRoman@5-14-86-200.residential.rdsnet.ro)
21:43.47*** join/#maemo-ssu trx (ns-team@212.200.199.101)
21:43.47*** join/#maemo-ssu trx (ns-team@devbin/founder/trx)
21:49.57kerioPali: to be fair, programs that map a file should handle truncation of that file
21:50.14kerioit's an unspoken agreement that files can change from behind your nose
21:50.53Palikerio: tell this to developers of dynamic linker (ld-linux.so)
21:51.42Palild-linux.so does not doing any that stuff because of speed
21:53.31*** join/#maemo-ssu amizraa (~amizraa@gateway/tor-sasl/amizraa)
21:53.34Palihaving all those fds for inotify only for handling truncate is 1) vaste of file descriptors 2) vaste of kernel operations and handling events
21:54.08kerio*waste
21:55.14*** join/#maemo-ssu nox- (noident@freebsd/developer/nox)
21:57.25*** join/#maemo-ssu tom___ (~tom@66.172.11.27)
22:00.40*** join/#maemo-ssu amizraa (~amizraa@gateway/tor-sasl/amizraa)
22:40.53DocScrutinizer05kerio: creating a local copy of *.so was defeating the whole purpose of shared libs
23:16.57*** join/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de)
23:16.57*** part/#maemo-ssu mkaindl (~mkaindl@ama-dablam.markus-kaindl.de)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.