Thursday, 2014-06-26

« Wednesday, 2014-06-25 Index Friday, 2014-06-27 »
*** slate has quit IRC04:18
*** slate has joined #sailfishos-porters04:22
*** slate has quit IRC04:30
*** slate has joined #sailfishos-porters04:39
*** slate has quit IRC04:56
*** slate has joined #sailfishos-porters05:00
*** ca158 has left #sailfishos-porters05:01
*** slate has quit IRC05:10
*** slate has joined #sailfishos-porters05:15
*** slate has quit IRC06:33
*** slate has joined #sailfishos-porters06:39
situMorning08:26
sledgesmornin!09:31
lbtmorning09:35
*** phdeswer has quit IRC10:21
*** phdeswer has joined #sailfishos-porters10:43
situsledges: Shall we continue from where we left yesterday ?10:51
sledgessitu: so you reverted debugfs?10:54
sledges22:13 < situ> http://pastebin.com/mCwKistY10:54
sledgescan't see anything suspicious..10:54
situsledges: so what is causing that crash according to you ?10:55
situ[pid  1283] write(2, "QPA-HWC: hw_get_module(HWC_HARDW"..., 106) = 10610:55
situI suspect this is goint to debugfs somehow10:56
sledgeshummm.. and if debugfs is double-mounted (android also cares about it)?..10:56
situNot sure.10:57
situsledges: If I umount debugfs, it will crash somewhere else.10:57
sledgessame cause?10:58
sledgesnever know ;)10:58
sledgessitu: ls -l /10:58
situhttp://pastie.org/932611011:02
situLooks like it crashes at the same point with debugfs mounted, let me check again.11:12
sledgesit is not finding the right hwc*.so, same for gralloc11:13
sledgesisn't android playing with properties to inject msm8xxx needed bits into X.Y.so search?11:14
sledges(hence why phdeswer had to start symlinking)11:14
sledgesmaybe something to messed up with build.prop init*.rc and wherever else we might find property havocs? :))11:15
phdeswersitu: sledges : yep that is the symlinking I did. To get the hwc and gralloc11:15
situYeah, it crashes at the same points despite debugfs is mounted or not.11:18
situsledges: in u5, I was able to get lipstick working by not mounting debugfs.11:18
situBut I didn't have any problems with loading .so's in u5.11:21
sledgesso it was a false positive when we disabled debugfs just now11:21
phdeswersledges: possibly11:21
sledgessitu: are you using dhd from your repos11:21
sledgesor from merged mer-hybris ?11:21
sledges(and rest of HA)11:22
phdeswerAnd situ make sure you move the sensors lib out of the dir. Renaming it makes it still crash there11:22
situIt's from mer-hybris.11:22
sledgessitu: maybe something gotten left behind during merge?11:22
situI have moved libqtsensors_sensorfw.so out of the way.11:22
situsledges: Shouldn't be.11:23
sledgesbaking a u5 image with mer-hybris HA?11:26
situI can try that.11:26
sledges(just in case we still per-used your repos in the past)11:26
situsledges: sudo mic create fs --arch armv7hl --tokenmap=RNDPATTERN:,RNDRELEASE:latest,ARCH:armv7hl,RELEASE:1.0.5.16 --record-pkgs=name,url --outdir=sfa-hammerhead-ea --pack-to=sfa-hammerhead-ea.tar.bz2 installroot/usr/share/kickstarts/Jolla-\@RELEASE\@-hammerhead-\@ARCH\@.ks 2>&1 | tee out.log11:29
situlooks good ?11:29
sledgeswhere is adaptation0 repo pointing?11:31
siturepo --name=adaptation0-hammerhead-@RELEASE@ --baseurl=http://repo.merproject.org/obs/home:/siteshwar:/hw:/hammerhead/sailfish_1.0.5.16_armv7hl/11:32
sledgesand that's from mer-hybris ?11:33
situI didn't get the question.11:33
sledgeshttp://repo.merproject.org/obs/home:/siteshwar:/hw:/hammerhead11:33
sledgesthis ha repo has been built using sources on mer-hybris?11:34
sledgesas opposed to github/siteshwar11:34
* lbt wonders why dhd provided /init-debug when it's already in hybris/hybris- boot ?11:34
situsledges: droid-hal-* packages are going to be picked up from local repository11:35
situWhich specific packages should I check for ?11:35
sledgessitu: dhd and libhybris which links against it ^_^11:36
sledgeseither both should be on obs11:36
sledgesor both locally11:36
situhttps://build.merproject.org/project/show/home:siteshwar:hw:hammerhead11:36
sledgesand for piece of mind: all other ha packages should follow the same logic11:36
situlibhybris is from mer-hybris11:37
sledgessitu: then it's useful to remove dhd from loca lrepo11:37
situdhd I already mentioned is picked up from mer-hybris11:37
sledgesand just have it as a patterns placeholder11:37
* sledges nods11:38
situsledges: Should I delete https://build.merproject.org/package/show/home:siteshwar:hw:hammerhead/droid-hal-hammerhead now ?11:38
sledgessitu: it's not local repo11:38
sledgeslocal repo = repo created with `createrepo` command11:39
situBut we are referencing it locally right ?11:39
siturepo --name=hammerhead --baseurl=file:///home/situ/droid-local-repo/hammerhead11:39
sledgesyes11:39
sledgesfor patterns11:39
sledgesmainly11:40
sledgesbut for package you need to decide11:40
sledgeseither all on obs11:40
sledgesor all on local-repo11:40
sledgesotherwise we end up pulling in dhd from local, but libhybris gets pulled in from obs, where it linked against another dhd11:40
situso should I push file:///home/situ/droid-local-repo/hammerhead to https://build.merproject.org/package/show/home:siteshwar:hw:hammerhead/droid-hal-hammerhead11:40
sledgesare you with me? :)11:41
situI am following you11:41
situso we have some rpm's under file:///home/situ/droid-local-repo/hammerhead11:41
sledgesim not obs expert to answer that if all - local and remote - packages are of _same_ revision, they would link up fine11:41
situwhich should be uploaded to https://build.merproject.org/package/show/home:siteshwar:hw:hammerhead/droid-hal-hammerhead11:41
sledgessitu: it's up to you11:42
sledgesyou know fresh they are11:42
situI will upload the packages to obs repo.11:42
sledgesok11:43
*** hexo is now known as shallow11:46
situsledges: ok, so it's building now https://build.merproject.org/project/show/home:siteshwar:hw:hammerhead11:49
situnow I after it finishes building I can remove following line from my .ks :11:49
siturepo --name=hammerhead --baseurl=file:///home/situ/droid-local-repo/hammerhead11:50
situbecause all these .rpm's are on server now.11:50
sledgesbut then you won't have patterns11:51
sledgesyou should delete droid-hal-*.rpm11:51
situok, I will delete droid-hal-*.rpm from my local file system repo.11:52
* sledges nods11:52
situlbt: Download logfile is not working on this page https://build.merproject.org/package/live_build_log/home:siteshwar:hw:hammerhead/libhybris/sailfish_1.0.5.16_armv7hl/armv8el11:54
situI can't get the full build log.11:54
lbtgrumble11:54
sledgesauth? ;)11:55
lbtI need to do another OBS update soon - I'll leave it until then11:55
lbtsorry for the inconvenience11:55
lbtosc cli should work though11:55
phdeswersitu: if you can try to start with strace -f  (seems it starts always with that) maybe some weird timing issues11:58
situphdeswer: Did you use any of my packages while building ?11:59
phdeswersitu: nope. Have not checked that. Busy fixing kernel bugs11:59
* situ starts building u5 image12:03
situsledges: nothing provides dconf needed by droid-hal-hammerhead-sailfish-config12:06
situremove dconf from patterns ?12:07
sledgeshhhright12:08
sledgesdconf in dhd needs reverting12:08
situsledges: Should I try building u7 instead ?12:09
situLet's try u7.12:11
sledgeshow would that be different from your current img?12:12
* sledges goes away for an hour12:12
situSo I have uploaded hal packages to OBS, and rebuilt hybris and other packages.12:12
sledgesok12:17
*** slate has quit IRC13:25
*** slate has joined #sailfishos-porters13:33
situsledges: Crashing at the same point13:34
sledgessitu: revert dconf and off to u5?13:44
situcan't we debug u7 directly ? :(13:44
situsledges: What if I provide you strace report for both succesful and failed attempts to start lipstick ?13:46
sledgessitu: also an option, i just want to test u5 with latest ha13:46
sledgesto rule out something's left out in ha13:46
sledgessitu: lipstick succeeds to start intermittently?13:47
situsledges: If I make several attempts to start it, it does start.13:47
sledgesrace..?13:48
situsledges: Let me try to get strace for it13:48
sledgesoki13:49
sledgesthanks13:49
situMay be this error is related :13:51
situQPA-HWC: hw_get_module(HWC_HARDWARE_MODULE_ID, (const hw_module_t **)(&hwc_module)) in create returned -213:51
situvgrade: ^ have we seen this before ?13:51
Stskeeps#define ENOENT 2 /* No such file or directory */13:52
situI remember dealing with such error before.13:53
situphdeswer: How did you fix this error ?14:00
phdeswersitu: linked /system/vendor/lib/hw/hwcomposer.ms87something to whatever it was.14:02
phdeswerLet me find yesterdays pastebin14:02
sledgesyet we need to know why it's looking for a wrong one..14:03
phdeswerhttp://pastebin.com/ghzZz7Tt14:04
phdeswerLine 1914:04
phdeswerI think it finds the default first and then tries to find one with hammerhead in it So it having hammerhead in the name moght work too14:06
phdeswerLike I did with the gralloc on line 16 or 1714:06
sledgesbut why not on n514:06
* sledges is looking for a door handle14:06
phdeswersledges: I suspect libhybris linking. CM != AOSP14:07
sledgesphdeswer: yes i read that from you earlier too; quite agree yet how could we validate it14:08
sledgess/n5/u5/14:09
phdeswersledges: different version of CM/libhybris/AOSP used?14:09
situhttp://pastie.org/932676314:10
situLooks like a sensor issue now14:10
situI haven't made gralloc links yet.14:10
phdeswersitu: try strace -f14:11
situmv /etc/xdg/QtProject/Sensors.conf /root14:12
phdeswerThen you can isolate the crash to thread where it happened14:12
situNow I am at this :14:12
situhttp://pastie.org/932677414:12
situphdeswer: grallow.default.so will cause a crash ?14:13
phdeswersitu: yes14:13
situok, moving it14:13
situor rather linking to gralloc.hammerhead.so14:14
phdeswerI don't know why there are two grallocs. You can see they have a different size. crf my pastebin and comments earlier14:14
sledgesthere are twos of many thing we don't know...14:14
sledgesthings*14:14
Stskeeps fwiw, you should not, in any way, need symlinks14:14
Stskeepsif you need symlinks, something else is broken, you should be able to use /system as-is14:14
sledgesyup, in the end need to figure out why it's looking for that file and not for the right one14:15
phdeswerStskeeps: well some boot scripts in android do a lot of linking in /system14:15
situNow crashing at http://pastie.org/932679014:15
phdeswerWhich does not happen now on n514:15
Stskeepshow about you go back to step zero, flash a fresh image, and try to start surfaceflinger?14:15
Stskeepsunder sailfishos setup14:15
Stskeepsif that works, fault is somewhere else14:15
situStskeeps: Yes, we can do that, but let's find out what is missing14:16
Stskeepsjust saying that if things are working like that, something deep is broken, hence me saying it might be better to trace from the beginning :P14:16
situand then several attempts to start lipstick and it comes up.14:18
situStskeeps: How should I track it (after reflashing) ?14:21
situohh ok, will try to start surfaceflinger.14:21
situStskeeps: I reflashed both cm and sailfish images14:28
situand executed '/system/bin/surfaceflinger ' on boot14:28
situI see cm boot screen.14:28
Stskeeps /system/bin/start surfaceflinger right?14:29
situRight, that works too.14:29
situI had executed '/system/bin/surfaceflinger ' earlier.14:29
Stskeepsnod14:29
Stskeepsso obviously the android part of the system works14:29
situok14:30
situStskeeps: ok, what next ?14:33
sledgesis that part already using hwc and gralloc?14:34
*** phdeswer has quit IRC14:35
sledges(you could strace surfaceflinger)14:37
situsledges: or look into /proc14:40
situb6713000-b6716000 r-xp 00000000 b3:19 49176      /system/lib/hw/gralloc.msm8974.so14:40
situb66f2000-b6704000 r-xp 00000000 b3:19 49177      /system/lib/hw/hwcomposer.msm8974.so14:40
situwhich shows both are being used.14:40
sledgeshmph14:40
sledgesgetprop ?14:40
sledgesas the getprop command and internal api systemcall are not sharing same codebase14:40
situhttp://pastie.org/932691014:41
* sledges pull out the door handle14:41
sledges[ro.board.platform]: [msm8974]14:41
sledgescan we find src line in android where it constructs hwcomposer.%s.so ?14:41
sledgesworse if it's %s.%s.so :D14:42
situI don't know who will try to load it.14:43
sledgesfind -exec grep -Hw hwcomposer {} \; | grep -w so14:44
sledgesand go for a tea :))14:44
sledges(filter cpp c h maybe?)14:44
* situ had tea some time back.14:47
* sledges goes for tea ;)14:47
*** slate has quit IRC15:03
*** slate has joined #sailfishos-porters15:10
situsledges: No luck http://pastie.org/932714315:29
situStskeeps: Do you have any wild guess how is the library path chosen ?15:32
situIt's an interesting read http://blog.spreedly.com/2014/06/24/merge-pull-request-considered-harmful/#.U6w9xqbyfeQ15:37
situIn fish shell we never hit the "merge"  button to merge pull requests instead we just rebase it.15:38
situso history looks very clean.15:38
situexcept for pull requests with large changes where we either squash the history or  do a regular merge.15:39
siturunning back home now.15:41
* sledges also dislikes merges15:43
*** vgrade_ has joined #sailfishos-porters16:16
vgrade_situ:looking at that -2 above , I would need to check code at home but try using https://github.com/siteshwar/libhybris/commit/08d55b6f3c393c0b9511a99e0d40356645a724a316:17
vgrade_situ:can you check our IRC logs also for this as it rings a bell with me16:18
sledgesinnterwesting ^_^16:25
situvgrade: QPA-HWC: err in present returned -116:30
situwas the one which we fixed earlier.16:30
situ-2 is new :)16:30
situsledges: https://github.com/CyanogenMod/android_hardware_libhardware/blob/cm-11.0/hardware.c#L12216:35
situI think that's the one we are looking for.16:35
sledgesnice16:36
sledgesand where it's getting the params from16:36
sledgesalso the mechanism it uses, worth examining closely16:37
*** vgrade_ has quit IRC16:50
situsledges: Looks like all the calls to property_get are failing https://github.com/CyanogenMod/android_hardware_libhardware/blob/cm-11.0/hardware.c#L14716:55
situSo it tries to load whatever.default.so16:56
sledgesok16:59
sledgessec16:59
situCould be an isue with bionic code which reads the properties.17:01
sledgeshttps://github.com/mer-hybris/android_system_core/commit/f43d7d43e5b024653ef27724c72104b4a457e00d17:02
sledgesis the one which worked for us for 10.117:02
sledges:17:02
sledgeshttps://github.com/mer-hybris/android_system_core/commit/aca51a667ae30ea33c51ca1599e222d496b0843f17:02
sledgesmeans it cannot be applied straightforwardly across branches17:03
situsledges: but I have already made those changes in my branch and they seemed to work for u5.17:03
sledgesthen we need to figure out exactly why property_get fails17:04
sledgesmaybe property doesn't exist?17:04
situWe saw the properties in output of getprop.17:04
sledgeswhich property is it reading?17:04
sledgesat any rate, we simply need to know why it fails now :)17:05
situhttp://pastie.org/932744717:05
sledgesi remember you had some problems reading kernel property?17:05
situThat was fixed.17:07
sledgesyep ok17:07
situsledges: This part of strace proves that properties are not being read properly  http://pastie.org/932745717:09
sledgesriight17:11
situsledges: but value ro.hardware is being read properly http://pastie.org/932746017:11
sledges8|17:13
*** vgrade_ has joined #sailfishos-porters17:15
sledgesvgrade_: you need to see this17:16
sledges:D17:16
sledges8)17:16
vgrade_remember that android init uses different getprop to other parts of android!17:16
sledgesin the logs, last two pastes17:16
situsledges: Probably that is because value of ro.hardware is being picked up from kernel parameters https://github.com/siteshwar/android_device_lge_hammerhead/commit/28f39bfa23278ba9726412f9ac0ca832c7de879917:16
sledgesso those are the two datasets (cc: vgrade_ )17:17
situvgrade_: [22:39] <situ> sledges: This part of strace proves that properties are not being read properly  http://pastie.org/932745717:17
situvgrade_: [22:41] <situ> sledges: but value ro.hardware is being read properly http://pastie.org/932746017:17
sledgesa code that unifies them17:17
sledgesis missing17:17
sledges(?)17:17
sledgesor just wrong17:17
vgrade_I put this in our shared hammerhead work doc, weeks ago http://pastie.org/932747617:19
sledges;)17:19
vgrade_but this probably related to ro.hardware17:20
vgrade_but interesting that it works sometimes17:21
vgrade_and always for u517:21
situI don't think it ever works.17:22
vgrade_situ: I understood you said earlier it works sometimes if you keep truing17:23
vgrade_at least if it never works with u7 thats a better place to be17:24
situvgrade_: That was after I created symbolic links to load the .so's which have msm8974 in name.17:24
vgrade_situ:ok17:24
vgrade_so multiple overlayed problems17:24
vgrade_situ: is property_service running17:25
situvgrade_: Is it a process ? No.17:25
situNo such process is running.17:25
situhttp://pastie.org/932748617:26
vgrade_situ do we have /dev/socket/property_service17:32
sledgesvgrade_: as per paste yes17:32
sledgesdroid-hal  566          root    6u     unix 0x00000000           10596 /dev/socket/property_service17:32
*** phdeswer has joined #sailfishos-porters17:37
vgrade_so build.prop is where msm8974 comes from17:39
vgrade_any sign of build.prop in the u7 logs situ17:40
situvgrade_: No, I don't see anything related to build.prop17:41
sledgesin journalctl, fresh from boot17:42
sledgesas if it would fail to open it or similar17:42
siturebooting17:42
situI don't see anything related.17:44
situI see many of these however http://pastie.org/932752317:45
situJul 04 20:40:56 Jolla timed-qt5[711]: ERROR: DBus call to interface org.ofono.NetworkTime function GetProperties of path /ril_0 failed: Method "GetProperti...sn't exist17:45
sledgessame rootcause?17:49
vgrade_and there is a build.prop in /system17:49
situvgrade_: Yes17:49
Stskeepswhat does /usr/libexec/droid-hybris/system/bin/getprop <the property that it should find> say?17:50
sledgesand don't say __strchr_* errors :D17:51
vgrade_sledges: ballock17:51
vgrade_:)17:51
sledges:DD17:51
sledgesballocks17:51
vgrade_:)17:51
sledgesyet he had an Archos tablet..17:51
sitush-3.2# getprop ro.board.platform17:52
situmsm897417:52
sledgeswith path17:52
Stskeepsuse full path17:52
situStskeeps: No such file17:53
sledges^_^17:53
vgrade_:)17:53
Stskeepsokay, find -name getprop /usr/libexec17:53
situfind /usr/libexec -name getprop doesn't find anything17:55
sledges8)17:55
vgrade_https://github.com/mer-hybris/droid-hal-device/blob/hybris-10.1/droid-hal-device.inc#L30317:56
vgrade_situ getprop in your droid hal out17:56
situNone of the rpm's has this file.17:57
sledgesin your build tree17:57
situNone of the droid-hal rpm's *17:57
sledgesor in mine :P17:58
situno :(17:58
Stskeeps...17:58
Stskeepswell it's there in the 4.2.217:58
sledgessledges@prospect:~$ ls -l hadk/out/target/product/mako/system/bin/17:58
vgrade_and in our u5 hal17:58
sledgesadb             linker          logcat          servicemanager  updater17:58
vgrade_u5 n5 hal17:59
sledgesok, something got left behind17:59
sledgesduring merge17:59
vgrade_or did not get built in tree17:59
sledgeshybris-hal should build it17:59
Stskeepswell18:00
Stskeepsmaybe it's libhybris that has it18:00
Stskeepsand not in libhybris, but in /usr/bin18:00
sledgesah right, under my mako it's not there either18:01
sledgesin build tree ^^18:01
* sledges does rpm -qf on mako18:01
sledgesgetprop is not there18:01
vgrade_https://github.com/mer-hybris/libhybris/blob/master/libhybris/hybris/properties/properties.c18:02
Stskeepsit's in libhybris18:02
sledgesyep18:02
sledges/usr/bin18:02
sledgesso getprop works18:02
sledgesthe property_get doesn't18:03
sitush-3.2# /usr/bin/getprop ro.board.platform18:03
situmsm897418:03
* vgrade_ has to go home, back in 1:3018:04
situproperty service responds properly to getprop http://pastie.org/932757418:04
situgoing out for dinner brb18:05
* sledges off to the training18:08
situThis issue got automatically fixed18:41
situwill reboot and test again.18:41
*** lbt has quit IRC18:45
*** Aquilum has quit IRC18:45
*** netchip has quit IRC18:45
*** Stskeeps has quit IRC18:45
*** MSameer has quit IRC18:45
*** vgrade has quit IRC18:46
*** Aquilum has joined #sailfishos-porters18:46
*** MSameer has joined #sailfishos-porters18:46
*** netchip has joined #sailfishos-porters18:46
*** lbt has joined #sailfishos-porters18:46
*** Stskeeps has joined #sailfishos-porters18:46
*** vgrade has joined #sailfishos-porters18:46
situI got very less values in getprop after rebooting http://pastie.org/932771918:49
*** lbt_ has joined #sailfishos-porters18:49
*** lbt_ has quit IRC18:49
*** lbt_ has joined #sailfishos-porters18:49
situand on next reboot it shows more values, so behavior of property service is inconsistent.18:52
*** lbt has quit IRC18:56
vgradeif you look at the differences between the properties listed between boots19:31
vgradeis that delta whats in build.prop19:32
situvgrade: I have rebooted now :(19:44
vgradesitu: np19:45
situI don't know what has changed so significantly in u7.19:45
vgradedo we know its u7 or the hal upstream19:47
situnope :(19:48
vgradecertainly seems timing related as one boot gives different results19:48
vgradeto another19:48
vgradeI might get sometime to get my device on u5 and we can compare19:49
sledgessystemd droid-hal-init execution order21:10
tbrvgrade: systemd changed21:12
vgradesledges: tbr another possibility21:15
sledgesyep21:20
sledgesthe cause and ffect21:20
Stskeepsrace condition?21:20
Stskeepsperhaps lipstick starts up before init is really up21:20
vgradethere should be a handshake though at the end of init21:21
vgradeas I recall21:21
vgradebut situ was reporting different getprop results after init21:23
situvgrade: Yes, getprop output may change after each reboot.21:23
vgradeI seem to recall seeing somwhere in android a comment about props and if it was threadsafe21:25
situStskeeps: Can I downgrade systemd to a lower version ?21:30
sledgesboot time optimisations might cause that21:36
vgradeStskeeps: we seem to have a similar check on permissions as we do with qservice in init. https://github.com/siteshwar/android_system_core/blob/hybris-11.0-old/init/property_service.c#L22221:42
situsledges: My journal log http://pastebin.com/2pbZkKB921:42
vgradewonder if new upgrade + this affect props21:43
* vgrade goes to eat21:43
sledgessitu: yet if you launch lipstick from cmdline, it should work everytime (at least get all props)21:45
sledgesgiven enough time since boot21:45
situvgrade: Right, so may be property service itself fails to read the properties while starting ?21:45
situsledges: ^21:46
vgradeunless setprop fails to do its job21:47
situvgrade: I think we should try our older .ks with u7 again and check if we get same issue.21:49
situsledges: I am building using .ks at https://github.com/siteshwar/sailfishos_hammerhead_ks/tree/sailfishos_1.0.7.1621:59
situand expected all the packages to be in mic cache21:59
situbut mic is downloading all the packages again. why so ?22:00
*** slate has quit IRC22:36
*** slate has joined #sailfishos-porters22:42
situI have tried booting 4-5 times using my old .ks and I don't see any issue with property service. Although lipstick automatically came up on 2nd boot only.22:48
situvgrade: It's very consistent, with our old .ks file lipstick automatically comes up on 2nd boot.22:49
*** slate has quit IRC22:59
sledgessitu: and HA is from?23:06
*** slate has joined #sailfishos-porters23:07
vgraderepo --name=hw-hammerhead --baseurl=http://repo.merproject.org/obs/home:/siteshwar:/hw:/hammerhead/sailfish_1.0.7.16_armv7hl/23:08
situhttps://github.com/siteshwar/sailfishos_hammerhead_ks/blob/sailfishos_1.0.7.16/jolla-hammerhead-kickstart.ks#L3023:08
situlipstick still crashes, but for some other reasons than property service.23:09
vgradeso new HA, new jolla repos, different package set23:09
vgradeand posts23:10
vgradesitu what us the crash reson now23:12
vgradereason23:12
sledgessensors?23:14
sledgessame HA23:14
sledgesdiff package set23:14
sledges.urls file pls? ;)23:15
sledgesi could sort and iff it23:15
sledges*diff23:15
sledgesi reckon mic has an option to output .urls file23:16
vgrade--pkglist or smthg23:16
* sledges shuts down, night for tonight!23:18
vgradenn sledges23:18
sledges--record-pkgs=url23:18
sledges(or other options for --record-pkgs)23:19
sledgesno need for full url23:19
sledgesnn23:20
« Wednesday, 2014-06-25 Index Friday, 2014-06-27 »

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!