Strange. Sensing network presence this way and modified grep indeed works w/o core dump. Thanks a lot.
I’m a bit surprised as my previous solution worked for me many years. But core dump is a bit much anyway. I wonder what changed: nmap, kernel or build process? I would like to report a bug but it helps if I would know where 
. Can anyone give me a hint please?
Since this update, Megapixels on the original PinePhone produces black&white JPEGs with a Moiré-type pattern (probably a Bayer pattern) instead of colored JPEGs. Looks like debayering is not being done.
In the Megapixels preview, everything looks nice and colored (even the small preview of the taken picture in the button in the bottom row), but when I open the JPEG in anything, it shows as Bayer.
And I can confirm it is a Bayer pattern, G’MIC-Qt’s Bayer filter with starting pattern Green-Blue reconstructs the colors, sorta. (It neither smoothes out the Bayer pattern nor applies a color correction matrix, so the result is suboptimal, but it proves that it is definitely a Bayer pattern that is stored in the JPEG instead of a decoded image.)
The issue seems to be with the metadata in the DNG because both dcraw and dcraw_emu on the computer also fail to debayer those DNGs whereas they debayer DNGs from before the update just fine.
Looking at the exiftool output, the CFA (color filter array) information is missing from the metadata:
-CFA Repeat Pattern Dim : 2 2
-CFA Pattern 2 : 2 1 1 0
-CFA Pattern : [Blue,Green][Green,Red]
This script works as a workaround, both on the computer and (after installing perl-image-exiftool that was not installed) on the PinePhone itself (the postprocessing commands are adapted and simplified from /usr/share/megapixels/postprocess.sh, e.g., no need to check whether exiftool is installed because the script needs it anyway to fix the DNG):
#!/bin/bash
if [ "$#" -ne 1 ]; then
echo "Usage: $0 target[.dng]"
exit 1
fi
TARGET="$1"
TARGET="${TARGET%.dng}"
echo "fixing $TARGET.dng..."
exiftool "-CFARepeatPatternDim=2 2" "-CFAPattern=[Blue,Green][Green,Red]" "-CFAPattern2=2 1 1 0" -P -overwrite_original "$TARGET.dng" || exit $?
echo "redoing the postprocessing..."
dcraw_emu +M -H 4 -o 1 -q 3 -T -fbdd 1 "$TARGET.dng" || exit $?
convert "$TARGET.dng.tiff" -sharpen 0x1.0 -sigmoidal-contrast 6,50% "$TARGET.jpg" || exit $?
exiftool -tagsFromfile "$TARGET.dng.tiff" -software="Megapixels" -overwrite_original "$TARGET.jpg" || exit $?
rm -f "$TARGET.dng.tiff"
echo "wrote $TARGET.jpg"
exit 0
Since those tags are unconditionally written to the DNG by the Megapixels source code, and since Megapixels was not updated, I suspect the libtiff 4.5.1 upgrade (upgraded from 4.5.0 in this update set) as the likely culprit. (It seems to be losing or incorrectly setting these tags.)
Alarm stop update again for days/week.
So what you expect? Does a repackage solves it or does some code need to be adjusted? Did you report your findings also upstream? Issues · postmarketOS / megapixels · GitLab
Well, what can I say. ALARM is a community project. They do a push to mirrors and only when they have completed a set of packages. Plus compiling ARM packages take longer … Commits · archlinuxarm/PKGBUILDs · GitHub
1 Like
Well, I was first trying to debug what is actually at fault. I am going to report this to Megapixels upstream, though it looks like a libtiff regression to me.
This quick hack:
sudo sed -i -e '29i exiftool "-CFARepeatPatternDim=2 2" "-CFAPattern=[Blue,Green][Green,Red]" "-CFAPattern2=2 1 1 0" -P -overwrite_original "$MAIN_PICTURE.dng"' /usr/share/megapixels/postprocess.sh
i.e., inserting above line 29 of /usr/share/megapixels/postprocess.sh the line:
exiftool "-CFARepeatPatternDim=2 2" "-CFAPattern=[Blue,Green][Green,Red]" "-CFAPattern2=2 1 1 0" -P -overwrite_original "$MAIN_PICTURE.dng"
makes Megapixels produce working images again (assuming perl-image-exiftool is installed, otherwise it will fail, so run sudo pacman -S perl-image-exiftool first). But it is a hack that papers over the real issue.
Filed:
I may end up filing an issue at `libtiff’ upstream as well, depending on what Megapixels upstream says.
I just used the manjaro-arm-installer and build myself an rpi installation.
Mounting the sd-card before booting from it and pacman.conf includes following lines:
[core]
Include = /etc/pacman.d/mirrorlist
[extra]
Include = /etc/pacman.d/mirrorlist
[community]
Include = /etc/pacman.d/mirrorlist
Maybe the script needs to be updated somewhere?
Hi,
Unexpected restart after overheating in the middle of the update.
My pinebook pro won’t restart.
Fully encrypted root partition with LUKS on SD card. The linux kernel loads, but I don’t get the prompt to decrypt the LUKS volume.
The volume can be decrypted by moving the SD card to another pinebook pro.
Guess I need to chroot myself and finish the update. But how to do it?
NOTE: All backups are OK.
edit: update OK after:
arch-chroot /mnt/sdcard
rm /var/lib/pacman/db.lck
pacman -Syu
However, the sdcard do not boot.
I suppose the problem is on the boot partition, not on the root partition.
How to fix the boot partition, for boot on the LUKS volume?
＠philm, can you build toolchain for user, others we build ourself?
whtat exactly do you mean by toolchain?
There is a new pull request: Workaround libtiff-4.5.1 (!32) · Merge requests · postmarketOS / megapixels · GitLab
1 Like
never mind, found you(Alarm) update again, thanks.
I have noticed you have issued a megapixels-1.6.1-2 update with that fix. I can confirm that this fixes the issue without my exiftool workaround in postprocess.sh. (Updating the package removed my hack from the script, and I still get correctly colored images, so the hack is no longer needed.) Thanks.
Inxi is up to date 
Manjaro arm go on !
1 Like
Latest chatty update causes the program to fail launching directly. In terminal:
chatty: symbol lookup error: undefined symbol: _ZN41i18n12phonenumbers11PhoneNumberC1EPN6google8protobuf5ArenaE
However, when a SMS is received and “open” is clicked from the notification area, it launches correctly.
Fixed with chatty 0.7.3-2.0 coming along soon.
1 Like
The spacebar-23.01.0-3 build that was pushed today does not launch at all, due to a missing symbol, similar to the chatty one (if not the exact same one). Downgrading to spacebar-23.01.0-1 fixes it. You probably need to rebuild spacebar against the stable packages as you did with chatty.
On the plus side, the plasma-mobile-5.27.7-1 build that was pushed at the same time seems to work.
I just pushed pkgrel 4. Please try again. Thank you.
2 Likes
Done. Works. Thanks!
1 Like