Skip to content
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -16,3 +16,6 @@ RECOVER_*.fla

# Mac junk
.DS_Store

# Generated by Make
ruffle_desktop
33 changes: 33 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
.PHONY: all clean distclean install uninstall version deb

prefix ?= /usr/local
VERSION := $(shell echo $(notdir $(CURDIR)) | tr -cd '0-9')
ifeq ($(VERSION),)
VERSION := $(shell date +%Y%m%d)
endif
Copy link
Member

@kjarosh kjarosh Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be needed after the changelog starts being properly updated. (Not to mention it doesn't work properly.)


all: ruffle_desktop

clean:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't it also clean the ignored files in /debian?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will add this later

-rm -f ruffle_desktop
-rm -rf target

distclean: clean

ruffle_desktop:
cargo build --release --package=$@
install -m755 target/release/$@ ./$@

install: ruffle_desktop
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you missed some stuff. We have a desktop file, metainfo, and an icon which should be installed too, along the binary.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add them later.

install -d $(DESTDIR)$(prefix)/bin/
install -m755 $^ $(DESTDIR)$(prefix)/bin/

uninstall:
-rm -f $(DESTDIR)$(prefix)/bin/ruffle_desktop

version:
@echo $(VERSION)
@sed -i '1s/([0-9]\{8\})/($(VERSION))/' debian/changelog
Copy link
Member

@kjarosh kjarosh Dec 1, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be needed after the changelog starts being properly updated.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep


deb: version
dpkg-buildpackage -us -uc
7 changes: 7 additions & 0 deletions debian/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
/*.substvars
/.debhelper/
/debhelper-build-stamp
/files
/ruffle/
/ruffle.debhelper.log
/tmp/
5 changes: 5 additions & 0 deletions debian/changelog
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
ruffle-nightly (20251201) UNRELEASED; urgency=medium
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changelog should start empty, and it should be updated by the .github/scripts/release.py script.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without this I can't test the whole thing.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that changelogs are generated upon creating releases (where they're never been written into repository files before creation of the corresponding tag). Maybe we should write a log somewhere in repository everytime a pull request is merged?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to leave an empty changelog, we'll only be packaging releases, no?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we use the version we have in Cargo.toml? Why does it say ruffle-nightly?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I initially get this from tags (which are nightly). Will change to that in Cargo.toml later.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using approach (1) (building using the repo), this should automatically read the version from Cargo.toml, or using approach (2) (building from an external source), the version can be updated in the release script.


* Initial release.

-- unknown <localhost> Fri, 28 Nov 2025 16:38:58 +0800
24 changes: 24 additions & 0 deletions debian/control
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
Source: ruffle-nightly
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you put all these files (including the Makefile) in ruffle/desktop/packages/linux/debian? If this produces more than one package (or has a potential to), it should be placed in a subdirectory there, e.g. ruffle/desktop/packages/linux/debian/ruffle, similarly to AUR

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This debian directory has a 3.0 (native) format, which has to be in root directory of source code. Maybe we should use the more complicated 3.0 (quilt) format?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Disclaimer: I'm not very proficient in debian packaging)

I think we have to talk through the general approach of building the package. I see two approaches: (1) build based on the repository, and (2) build from an external source.

Currently, we have a bit of a mix of both, but I would personally prefer the (2) approach. That's how we did AUR and Flatpak, and it just makes it easier for everyone, because packaging is not tightly coupled with the repo, and there's a hierarchy: the repo (upstream) decides how it should be built, and the package (downstream) builds it the way it should. This also fits with the general approach to packaging software, where the downstream is a separate repo.

So I would really prefer this approach, and IIUC it currently works a bit like that? Based on what you said about the tags and tarballs. But on the other side it doesn't, because it requires to be in a specific directory. Could you elaborate on the flow? Like a step by step instruction on how to produce a package with this PR? I think the (2) approach I described should be easily doable in ruffle/desktop/packages/linux/debian—the packaging code would just download the source (the tarball) and do the build as it wishes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Debian packaging tools won't download source code; apt source does (it requires a source repository).

AFAIK:

3.0 (native) tries to build from where the debian directory is, and build the source as-is. It also build a source tarball outside the source directory (with local changes). Revisioning is not allowed.

3.0 (quilt) requires a properly named source tarball to be placed along with the source directory, and will verify the source tree with the tarball (any local file changes should be in separated patches rather than the source tree). Revisioning is required. A .dsc file and .debian.tar.xz (containing the whole debian directory with control, changelog, rules, patches, etc.) is created during build (for properly extract the source with dpkg-source -x)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, based on what I read about the difference between (native) and (quilt), (quilt) would fit better for Ruffle, as it's not a Debian-native application. We're building a Debian package as a downstream, and coupling Ruffle with Debian that tightly could be problematic IMO.

But the main question is: what do we do with this debian packaging config? Do you want Ruffle to be published in Debian repos? Is it meant to be available for users to build? Do you want us to provide .deb packages for each release?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this (I'm not a debian maintainer)... Maybe it's a good start to have debian scripts in repository.

Copy link
Member

@kjarosh kjarosh Dec 2, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm asking because I don't see how we could use those scripts in the first place. I see issues with every application, but it would be useful to focus on the one we're planning to use, because we need to somehow address those issues before we can merge.

The main issue I see is that Ruffle does not have stable releases (and it's not gonna happen soon, the community doesn't want that), and is inherently incompatible with how Debian releases software and their stabilization process. Dependencies in Debian repos are old compared to what Ruffle uses, and we have no way of supporting older releases. It means that Debian users (using the latest Debian release) would have to use a ~8 months old Ruffle release without any patch in between the release date and today. Something is broken in Ruffle on Debian? You have to wait a year before you can enjoy the fix. (And that is without the guarantee that something else doesn't get broken by the way.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you get the source package? Why does it have "nightly" in name, but this package doesn't?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd reconsider this later...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to have a CI set up so that this package is being built automatically. Otherwise it will decay, and merging it doesn't make sense, because we won't be supporting it properly.

It doesn't have to produce release artifacts yet, but it should be built at least once per day to make sure it doesn't start failing.

Section: misc
Priority: optional
Maintainer: unknown <localhost>
Rules-Requires-Root: no
Build-Depends:
debhelper-compat (= 13),
rustc (>= 1.86),
cargo (>= 1.86),
libasound2-dev,
libudev-dev,
Standards-Version: 4.7.2
Homepage: https://ruffle.rs/
#Vcs-Browser: https://github.com/ruffle-rs/ruffle
#Vcs-Git: https://github.com/ruffle-rs/ruffle.git

Package: ruffle
Architecture: any
Depends:
${shlibs:Depends},
${misc:Depends},
Description: A Flash Player emulator written in Rust
Ruffle is an Adobe Flash Player emulator written in the Rust programming
language. Ruffle targets both the desktop and the web using WebAssembly.
55 changes: 55 additions & 0 deletions debian/copyright
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: https://github.com/ruffle-rs/ruffle
Upstream-Name: ruffle
Upstream-Contact: kjarosh <[email protected]>

Files:
*
Copyright:
2021-2025 Aaron1011 <[email protected]>
2021-2025 Bale001
2016-2025 Herschel <[email protected]>
2023-2025 kjarosh <[email protected]>
2019-2024 kmeisthax
2022-2025 n0samu
2023-2025 sleepycatcoding
2020-2025 Toad06
2020-2025 torokati44 <[email protected]>
License: Apache-2.0 OR MIT

License: Apache-2.0
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
.
https://www.apache.org/licenses/LICENSE-2.0
.
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
.
On Debian systems, the full text of the Apache Software License version 2 can
be found in the file `/usr/share/common-licenses/Apache-2.0'.

License: MIT
Permission to use, copy, modify, and distribute this software and
its documentation for any purpose and without fee is hereby
granted, provided that the above copyright notice appear in all
copies and that both that copyright notice and this permission
notice appear in supporting documentation, and that the name of
Giampaolo Rodola' not be used in advertising or publicity pertaining to
distribution of the software without specific, written prior
permission.
.
ISSUER DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
NO EVENT Giampaolo Rodola' BE LIABLE FOR ANY SPECIAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN

22 changes: 22 additions & 0 deletions debian/rules
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
#!/usr/bin/make -f

# See debhelper(7) (uncomment to enable).
# Output every command that modifies files on the build system.
#export DH_VERBOSE = 1


# See FEATURE AREAS in dpkg-buildflags(1).
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all

# See ENVIRONMENT in dpkg-buildflags(1).
# Package maintainers to append CFLAGS.
#export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
# Package maintainers to append LDFLAGS.
#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed


%:
dh $@

override_dh_auto_install:
dh_auto_install -- prefix=/usr
1 change: 1 addition & 0 deletions debian/source/format
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
3.0 (native)
Loading