#266 support conditions on build manifests 7 days ago

Ticket created by ~mvdan on ~sircmpwn/git.sr.ht

For example, imagine that some of the repos in 'sources' are private repositories, so they only work if the user has set up the right SSH keys. For an open source project, this can mean that the manifest succeeds when run on the original repo, but fails when run on forks.

It would be useful to be able to specify a condition expression, which would make the entire manifest be skipped if it evaluates to false. For example, assuming the right environment variables:

sources:
 - git@git.sr.ht:~foobar/privaterepo
condition: $JOB_OWNER == "foobar"

The syntax is up for debate, but we could continue mimicking shell semantics and use the same logic as (( expr )):

if ! (($JOB_OWNER == "foobar")); then
    skip-job
fi

#260 Allow enabling official Arch repositories 17 days ago

Ticket created by ~mvdan on ~sircmpwn/builds.sr.ht

For example, [multilib] is disabled by default, and it contains many useful packages like wine.

There are also others, like [testing] and [community-testing].

The current workaround is to enable them with a specific mirror and a specific key from an existing Arch developer, for example:

repositories:                                                                        
  multilib: http://mirror.rackspace.com/archlinux/multilib/os/x86_64#c100346676634e80c940fb9e9c02ff419fecbe16

This is far from ideal, though. The recommended way to enable repos like multilib is just:

[multilib]
Include = /etc/pacman.d/mirrorlist

This issue is about enabling just that, removing the need to hard-code an arbitrary mirror and key ID. For example:

repositories:                                                                        
  multilib: included

#29 Wayland window bar 18 days ago

Comment by ~mvdan on ~eliasnaur/gio

Ah, excellent :) I was fearing that there would be no such negotiation mechanism.

#27 Using 'go run' with a different target 18 days ago

Comment by ~mvdan on ~eliasnaur/gio

Jesus, I always fail at formatting here.

DISPLAY= ./gio-app # enforce Wayland, by ensuring it can't talk to X11
WAYLAND_DISPLAY= ./gio-app # the oppposite of the line above

#27 Using 'go run' with a different target 18 days ago

on ~eliasnaur/gio

REPORTED RESOLVED FIXED

#27 Using 'go run' with a different target 18 days ago

Comment by ~mvdan on ~eliasnaur/gio

Yep, this is now done.

One can also force the selection at run-time, if a binary supports both X11 and Wayland, and both are running locally. For example:

DISPLAY= ./gio-app # enforce Wayland, by ensuring it can't talk to X11 WAYLAND_DISPLAY= ./gio-app # the oppposite of the line above

#29 Wayland window bar 18 days ago

Comment by ~mvdan on ~eliasnaur/gio

Just as a data point - we shouldn't always draw client-side decorations when the server doesn't provide any. On tiling window managers like Sway, a window works just fine without decorations, and most work that way.

I guess it's fine if we use a decoration in that case, but for tiling window manager users, it's wasted space. It would be nice if Gio is smart enough to only draw client-side decorations when the server requires the clients to do so, or when we can detect that the server doesn't provide decorations and isn't a tiling WM.

#84 android logs should use the configured appid 30 days ago

Comment by ~mvdan on ~eliasnaur/gio

Cool. I'll see if I can get a working patch once the android e2e test is merged.

#84 android logs should use the configured appid a month ago

Ticket created by ~mvdan on ~eliasnaur/gio

Right now, on Android, stdout and stderr are recorded as log messages. That's good, because it helps with debugging.

However, the tag is simply gio. I think it should be something more unique. How about the app ID set via gogio -appid?

Here's a concrete use case: I'm writing end-to-end tests for Android, and filtering by the tag gio isn't unique at all. If another gio app happens to be running on the same device or emulator, I might be in trouble.

#28 end to end testing 2 months ago

Comment by ~mvdan on ~eliasnaur/gio

I think this is resolved, with basic coverage for x11, wayland, and JS.

REPORTED RESOLVED FIXED