Support for installing in apt (.deb) #31

maltfield · 2022-07-22T13:03:38Z

Feature request: create a .deb and work with Debian to add this software to the main Debian repos

maltfield · 2022-10-14T13:43:06Z

@fmarier (one of our users and a Debian Member) just submitted an RFP to add BusKill to the repos a couple days ago:

https://www.mail-archive.com/[email protected]/msg1873862.html

maltfield · 2022-10-14T13:53:37Z

I wanted to read about how RFPs work, but I got "403 Forbidden" trying to access the wiki

https://wiki.debian.org/RFP

@fmarier I almost-always get 403 errors trying to access the debian wiki. Is there any way you can have them not block VPN users? It's surprisingly anti-privacy for the debian project :(

fmarier · 2022-10-14T17:03:45Z

I almost-always get 403 errors trying to access the debian wiki. Is there any way you can have them not block VPN users? It's surprisingly anti-privacy for the debian project :(

Hm, that's weird. I can't imagine that being done on purpose. Probably just some false positive from an anti-abuse system of some sort. I see some IP-blocking logic in https://salsa.debian.org/debian/wiki.debian.org/-/tree/master/bin. Here what the FAQ (on the wiki of course!) says:

Access to wiki.debian.org is blocked with 403 Forbidden
Please mail [email protected] with your IP address.

Other ways to reach them:

Interacting with the team
Read the FAQ first: DebianWiki
Read about contacting us: DebianWiki/Contact
Email contact (public): [email protected]
Email contact (private): [email protected]
Bug reports: wiki.debian.org
Public IRC channel: #debian-www on OFTC (webchat)

fmarier · 2022-10-14T17:08:17Z

https://wiki.debian.org/RFP

Here's what that page currently says:

A Request for Package (RFP) is a Debian bug report of the Work-Needing and Prospective Packages (WNPP) family.

You use an RFP when:

You would like to see some software packaged for Debian

It is not packaged yet (see https://packages.debian.org/ to check)

No RFP or ITP has already been sent for this package (use the wnpp.debian.net service, the WNPP-by-tags service, or search in the wnpp pseudo-package at the BTS or the WNPP package lists)

It is eligible for inclusion into Debian (for example, it is DFSG-free). Also, check the available list at https://www.debian.org/devel/wnpp/unable-to-package

New entries can be submitted via email or with reportbug, as described at https://www.debian.org/devel/wnpp

So basically, it's a "Request for Package", as opposed to "Intent to Package". I am planning to convert it into an ITP once I've got a bit of time to do it, but I filed it as an RFP in case someone else is keen to get it done right now and upload it.

maltfield · 2022-11-25T19:24:24Z

@fmarier we just got another ticket from a user asking about debian repo integration (specifically asking if we could make our own third-party repo).

Debian/Ubuntu Repository #45

Generally, I'd prefer to put BusKill in the official repos. This was also a prereq from @adrelanos to integrate BusKill into Whonix

Is there anything that I can do to help with this effort? Maybe I can build a .deb file for you or something? I'm not sure the process, but if you link me to some documentation I'll be happy to do most of the legwork for you.

fmarier · 2022-11-27T00:50:00Z

Right now, I don't have any free time at all for this, but hopefully I'll find some time during the xmas break and make it before the freeze for the next Debian version.

Is there anything that I can do to help with this effort? Maybe I can build a .deb file for you or something? I'm not sure the process, but if you link me to some documentation I'll be happy to do most of the legwork for you.

The things that normally need to be worked out are:

licensing issues: I took a quick look and from what I can see, that shouldn't be a problem. You seem to have done a great job including all of the licenses for the third-party code and made sure they're GPL-compatible. One thing to double-check as well is if there are any non-free files in the source tarballs I would be downloading for Debian (e.g. maybe there's some Windows/Mac stuff that's non-free and in there despite not being needed for a Linux build). If that's the case, then I would need to repack the upstream tarball because Debian can't ship non-free source tarballs.
bundled third-party libraries: it looks like there's a small amount of code that comes from elsewhere, but I didn't see any libraries that are "vendored in" and that would need to be packaged separately for Debian, though I didn't look super closely. If you can identify those ahead of time, that would be super helpful.
automated check for new releases: some upstream projects have an easy way to figure out whether or not a new release is available, for others, it's hard or can't be automated. On GitHub, at the moment, the Debian tooling can reliably look at the tags page (but not the releases page unfortunately). I see a lot of builds there and not many actual releases. Are you aware of a way (query string parameter perhaps?) to filter out the daily builds and only show the releases? (The automated check I need to write looks like this: https://salsa.debian.org/debian/pdfresurrect/-/blob/master/debian/watch.)
files not installed in the standard directories: sometimes upstream projects will put files in /opt instead of /etc, /usr, etc. If that's configurable, then there's no problem, but when it's impossible to install in standard system directories, then we need to patch the upstream source for Debian. Note that this is different from putting the config files in the standard place (Two different config directory in my homedir on Linux #39), a very nice to have, but not strictly required like the main application files.
missing manpage: Debian requires each binary to have a manpage. These often come with upstream programs, but not always, especially for tools that don't have many (or any!) parameters. Here's an example of one I had to write : https://salsa.debian.org/debian/pip-check-reqs/-/blob/master/debian/pip-missing-reqs.1. The ideal case here is when upstream devs write it and include it in their repo and tarball.

One minor thing: the standard Debian tooling can check the upstream GPG signature on the tarball, but not on a SHA256SUMS file. So if you modified your signing script to upload two .asc files (i.e. SHA256SUMS.asc and buskill-lin-v0.6.0-x86_64.tbz.asc), then I could add signature verification in the Debian package. Otherwise, it will be disabled (which is okay, but not ideal).

Anyways, if all of these potential issues are resolved ahead of time, then it should be pretty smooth creating, testing and uploading the package :)

fmarier · 2022-11-27T00:51:52Z

And I forgot to say, I do appreciate the offer to help. It's immensely helpful when upstream developers are friendly and supportive of the packaging work in Debian 😄

trymeouteh · 2022-11-27T01:34:49Z

Would prefer a Debian/Ubuntu repository. This way the update manager can install updates automatically on all Debian and Ubuntu based distros.

maltfield · 2022-11-27T19:24:40Z

@trymeouteh

Would prefer a Debian/Ubuntu repository. This way the update manager can install updates automatically on all Debian and Ubuntu based distros.

Is there a difference here between a "Debian/Ubuntu repository" and a "Debian repository".

I assumed that buskill would be available automatically in Ubuntu if we included it in the Debian repositories. Is that not correct?

fmarier · 2022-11-27T20:28:36Z

I assumed that buskill would be available automatically in Ubuntu if we included it in the Debian repositories. Is that not correct?

Once it's included in Debian, it will automatically be part of all future Ubuntu releases (in the universe repository), as well as all other Debian derivatives (of which there are many).

maltfield · 2022-11-27T22:06:00Z

awesome, thanks for pointing me in the right direction :)

licensing issues: I took a quick look and from what I can see, that shouldn't be a problem. You seem to have done a great job including all of the licenses for the third-party code and made sure they're GPL-compatible. One thing to double-check as well is if there are any non-free files in the source tarballs I would be downloading for Debian (e.g. maybe there's some Windows/Mac stuff that's non-free and in there despite not being needed for a Linux build). If that's the case, then I would need to repack the upstream tarball because Debian can't ship non-free source tarballs.

bundled third-party libraries: it looks like there's a small amount of code that comes from elsewhere, but I didn't see any libraries that are "vendored in" and that would need to be packaged separately for Debian, though I didn't look super closely. If you can identify those ahead of time, that would be super helpful.

I think the app's dependencies and licenses could be better enumerated. I'll work on adding this to our documentation to make it more clear.

automated check for new releases: some upstream projects have an easy way to figure out whether or not a new release is available, for others, it's hard or can't be automated. On GitHub, at the moment, the Debian tooling can reliably look at the tags page (but not the releases page unfortunately). I see a lot of builds there and not many actual releases. Are you aware of a way (query string parameter perhaps?) to filter out the daily builds and only show the releases? (The automated check I need to write looks like this: https://salsa.debian.org/debian/pdfresurrect/-/blob/master/debian/watch.)

Quesion: how do apps like firefox with their own built-in update systems work when packaged on Debian to avoid conflicts with apt?

The BusKill app has a built-in update checker, which downloads a json file in a random web server from a set hard-coded mirrors defind here:

buskill-app/src/packages/buskill/__init__.py

Lines 49 to 54 in 8b413b1

    
           UPGRADE_MIRRORS = [ 
        
            'https://raw.githubusercontent.com/BusKill/buskill-app/master/updates/v1/meta.json', 
        
            'https://gitlab.com/buskill/buskill-app/-/raw/master/updates/v1/meta.json', 
        
            'https://repo.buskill.in/buskill-app/v1/meta.json', 
        
            'https://repo.michaelaltfield.net/buskill-app/v1/meta.json', 
        
           ]

One mirror is GitHub, for example:

https://github.com/BusKill/buskill-app/tree/v0.6.0/updates/v1

The meta.json file (which has a cooresponding signature in meta.json.asc) says what is the 'latest' version of the app:

buskill-app/updates/v1/meta.json

Lines 2 to 4 in b712e4c

"latest":{

"buskill-app":{

"stable":"v0.6.0"

But that's just how our in-app updates works internally. I wonder: should we detect if the app was installed via apt somehow and turn-off in-app updates somehow?

The latest release is also listed directly in the GitHub API, which spits out a JSON

https://api.github.com/repos/buskill/buskill-app/releases/latest

{
...
  "tag_name": "v0.6.0",
  "target_commitish": "master",
  "name": "v0.6.0 (beta)",
  "draft": false,
  "prerelease": false,
  "created_at": "2022-10-24T03:03:02Z",
  "published_at": "2022-10-26T02:19:14Z",
  "assets": [
    {
      "url": "https://api.github.com/repos/BusKill/buskill-app/releases/assets/82277425",
      "id": 82277425,
      "node_id": "RA_kwDOEFpnBc4E53Qx",
      "name": "buskill-lin-v0.6.0-x86_64.tbz",
...
      "browser_download_url": "https://github.com/BusKill/buskill-app/releases/download/v0.6.0/buskill-lin-v0.6.0-x86_64.tbz"
    },
...

Yes, our CI pipeline spits-out three "pre-release" builds for every push to github.com. These tag names are just a long string of numbers (seconds since epoch iirc). Actual release tags differ in that their tag names use semantic version naming (eg 'v0.6.0').

Does your Debain Watch tool allow you to query GitHub tags by regex?

files not installed in the standard directories: sometimes upstream projects will put files in /opt instead of /etc, /usr, etc. If that's configurable, then there's no problem, but when it's impossible to install in standard system directories, then we need to patch the upstream source for Debian. Note that this is different from putting the config files in the standard place (Two different config directory in my homedir on Linux #39), a very nice to have, but not strictly required like the main application files.

The BusKill app is a single AppImage. Just copying the AppImage binary on machines would be the easiest solution.

Would you plan to just put the AppImage in the repos or build some sort of wrapper for the sourcecode directly? How is this done for other software in Debian that's distributed upstream as AppImages?

missing manpage: Debian requires each binary to have a manpage. These often come with upstream programs, but not always, especially for tools that don't have many (or any!) parameters. Here's an example of one I had to write : https://salsa.debian.org/debian/pip-check-reqs/-/blob/master/debian/pip-missing-reqs.1. The ideal case here is when upstream devs write it and include it in their repo and tarball.

Ah, yes. I'll write one.

One minor thing: the standard Debian tooling can check the upstream GPG signature on the tarball, but not on a SHA256SUMS file. So if you modified your signing script to upload two .asc files (i.e. SHA256SUMS.asc and buskill-lin-v0.6.0-x86_64.tbz.asc), then I could add signature verification in the Debian package. Otherwise, it will be disabled (which is okay, but not ideal).

I'd rather update our release workflow to include a redundant signature on the linux tarball just for Debian than disable this upstream GPG signature check.

fmarier · 2022-11-28T03:48:56Z

How do apps like firefox with their own built-in update systems work when packaged on Debian to avoid conflicts with apt?

Usually what we do in Debian is simply disable these in-app update checks since updates are handled by the system. If that check can be disabled in a config file (or similar mechanism), then that would be very handy and save us from having to maintain a patch.

Does your Debian Watch tool allow you to query GitHub tags by regex?

Yes, we'll be able to filter that tags URL for something like v[0-9.]+ then.

Would you plan to just put the AppImage in the repos or build some sort of wrapper for the sourcecode directly? How is this done for other software in Debian that's distributed upstream as AppImages?

I'm not super familiar with AppImage, but my understanding is these are self-contained archives with everything required to run the program (perhaps bundling third-party libraries too?).

In Debian, we would install the Python files in the usual directories (e.g. /usr/bin, /usr/lib, /etc/, /var/lib, etc.). Specifying the location of each file can be done in the Debian packaging directly. Any dependencies would be packaged separately so that there's only one copy of each library (more or less) on the system.

I'd rather update our release workflow to include a redundant signature on the linux tarball just for Debian than disable this upstream GPG signature check.

🎉

…arball (for downstream Debian package maintainers) * #31 (comment)

maltfield · 2022-11-28T17:50:49Z

I went ahead and signed the latest linux release tarball (v0.6.0):

https://github.com/BusKill/buskill-app/releases/tag/v0.6.0

And I've also updated our Release Workflow documentation to include this redundant external signature file for future releases:

https://docs.buskill.in/buskill-app/en/dev/software_dev/release.html#build-sign

maltfield · 2022-11-28T18:10:37Z

I'm not super familiar with AppImage, but my understanding is these are self-contained archives with everything required to run the program (perhaps bundling third-party libraries too?).

Yeah, it's basically one big binary that includes your app and all its dependencies. At execution-time, it extracts everything into a temporary directory.

This is how we build our BusKill app for Linux. We actually start with the AppImage for Python, then we extract the squashfs contents, modify it by adding our code/images/etc, and then package it back up again into an AppImage binary.

In Debian, we would install the Python files in the usual directories (e.g. /usr/bin, /usr/lib, /etc/, /var/lib, etc.). Specifying the location of each file can be done in the Debian packaging directly. Any dependencies would be packaged separately so that there's only one copy of each library (more or less) on the system.

I'm afraid this is the hard approach because we don't build/test the BusKill app like that, but it will result in a much smaller package. I expect some iteration will be needed to get it working. Code changes may be needed for things like images, which are expected to be located relative to the extracted AppImage's temp directory.

Usually what we do in Debian is simply disable these in-app update checks since updates are handled by the system. If that check can be disabled in a config file (or similar mechanism), then that would be very handy and save us from having to maintain a patch.

Right now we don't have a config option to disable the BusKill in-app updates, and this is blocked until at least the next release, which will finally include config file support.

Config file support #16

I've created a ticket for this. But, unfortunately, I'm not sure this can be done before the new year.

Add option to disable in-app update #47

maltfield · 2022-11-29T03:04:24Z

I've added a new "Dependencies" section to our documentation that enumerates all the external software that the BusKill app uses:

https://github.com/BusKill/buskill-app/blob/dev/docs/software_dev/depends.rst

In Debian, I believe this translates to the following packages:

python3
python3-kivy
gnupg
python3-gnupg
python3-usb1

All the above software is already in Debian.

The only code that I or other contributors didn't write directly for this project is here in the 'packages' dir. As you saw, the LICENSE files with copyrights are there, and it all should be GPL compatible

fmarier · 2022-11-29T05:48:50Z

That's great. All of these are already packaged in Debian ✔️

maltfield · 2022-12-13T21:38:49Z

manpage is complete (see #48)

@fmarier I think that addresses everything I can for now. Please let me know if there's anything more I can do to assist. If not, then I look forward to BusKill being added to Debian over the xmas break :)

fmarier · 2022-12-21T04:54:02Z

I've done some initial packaging work in this repo. It's not quite ready yet, but it does seem to run (I don't have my buskill with me so I can't actually test it).

A few questions for you:

Is buskill_cli actually used anywhere?
What would you recommend to me as the best way to patch out the update code so that it doesn't do anything?
Is gnupg only used by the update code?

One thing I failed to notice earlier when you added a GPG signature on the tarball just for the Debian use case is that the tarball I actually need to use is not the Linux one (which only contains the AppImage), but rather the source code one since I am "building" from source. Sorry for not catching this earlier. Would you like me to file a separate issue for this?

fmarier · 2022-12-21T04:58:56Z

The larger problem though is that I may need to repackage the upstream source code tarball. It contains far too much stuff compared to what's actually needed in Debian (i.e. > 300MB of external dependencies), and I would also need to document the licenses for all of that if I left it in.

Alternatively, do you think you could simply exclude the build/ directory from the source code tarballs? Someone who wants to build the AppImages from source could always just clone the repo, but it would mean that the source code tarball itself is just the original code from the project and the documentation. That's normally what we expect when we package software on Linux.

maltfield · 2022-12-21T15:17:02Z

Thanks so much for your work on this. To answer your questions

Is buskill_cli actually used anywhere?

Yes, it's used if the application is executed with arguments. See:

buskill-app/src/main.py

Lines 142 to 147 in b712e4c

    
           else: 
        
           	# the user passed-in arguments; give 'em the cli 
        
           	from buskill_cli import * 
        
           	ret = BusKillCLI()

What would you recommend to me as the best way to patch out the update code so that it doesn't do anything?

The quick & dirty method would be to just comment-out the two ways the user can trigger the upgrade functions to run in the UIs.

I'd like to just do ^ that for now so this can get in before the freeze. But in the future I'll add a boolean flag and some logic in the code that will detect this and hide the options if that's set to True.

Is this what other projects do? Can you link to good examples of how this is ideally solved in other software (eg Firefox and, uh, another app that's much simpler than Firefox)?

But for now, please just comment-out this block for the GUI

buskill-app/src/buskill.kv

Lines 79 to 89 in b712e4c

    
           					Button: 
        
           						text: '[font=Roboto][size=24]  [/size][/font][font=mdicons][size=24]\ue923[/size][/font]     [font=RobotoMedium][size=16]Update[/size][/font]' 
        
           						markup: True 
        
           						halign: 'left' 
        
           						valign: 'center' 
        
           						text_size: self.size 
        
           						size_hint: 1, None 
        
           						height: 50 
        
           						background_normal: '' 
        
           						background_color: root.color_menu_bg 
        
           						on_release: root.upgrade1()

And this block for the CLI

buskill-app/src/buskill_cli.py

Lines 88 to 92 in b712e4c

    
           parser.add_argument( 
        
            "-U", "--upgrade", 
        
            help="Download & upgrade latest version of BusKill", 
        
            action="store_true" 
        
           )

Is gnupg only used by the update code?

Ah, good point. I think you're right and gnupg is only used by the update code, so you can probably remove that depend on Debian systems.

One thing I failed to notice earlier when you added a GPG signature on the tarball just for the Debian use case is that the tarball I actually need to use is not the Linux one (which only contains the AppImage), but rather the source code one since I am "building" from source. Sorry for not catching this earlier. Would you like me to file a separate issue for this?

Ah, ok. Yeah, a new issue would help as I'll need to update the docs for how to do our release. But I'll try to get you that detached sig file for the v0.6.0 source code by EOD.

The larger problem though is that I may need to repackage the upstream source code tarball. It contains far too much stuff compared to what's actually needed in Debian (i.e. > 300MB of external dependencies), and I would also need to document the licenses for all of that if I left it in.

Alternatively, do you think you could simply exclude the build/ directory from the source code tarballs? Someone who wants to build the AppImages from source could always just clone the repo, but it would mean that the source code tarball itself is just the original code from the project and the documentation. That's normally what we expect when we package software on Linux.

Yeah, definitely strip the build/ dir.

You can also delete the updates/ dir.

I'd also consider deleting all of the files in docs/ with the exception of the following files:

README.md
buskill.1

And you should also be able to delete the .github dir.

fmarier · 2022-12-21T18:40:25Z

I see a lot of debug output when I use the command line tools in the Debian package I just built:

$ buskill --help
===============================================================================
INFO: Writing to log file '/tmp/user/1000/buskill.log'
buskill version {'VERSION': '', 'GITHUB_REF': '', 'GITHUB_SHA': '', 'SOURCE_DATE_EPOCH': ''}
usb1.__version__:|2.0.1|
usage: buskill [-h] [--version] [--list-triggers] [-v] [-t] [-T] [-a]

App for arming and configuring BusKill. For help, see https://docs.buskill.in

options:
  -h, --help         show this help message and exit
  --version          print version and exit.
  --list-triggers    List all available triggers.
  -v, --verbose      increase output verbosity
  -t , --trigger     Choose trigger to execute. See --list-triggers for all possible values.
  -T, --run-trigger  Immediately execute the trigger on start
  -a, --arm          Arms BusKill

and:

$ buskill --list-triggers
===============================================================================
INFO: Writing to log file '/tmp/user/1000/buskill.log'
buskill version {'VERSION': '', 'GITHUB_REF': '', 'GITHUB_SHA': '', 'SOURCE_DATE_EPOCH': ''}
usb1.__version__:|2.0.1|
DEBUG: EXECUTED_AS_SCRIPT:|True|
DEBUG: EXE_PATH:|/usr/share/buskill/main.py|
DEBUG: EXE_DIR:|/usr/share/buskill|
DEBUG: EXE_FILE:|main.py|
DEBUG: APP_DIR:|/usr/share|
DEBUG: APPS_DIR:|/usr|
DEBUG: SRC_DIR:|/usr/share/buskill|
DEBUG: os.environ['PATH']:|/home/francois/bin:/home/francois/devel/remote/user-scripts:/usr/lib/ccache:/home/francois/bin:/usr/share/safe-rm/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/share/buskill:/usr/share|

DEBUG: Unable to write to '/usr'; skipping.
	[Errno 13] Permission denied: '/usr/tmp9n_h460x'

DEBUG: Unable to write to '/usr/share'; skipping.
	[Errno 13] Permission denied: '/usr/share/tmp2815z87t'

INFO: using DATA_DIR:|/home/francois/.buskill|

Supported triggers include:
	lock-screen
	soft-shutdown

Is there anything I should be setting/changing to hide the inconsequential debug output?

fmarier · 2022-12-21T21:03:29Z

Ah, ok. Yeah, a new issue would help as I'll need to update the docs for how to do our release. But I'll try to get you that detached sig file for the v0.6.0 source code by EOD.

Might be too late, but here it is: #53

maltfield · 2022-12-21T22:05:09Z

I see a lot of debug output when I use the command line tools in the Debian package I just built:
...
Is there anything I should be setting/changing to hide the inconsequential debug output?

There's currently nothing you can do. The app always outputs DEBUG messages. Adding an option to toggle debug log messages is on the TODO list, but it's fairly low priority and is blocked by #16

fmarier · 2022-12-27T03:08:23Z

I'm wondering: who is the audience for these hybrid source-and-binaries tarballs?

So the source tarball is actually built by GitHub when you tag a commit and create a release from that tag. I don't select its contents; it just includes everything in the repo at the time of the commit that the tag points-to (with the exception of the .git dir, it seems).

In that case, you might be able to just add the build and updates directories to .gitattributes like https://github.com/fmarier/tmd710_tncsetup/blob/master/.gitattributes.

maltfield · 2022-12-27T03:17:55Z

(Is my I'm-not-actually-a-real-developer hat showing?)

TIL the git archive command, thanks :) I guess this is somehow the equivalent of svn export and is what GitHub uses when preparing the source tarball? From man git archive:

ATTRIBUTES
export-ignore
Files and directories with the attribute export-ignore won’t be
added to archive files. See gitattributes(5) for details.

   export-subst
       If the attribute export-subst is set for a file then Git will
       expand several placeholders when adding this file to an archive.
       See gitattributes(5) for details.

   Note that attributes are by default taken from the .gitattributes files
   in the tree that is being archived. If you want to tweak the way the
   output is generated after the fact (e.g. you committed without adding
   an appropriate export-ignore in its .gitattributes), adjust the checked
   out .gitattributes file as necessary and use --worktree-attributes
   option. Alternatively you can keep necessary attributes that should
   apply while archiving any tree in your $GIT_DIR/info/attributes file.

And from man gitattributes

Creating an archive
export-ignore
Files and directories with the attribute export-ignore won’t be added to
archive files.

  export-subst
      If the attribute export-subst is set for a file then Git will expand
      several placeholders when adding this file to an archive. The expansion
      depends on the availability of a commit ID, i.e., if git-archive(1) has
      been given a tree instead of a commit or a tag then no replacement will be
      done. The placeholders are the same as those for the option
      --pretty=format: of git-log(1), except that they need to be wrapped like
      this: $Format:PLACEHOLDERS$ in the file. E.g. the string $Format:%H$ will
      be replaced by the commit hash.

Thanks for the tip. I'll give that a try and see if I can get GitHub's release source tarball to match what you expect automatically

maltfield · 2022-12-27T16:14:39Z

Aand today I stumble on this :) thanks again

https://feeding.cloud.geek.nz/posts/excluding-files-from-git-archive/

testing trying to change the shebang from a specific version of python3 to just 'python3' as it'll get rid of errors on Debian: * #56 * #31

fmarier · 2023-01-02T00:09:05Z

Initial package submitted to the NEW queue for approval: https://ftp-master.debian.org/new/buskill_0.6.0+git20221227.e1539d2-1.html

maltfield · 2023-01-02T01:00:19Z

Fantastic news @fmarier, thanks so much for your work on this!

Depends: fonts-freefont-ttf, fonts-material-design-icons-iconfont, fonts-roboto ...

And thanks for catching those font depends, and sorry I missed them before

maltfield · 2023-01-02T01:06:52Z

See also the ticket for packaging buskill on Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021693

I see it's marked to be added to unstable

https://ftp-master.debian.org/new.html

What is the process of going from unstable to stable or bookworm?

fmarier · 2023-01-02T03:27:47Z

What is the process of going from unstable to stable or bookworm?

Once it's accepted into unstable 🤞 , it will automatically migrate to testing (which is bookworm at the moment) after 5 days. Then when bookworm is released, that version of Debian will be the new stable and buskill will be in it.

maltfield · 2023-01-03T17:44:49Z

TODO: After the buskill package is in stable, we should test the buskill app on all these Debian-based systems:

Debian 12 (bookworm)
Ubuntu
Mint
Whonix
PureOS
Kali
Knoppix
TAILS

fmarier · 2023-01-03T18:20:06Z

Since the Debian Import Freeze for Ubuntu 23.04 is on 2023-02-23, it should normally be in that distro as well.

… issues for bugs, enhancements, PRs, and helped bring the BusKill app into the Debian repos in 2022/2023 * https://github.com/fmarier * #31 (comment)

fmarier · 2023-01-28T21:21:52Z

The buskill package has just been accepted in Debian unstable and has been sync'ed into the development version of Ubuntu.

maltfield · 2023-01-29T03:28:19Z

Fantastic news, thanks so much for your help to get us to reach this milestone, @fmarier !!

I was wondering how to track the package's status in the NEW queue. So I guess if it disappears from the new queue, then it was accepted? Maybe a "red" font means rejected?

maltfield · 2023-01-29T04:37:52Z

Ah, I also just noticed that the "Homepage" listed for the buskill debian package is a broken link.

Currently it's:

https://github.com/BusKill/buskill

But it should be:

https://github.com/BusKill/buskill-app

fmarier · 2023-01-29T05:26:20Z

Indeed. It was also reported on the Debian bug tracker and so I just fixed it, for a future upload next week. I used the buskill.in page though, do you think that's okay?

maltfield · 2023-01-29T15:17:26Z

buskill.in page though, do you think that's okay?

Absolutely. Thanks :)

fmarier · 2023-02-08T04:52:43Z

And the homepage fix has now make it to bookworm.

fmarier · 2023-02-08T04:54:07Z

FWIW, the latest version of the package also includes an optional systemd unit file to enable buskill automatically without requiring the GUI application: https://salsa.debian.org/debian/buskill/-/blob/master/debian/README.Debian

maltfield · 2023-02-08T19:13:10Z

@fmarier very interesting idea to create a systemd unit file!

https://salsa.debian.org/debian/buskill/-/blob/master/debian/buskill.user.service

So the idea is that the user executes the following to arm buskill

systemctl --user enable buskill.service
systemctl --user start buskill.service

And they execute the following to disarm (eg before going to the bathroom), is that correct?

systemctl --user stop buskill.service

Also, I'm not sure if you've ever used the shutdown feature, but that's currently available in the CLI version of BusKill

/usr/bin/buskill --arm --trigger soft-shutdown

I imagine it's possible to update the systemd config to support setting the trigger type, but I'm not privy to the systemd/debian best-practices for how this should be done.

fmarier · 2023-02-10T03:11:50Z

So the idea is that the user executes the following to arm buskill
systemctl --user enable buskill.service
systemctl --user start buskill.service
And they execute the following to disarm (eg before going to the bathroom), is that correct?
systemctl --user stop buskill.service

Yes, although since it's using the default trigger of locking the screen, I expect most users will just let the screen lock while they go to the bathroom ;-)

fmarier · 2023-02-10T03:14:02Z

Also, I'm not sure if you've ever used the shutdown feature, but that's currently available in the CLI version of BusKill
/usr/bin/buskill --arm --trigger soft-shutdown
I imagine it's possible to update the systemd config to support setting the trigger type, but I'm not privy to the systemd/debian best-practices for how this should be done.

Right now that could be done by editing/overriding the unit file and changing the ExecStart line.

Once there is support for a config file in buskill though, it could be even easier: just configure buskill to use the shutdown trigger as default when it arms, and then the systemd unit file can be used as-is.

maltfield · 2023-06-08T23:13:26Z

FYI, looks like Debian 12 is becoming stable in two days 🎉

https://www.debian.org/releases/bookworm/

fmarier · 2023-06-08T23:35:46Z

Indeed! https://wiki.debian.org/ReleasePartyBookworm

maltfield · 2023-06-19T17:32:53Z

Yesterday I downloaded and installed Debian 12 in an HVM on my QubesOS system. I think this might have been the first time I've installed Debian on an HVM in Qubes, but it was unable to get a network connection, so I ended-up with a system without a Desktop Environment.

Surprisingly, I was still able to install BusKill without a DE. After it installed, I ran buskill from my tty1 session.

Unfortunately, I couldn't click anything with the mouse (somehow I was able to open the navigation drawer, but I still couldn't click anything). And, worse, I couldn't exit the shell.

If I wasn't on an HVM, I could have done the ctrl+alt+f2 to jump to tty2 and kill the session, but those hotkeys were captured on my QubesOS dom0 hypervisor, so the only thing I could do was shutdown the system :(

I think we should implement some kind of way to exit the app with a keyboard shortcut, for which I've created this bug:

Basic Keyboard Shortcuts #74

In any case, I think this ticket is complete

maltfield · 2023-06-19T17:35:02Z

Later this year, I hope to publish an article that shows how to install BusKill on Debian-based systems, including:

Debian
Mint
Ubuntu
Whonix
TAILS
Kali
PopOS

...but I'll at least have to wait for the next release of each of those systems

maltfield added this to the Built-in Distro Packages (apt, yum, etc) milestone Jul 22, 2022

maltfield mentioned this issue Nov 25, 2022

Debian/Ubuntu Repository #45

Closed

maltfield added a commit that referenced this issue Nov 28, 2022

Updated release process to add redundant signature of linux release t…

8d81687

…arball (for downstream Debian package maintainers) * #31 (comment)

maltfield mentioned this issue Nov 28, 2022

Add option to disable in-app update #47

Open

maltfield pinned this issue Dec 3, 2022

maltfield mentioned this issue Dec 8, 2022

Write man page #48

Closed

maltfield mentioned this issue Dec 21, 2022

Move the Debian-specific GPG signature from the Linux tarball to the source tarball #53

Closed

maltfield added a commit that referenced this issue Jan 1, 2023

s/python3.7/python3

d47eb02

testing trying to change the shebang from a specific version of python3 to just 'python3' as it'll get rid of errors on Debian: * #56 * #31

maltfield closed this as completed Jan 3, 2023

maltfield reopened this Jan 3, 2023

maltfield closed this as completed Jun 19, 2023

maltfield unpinned this issue Jun 19, 2023

maltfield mentioned this issue Jun 19, 2023

PermissionError: [Errno 13] Permission denied: '/tmp/buskill.log' #75

Open

Support for installing in apt (.deb) #31

Support for installing in apt (.deb) #31

Comments

maltfield commented Jul 22, 2022

maltfield commented Oct 14, 2022

maltfield commented Oct 14, 2022 • edited Loading

fmarier commented Oct 14, 2022

fmarier commented Oct 14, 2022

maltfield commented Nov 25, 2022 • edited Loading

fmarier commented Nov 27, 2022 • edited by maltfield Loading

fmarier commented Nov 27, 2022

trymeouteh commented Nov 27, 2022

maltfield commented Nov 27, 2022

fmarier commented Nov 27, 2022

maltfield commented Nov 27, 2022 • edited Loading

fmarier commented Nov 28, 2022

maltfield commented Nov 28, 2022

maltfield commented Nov 28, 2022 • edited Loading

maltfield commented Nov 29, 2022 • edited Loading

fmarier commented Nov 29, 2022

maltfield commented Dec 13, 2022

fmarier commented Dec 21, 2022

fmarier commented Dec 21, 2022

maltfield commented Dec 21, 2022 • edited Loading

fmarier commented Dec 21, 2022

fmarier commented Dec 21, 2022

maltfield commented Dec 21, 2022 • edited Loading

fmarier commented Dec 27, 2022

maltfield commented Dec 27, 2022 • edited Loading

maltfield commented Dec 27, 2022 • edited Loading

fmarier commented Jan 2, 2023

maltfield commented Jan 2, 2023 • edited Loading

maltfield commented Jan 2, 2023 • edited Loading

fmarier commented Jan 2, 2023

maltfield commented Jan 3, 2023 • edited Loading

fmarier commented Jan 3, 2023

fmarier commented Jan 28, 2023 • edited Loading

maltfield commented Jan 29, 2023

maltfield commented Jan 29, 2023 • edited Loading

fmarier commented Jan 29, 2023

maltfield commented Jan 29, 2023

fmarier commented Feb 8, 2023

fmarier commented Feb 8, 2023

maltfield commented Feb 8, 2023 • edited Loading

fmarier commented Feb 10, 2023

fmarier commented Feb 10, 2023

maltfield commented Jun 8, 2023 • edited Loading

fmarier commented Jun 8, 2023

maltfield commented Jun 19, 2023

maltfield commented Jun 19, 2023 • edited Loading

maltfield commented Oct 14, 2022 •

edited

Loading

maltfield commented Nov 25, 2022 •

edited

Loading

fmarier commented Nov 27, 2022 •

edited by maltfield

Loading

maltfield commented Nov 27, 2022 •

edited

Loading

maltfield commented Nov 28, 2022 •

edited

Loading

maltfield commented Nov 29, 2022 •

edited

Loading

maltfield commented Dec 21, 2022 •

edited

Loading

maltfield commented Dec 21, 2022 •

edited

Loading

maltfield commented Dec 27, 2022 •

edited

Loading

maltfield commented Dec 27, 2022 •

edited

Loading

maltfield commented Jan 2, 2023 •

edited

Loading

maltfield commented Jan 2, 2023 •

edited

Loading

maltfield commented Jan 3, 2023 •

edited

Loading

fmarier commented Jan 28, 2023 •

edited

Loading

maltfield commented Jan 29, 2023 •

edited

Loading

maltfield commented Feb 8, 2023 •

edited

Loading

maltfield commented Jun 8, 2023 •

edited

Loading

maltfield commented Jun 19, 2023 •

edited

Loading