https://wiki.archlinux.org/title/Unifie … _Boot#shim
and as you use grub
https://wiki.archlinux.org/title/GRUB#Shim-lock

unfortunately this is pretty much where my ability to help ends as i have quite my own view of secureboot
as for why --removable works: i highly suspect your uefi gets confused by the second esp in combination with secureboot - wonder how/why it worked before you started looking into securebokt - maybe some conincidence

Jul 17 20:34:36 archlinux dnsmasq-dhcp[1003]: DHCPREQUEST(virbr0) 192.168.122.29 52:54:00:d9:ba:32
Jul 17 20:34:36 archlinux dnsmasq-dhcp[1003]: DHCPACK(virbr0) 192.168.122.29 52:54:00:d9:ba:32 pepper-mint
Jul 17 20:46:26 archlinux kernel: pci_bus 0000:0c: Allocating resources
Jul 17 20:46:28 archlinux kernel: xhci_hcd 0000:6d:00.0: bad transfer trb length 4 in event trb
Jul 17 20:47:09 archlinux libvirtd[926]: Operation not supported: live attach of device 'graphics' is not supported

I believe the last one is from when I attempted to add spice graphics to the crashed VM in virtmanager. Left out are usb connection messages.

I don't see anything other than my USB devices in dmesg -T from the time of the crash.

 lspci | grep 6d
6d:00.0 USB controller: ASMedia Technology Inc. ASM4242 USB 3.2 xHCI Controller (rev 01)

The VM does respond to ping pepper_mint

01:00.0 VGA compatible controller: NVIDIA Corporation GB203 [GeForce RTX 5070 Ti] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 5310
	!!! Unknown header type 7f
	Memory at d8000000 (32-bit, non-prefetchable) [size=64M]
	Memory at f800000000 (64-bit, prefetchable) [size=16G]
	Memory at fc00000000 (64-bit, prefetchable) [size=32M]
	I/O ports at f000 [size=128]
	Expansion ROM at dc000000 [disabled] [size=512K]
	Kernel driver in use: vfio-pci
	Kernel modules: nouveau

01:00.1 Audio device: NVIDIA Corporation GB203 High Definition Audio Controller (rev a1) (prog-if 00 [HDA compatible])
	Subsystem: NVIDIA Corporation Device 0000
	!!! Unknown header type 7f
	Memory at dc080000 (32-bit, non-prefetchable) [size=16K]
	Kernel driver in use: vfio-pci
	Kernel modules: snd_hda_intel

After shutting down the VM when attempting to restart it.

Error starting domain: internal error: Unknown PCI header type '127' for device '0000:01:00.0'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 67, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
    ~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in tmpcb
    callback(*args, **kwargs)
    ~~~~~~~~^^^^^^^^^^^^^^^^^
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1446, in startup
    self._backend.create()
    ~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/lib/python3.14/site-packages/libvirt.py", line 1401, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: internal error: Unknown PCI header type '127' for device '0000:01:00.0'

manufacturer website says last  BIOS firmware leased 4 months:   2026-03-11
But I saw these messages this week only.

Pretty enough time for update to get into LVFS database. However, fwupdmgr get-history shows nothing. That's strange, indeed.

Maybe it wasn't related to BIOS firmware but some key revocation etc.

Maybe

$ cat /sys/class/dmi/id/bios_version

?

https://archlinux.org/packages/extra/x8 … ugins-all/

after install this i the UI still yelled at me codec not supported. When is the correct way to expect the vlc load those codec?

ss -tulpen | grep -E '59.87'
stat dev/usb/lp*

If you run

dmesg -W

and attach the printer (and power it on) - what tail does that generate?

@dimich, this probably should be fixed upstream, see eg. https://github.blog/security/applicatio … icated-git

Probably not even upstream but at upstream's hosting provider. BTW, almost all links for projects hosted on that site give me 500 Internal Server Error.

There is another repo of this project at github: https://github.com/rustyrussell/ccan, at it looks more up-to-date than at git.ozlabs.org.
Maybe it makes sense to change source URL in sbsigntools package to github.

Intel IPU6 (OV02C10) Webcam on Arch / EndeavourOS
Getting full hardware-ISP quality (factory-calibrated, what Windows/Dell-Ubuntu give you) out of the IPU6 camera.

Tested: Dell XPS 13 9340 · OV02C10 sensor · IPU6 Meteor Lake · EndeavourOS · kernels 7.1.2 and 7.1.3-arch1-3 (survived the bump via DKMS).

Result: /dev/video60 = Intel MIPI Camera, works in Firefox/Zoom/VLC/Teams/OBS, on-demand (LED only lights when an app opens it), boot-persistent, suspend-safe.

Info: There are two paths. Pick one, never mix.

1. libcamera + software ISP: Open source, near-zero setup on kernel ≥ 6.10. But there's no factory calibration, framerate dips, processed on your CPU. Most guides and the "Galaxy Book"-style fix scripts install this.

2. Intel HAL + hardware ISP: Real calibration, hardware processing, proper color, much better image quality.

The following is for option 2:  Intel HAL + hardware ISP.  Mixing them means two stacks contending for the sensor and shadowing each other's libraries.

Part 1 — Quick Installation
1.1 Packages

sudo pacman -S —needed base-devel git v4l2loopback-dkms v4l2loopback-utils v4l-utils
pamac build intel-ipu6-camera-bin intel-ipu6-dkms-git icamerasrc-git v4l2-relayd

1.2 Build the HAL (patch required)

git clone https://aur.archlinux.org/intel-ipu6-camera-hal-git.git
cd intel-ipu6-camera-hal-git

Add this prepare() to the PKGBUILD:

prepare() {
    cd "$srcdir/$_pkgname"
    find . -name CMakeLists.txt -exec sed -i 's/-Werror//g' {} +
    find . -name CMakeLists.txt -exec sed -i 's/-D_FORTIFY_SOURCE=[0-9]//g' {} +
    cd "$srcdir"
}

and these two lines at the top of build():

export CFLAGS="${CFLAGS//-D_FORTIFY_SOURCE=2/} -Wno-error"
export CXXFLAGS="${CXXFLAGS//-D_FORTIFY_SOURCE=2/} -Wno-error"

Then makepkg -si. Confirm: ls -l /usr/lib/libcamhal.so* must resolve to a real file.

1.3 Smoke-test the hardware ISP

sudo modprobe intel-ipu6-psys        # usually auto-loads; check `lsmod | grep psys`
ls -l /dev/ipu-psys0                 # MUST exist
sudo -E gst-launch-1.0 icamerasrc buffer-count=7 ! \
    video/x-raw,format=NV12,width=1280,height=720 ! videoconvert ! ximagesink

live picture here means the hard part is done.

1.4 Relay config

sudo tee /etc/default/v4l2-relayd > /dev/null << 'EOF'
DEVICE=/dev/video60
CARD_LABEL="Intel MIPI Camera"
VIDEOSRC="icamerasrc buffer-count=7"
FORMAT=NV12
WIDTH=1280
HEIGHT=720
FRAMERATE=30/1
EOF

sudo tee /etc/modprobe.d/v4l2loopback.conf > /dev/null << 'EOF'
options v4l2loopback devices=0
EOF

1.5 Readiness script

sudo tee /usr/local/bin/ipu6-camera-ready > /dev/null << 'EOF'
#!/bin/sh
# Exits 0 only when PSYS is up, the sensor is in the media graph, and a
# correctly-labeled v4l2loopback device exists. Triggered by udev.
set -u
LOOPBACK_DEV=/dev/video60
LOOPBACK_LABEL="Intel MIPI Camera"

log() { echo "ipu6-camera-ready: $*"; }
labeled_loopback_exists() {
    grep -qlx "$LOOPBACK_LABEL" /sys/devices/virtual/video4linux/*/name 2>/dev/null
}

if [ ! -e /dev/ipu-psys0 ]; then
    log "waiting for PSYS…"
    i=0
    while [ $i -lt 60 ]; do
        [ -e /dev/ipu-psys0 ] && break
        sleep 0.5; i=$((i + 1))
    done
fi
[ -e /dev/ipu-psys0 ] || { log "FAIL: /dev/ipu-psys0 never appeared"; exit 1; }

[ -e /usr/lib/libcamhal.so ] || { log "FAIL: libcamhal.so missing"; exit 1; }

log "waiting for sensor in media graph…"
i=0; ready=0
while [ $i -lt 60 ]; do
    for m in /dev/media*; do
        [ -e "$m" ] || continue
        media-ctl -d "$m" -p 2>/dev/null | grep -qi 'ov02c10' && { ready=1; break; }
    done
    [ "$ready" -eq 1 ] && break
    sleep 0.5; i=$((i + 1))
done
[ "$ready" -eq 1 ] || { log "WARN: sensor not confirmed; settling"; sleep 5; }

if labeled_loopback_exists; then
    log "loopback already present and labeled"
else
    log "creating labeled loopback at $LOOPBACK_DEV…"
    systemctl stop 'v4l2-relayd@0.service' 2>/dev/null
    modprobe -r v4l2loopback 2>/dev/null
    modprobe v4l2loopback || { log "FAIL: cannot load v4l2loopback"; exit 1; }
    v4l2loopback-ctl add -n "$LOOPBACK_LABEL" -x 1 "$LOOPBACK_DEV" \
        || { log "FAIL: v4l2loopback-ctl add failed"; exit 1; }
fi

i=0
while [ $i -lt 30 ]; do
    [ -c "$LOOPBACK_DEV" ] && break
    sleep 0.2; i=$((i + 1))
done
[ -c "$LOOPBACK_DEV" ] || { log "FAIL: $LOOPBACK_DEV never appeared"; exit 1; }
labeled_loopback_exists || { log "FAIL: loopback not labeled '$LOOPBACK_LABEL'"; exit 1; }

log "ready: PSYS up, $LOOPBACK_DEV labeled '$LOOPBACK_LABEL'"
exit 0
EOF
sudo chmod +x /usr/local/bin/ipu6-camera-ready

1.6 Units + udev trigger

sudo tee /etc/systemd/system/ipu6-camera-ready.service > /dev/null << 'EOF'
[Unit]
Description=Prepare IPU6 camera stack (PSYS + labeled v4l2loopback)
After=systemd-modules-load.service
Upholds=v4l2-relayd@0.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/ipu6-camera-ready

[Install]
WantedBy=multi-user.target
EOF

sudo mkdir -p /etc/systemd/system/v4l2-relayd@.service.d
sudo tee /etc/systemd/system/v4l2-relayd@.service.d/10-restart.conf > /dev/null << 'EOF'
[Service]
RestartSec=5
EOF

sudo tee /etc/udev/rules.d/99-ipu6-camera.rules > /dev/null << 'EOF'
ACTION=="add", KERNEL=="ipu-psys0", TAG+="systemd", ENV{SYSTEMD_WANTS}="ipu6-camera-ready.service"
EOF

sudo systemctl daemon-reload
sudo udevadm control —reload-rules
sudo systemctl enable ipu6-camera-ready.service

1.7 Kill the libcamera duplicate

sudo tee /etc/wireplumber/wireplumber.conf.d/50-disable-libcamera.conf > /dev/null << ‘EOF’
wireplumber.profiles = {
  main = {
    monitor.libcamera = disabled
  }
}
EOF
systemctl —user restart wireplumber pipewire

1.8 Reboot and verify

sudo reboot

systemctl is-active ipu6-camera-ready.service          # active
systemctl is-active ‘v4l2-relayd@0.service’            # active
systemctl show ‘v4l2-relayd@0.service’ -p UpheldBy     # UpheldBy=ipu6-camera-ready.service
v4l2-ctl -d /dev/video60 —info | grep ‘Card type’     # Intel MIPI Camera
wpctl status | grep -iE ‘MIPI|ov02’                    # only Intel MIPI Camera

Resilience check — the relay should come back on its own:

sudo systemctl stop ‘v4l2-relayd@0.service’; sleep 8; systemctl is-active ‘v4l2-relayd@0.service’

Part 2 — Design Choices & Pitfalls
Why each piece is the way it is, and what bites you if you deviate. Every pitfall below was hit for real.

• 2.1 Why the proprietary path at all — and why “obsolete” is a lie

  • Choice: use Intel’s out-of-tree PSYS + HAL rather than libcamera.

  • The trap: intel-ipu6-dkms-git’s AUR page says ”This package is obsolete! Linux kernel 6.10 onwards now has built-in IPU6 drivers and this package will no longer work. Uninstall it.” Its maintainer also wrote ”IPU6 is so horrendous I’ve basically given up on it.” Intel’s own repos target kernel 6.12/Ubuntu 24.04, and patch/v7.0/in-tree-build/ is empty — no PSYS build workaround for kernel 7. Every signal says stop.

  • The reality: those warnings refer to the sensor and ISYS drivers, which are in-tree now. PSYS never went in-tree — Intel keeps the hardware-ISP algorithms proprietary. It’s a separate module, still required, and the DKMS package still builds it fine on 7.x despite the missing patch directory.

  • How to check for yourself rather than trust the warning:

    sudo find /usr/lib/modules/$(uname -r) /var/lib/dkms -iname ‘*psys*’
    sudo find /var/lib/dkms/ipu6-drivers -name make.log -exec tail -20 {} \;;

    If you see LD [M] …/psys/intel-ipu6-psys.ko and exit code: 0, it built. That single check is what this entire guide rests on.

• 2.2 The HAL build patch

  • Choice: strip -Werror and the fortify redefinition.

  • Pitfall: makepkg injects -D_FORTIFY_SOURCE=2; the HAL’s CMake sets it too; GCC warns about the redefinition; -Werror promotes it to fatal. Build dies at ~0% on I3AControlFactory.cpp.

  • Pitfall: old AUR comments suggest patches for intel-ipu6ep-camera-hal-git (the deprecated Alder-Lake-only package) with different CMake flags like -DIPU_VER. Don’t apply them — the current unified package uses -DIPU_VERSIONS=”ipu6;ipu6ep;ipu6epmtl” and those old diffs will break it differently.

  • Watch for: if stripping -Werror reveals a genuine C++ error deeper in (not a promoted warning), you’ve hit a real toolchain incompatibility that needs source patches nobody has written. That’s the point to stop.

• 2.3 PSYS doesn’t need forcing — but check

  • Choice: rely on modalias auto-loading.

  • Pitfall: the obvious move is /etc/modules-load.d/ipu6-psys.conf. Usually unnecessary — the kernel matches the PCI device and loads intel_ipu6_psys on its own. Verify with lsmod | grep psys after a clean boot before adding anything.

  • Pitfall: /dev/ipu-psys0 existing does not mean the stack is usable — see 2.6.

  • Note: early dmesg shows deferred probe pending: intel-ipu6: IPU6 bridge init failed. That’s normal; it resolves later in boot. Don’t chase it.

• 2.4 Why a relay at all

  • Choice: bridge icamerasrc → v4l2loopback via v4l2-relayd.

  • Why: icamerasrc is a GStreamer element. Firefox, Zoom, VLC, Teams, OBS don’t speak GStreamer — they want a /dev/video* node. The relay runs the HAL pipeline and writes frames into a virtual camera every app can open.

  • Bonus: v4l2-relayd is on-demand — it only runs the pipeline when an app opens the device, so the camera LED stays dark and CPU stays idle otherwise. Don’t replace it with an always-on gst-launch service; you'd lose that and light your LED 24/7. (Verify with: LED off at idle, ps aux | grep -c ‘icamerasrc’ → 1, the daemon itself.)

  • Nice detail: the shipped unit already has DeviceAllow=char-intel-ipu6-psys — this package was written with IPU6 in mind.

• 2.5 The device-number trap — use video60, not video0

  • Choice: pin the loopback to /dev/video60.

  • Pitfall: the obvious move is video0 (apps default to it). Don’t. The in-tree ISYS driver creates ~48 raw nodes that claim video0 upward, and their numbering shifts between boots (I saw 41 nodes one boot, 48 the next). Ask for video0 and you’ll either get failed to create device: File exists, or get silently bumped elsewhere while a raw ipu6 node squats at video0 — apps then find garbage where the camera should be. Symptom: v4l2-ctl -d /dev/video0 —info reports Card type: ipu6 at 3840x2160.

  • Pitfall: options v4l2loopback devices=1 auto-creates an unlabeled “Dummy” device at load that collides with the one you want. Use devices=0 and let the script create exactly one, explicitly.

  • Note: DEVICE= in /etc/default/v4l2-relayd is nearly decorative — the unit’s ExecStart greps /sys/devices/virtual/video4linux/*/name for CARD_LABEL. The label is what matters; keep DEVICE= accurate anyway.

• 2.6 Why udev triggers it, not a boot target

  • Choice: ACTION==”add”, KERNEL==”ipu-psys0”, TAG+=”systemd”, ENV{SYSTEMD_WANTS}=”…”.

  • Why: the kernel tells you when PSYS exists. Hanging the service off basic.target means guessing whether PSYS is there yet — the device event is the readiness signal, so the ordering problem disappears structurally.

  • Pitfall: TAG+=”systemd” is mandatory. Per systemd.device(5), SYSTEMD_WANTS “is not taken into account unless the device is tagged with the systemd tag” — without it the rule silently does nothing.

  • Pitfall: systemd “will only act on Wants= when a device first becomes active”. Testing with udevadm trigger fires udev but not necessarily the systemd side. Only a real reboot proves this.

• 2.7 Why `sleep 5` had to go

  • Choice: poll media-ctl for the sensor instead of sleeping.

  • Why: PSYS appears before the IPU6 stack is usable — the kernel does a deferred probe and the sensor lands in the media graph a moment later. The original design covered this with sleep 5: a magic number that’s a guess, breaks if a future kernel is slower, and wastes time if it’s faster.
    Polling for the actual condition (media-ctl -d /dev/mediaN -p | grep ov02c10) returns in 0s on this hardware and self-adjusts elsewhere.

  • Pitfall: don’t hard-fail if media-ctl is missing or the graph names things differently on other hardware — fall back to a settle delay. Insurance, not a tripwire.

• 2.8 Why two units — you cannot merge them

  • Choice: a separate unsandboxed ipu6-camera-ready.service does privileged setup; the relay only relays.

  • This looks redundant. It is not optional. v4l2-relayd@.service ships with:

    CapabilityBoundingSet=          # empty — NO capabilities
    DevicePolicy=closed
    DeviceAllow=char-video4linux
    DeviceAllow=char-intel-ipu6-psys

  • Pitfall (tested): folding modprobe + v4l2loopback-ctl add into the relay’s own ExecStartPre fails with:
    unable to open control device ‘/dev/v4l2loopback’: Operation not permitted
    No CAP_SYS_MODULE, and /dev/v4l2loopback isn’t in the DeviceAllow list. The relay deliberately cannot load modules or create loopbacks. Merging means gutting the packager’s security hardening to save one file. Bad trade. The split is forced by the sandbox.

• 2.9 `Upholds=`, not `Wants=` — the subtle one

  • Choice: Upholds=v4l2-relayd@0.service in the ready unit.

  • Pitfall (cost several reboots): Wants= looks right and fails silently. Per systemd.unit(5), if the wanted unit “cannot be added to the transaction, this has no impact on the validity of the transaction as a whole, and this unit will still be started.” Observed result: ready runs perfectly, relay gets no start job at all, nothing logged in either journal, systemctl show … -p ConditionResult shows a stale no. Nothing tells you it was dropped.

  • Why Upholds= works: it’s “similar to Wants=, but as long as this unit is up, all units listed are started whenever found to be inactive or failed, and no job is queued for them.” No job = nothing to silently drop. And the continuous effect restarts the relay for free if it dies — Restart=always becomes redundant.

  • Pitfall Mechanism: RemainAfterExit=yes is load-bearing. Upholds= only holds while the unit is up; a Type=oneshot without it goes inactive the instant the script exits, and the relationship evaporates.

  • Pitfall — the deadlock: using ExecStartPost=/usr/bin/systemctl start v4l2-relayd@0.service while the relay has After=ipu6-camera-ready.service hangs forever: systemctl start blocks on the relay → relay waits for ready → ready can’t finish. You’ll see ready stuck activating with └─ /usr/bin/systemctl start v4l2-relayd@0.service in its CGroup. If you must use ExecStartPost, add —no-block.

  • Pitfall: do not add After=ipu6-camera-ready.service to the relay alongside Upholds=. It creates an unresolvable transaction and the relay’s job gets silently dropped. Upholds= only fires once the upholder is active — the ordering is already implicit.

  • Verify it registered: systemctl show ‘v4l2-relayd@0.service’ -p UpheldBy → UpheldBy=ipu6-camera-ready.service. Empty means it didn’t take.

• 2.10 Hiding the duplicate and the clutter

  • Choice: disable libcamera in WirePlumber; accept the raw-node clutter.

  • Why disable libcamera: it independently exposes the sensor as an ov02c10 PipeWire source — the worse Path-A camera. It’s not just a cosmetic duplicate: both paths read the same ISYS nodes, so picking it can contend with your HAL stack for the sensor.

  • Pitfall: matching by node name doesn’t work — those nodes are named v4l2_input.pci-0000_00_05.0.x and ipu6 only appears in the description. Disabling the whole libcamera monitor via wireplumber.profiles is cleaner and survives.

  • Accept this: VLC and other raw-V4L2 apps will always list ~48 ipu6 devices. They enumerate /dev/video* directly, ignoring PipeWire rules — and they’ll list nodes even with permissions stripped (I tried TAG-=”uaccess”, GROUP=”root”, MODE=”0660” — the nodes became inaccessible but VLC still showed them). They can’t be removed without unloading the driver your camera needs. Pick “Intel MIPI Camera” and move on; this is not worth fighting.

• 2.11 Gotchas that will waste your afternoon

  • Firefox caches its camera list. If it “stops seeing” the camera, pkill firefox and reopen before debugging anything else. This wasted time twice.

  • csi2-4 error: Frame sync error floods dmesg constantly. Benign. Ignore.

  • Upside-down image? Mine was inverted mid-setup and came up correct after a full reboot. Try that before adding videoflip method=rotate-180. Left/right mirroring in self-view is normal — the far end sees you correctly; do not add a horizontal flip.

  • v4l2-relayd.service (non-templated) is ExecStart=/bin/true. That’s correct — it’s a grouping anchor. The real worker is the templated v4l2-relayd@0.service. Enabling the wrong one does nothing.

  • Kernel updates: survived 7.1.2 → 7.1.3 with DKMS rebuilding PSYS automatically. If a kernel ever breaks the build you silently lose the hardware ISP — check /var/lib/dkms/ipu6-drivers/*/*/log/make.log.

  • Back up your config. Reconstructing the patched PKGBUILD and unit files from scratch is genuinely painful.

In doubt post your complete system journal for the boot after such failure

sudo journalctl -b | curl -s -H "Accept: application/json, */*" --upload-file - 'https://paste.c-net.org/'

Why is the executable stored in ~/.config/discord/app*/Discord at all?

This I don't understand. I only installed the discord from Archlinux repository. Could it be an in-app update that would have fired and set itself as the new default Discord?

Indeed when I toggle the autostart option from within Discord (being run from /usr/bin), it creates a desktop entry in the .config/autostart, where the ExecBin targets the .config/discord/app-X.XX.XXX/Discord file.
I untoggled the option and created manually the symlink to the package desktop entry, then when restarting Discord, it considers the option being toggled on again. Won't it overwrite the autostart entry during next update (using pacman/wrapper)? I'll wait and see.

If it does, I'll remove the package and the whole .config/discord directory, I'll reinstall it and see if the behavior differs.

I was just wondering if anyone encountered the same behavior, and if anyone did, if they know what fires it.

Aside, I tried to install and start UWSM, but that delays the session start quite a bit, and crashes often.

That was just a question, not a suggestion

Absolutely not.

I was also able to drop the `--enable-global-vaapi-lock` flag. However, beware the Chromium team put hardware acceleration on NVIDIA behind a feature flag: `--enable-features=VaapiOnNvidiaGPUs`. I'm also enabling `AcceleratedVideoDecodeLinuxZeroCopyGL`; not sure if it's needed but it doesn't hurt to have it I guess... (: