PackageCloud Trial for Debian and RPM users

[shiftkey]

If you're using a Debian or RPM-based distro I've started evaluating PackageCloud as a way of distributing updates. The trial lasts for 2 weeks.

The details are up at https://packagecloud.io/shiftkey/desktop including setup instructions, and the current release is listed there. I'm aiming to get automated releases in place for the 2.5 release of GitHub Desktop that's coming up, but no promises (and I can manually upload anyway if I don't get time).

This is not a free service (starts at $75 a month) but if you get value out of it and would love to sponsor to assist with the expenses please get in touch (either here or via email).

[jfgordon2]

@shiftkey I'll throw in a bit, as I'd love to see this thrive - perhaps this would be worthwhile to setup a few tiers on github sponsors? not sure what the obligation is, though, nor the credit card fees, etc

[shiftkey]

@jfgordon2 I need to go through a whole process (after being accepted into the program of course) but more info about sponsoring is here: https://help.github.com/en/github/supporting-the-open-source-community-with-github-sponsors/sponsoring-an-open-source-contributor

[shiftkey]

Installation instructions are now in the README: https://github.com/shiftkey/desktop#packagecloud

[shiftkey]

So the trial is about to expire and here's some quick stats from the less-than-two-weeks of having this open:

• 560+ downloads - 94% for deb, 6% for RPM
• 33GB bandwidth used

Extrapolating to a full month looks like we'd need ~75GB a month of bandwidth at the current popularity, which would fall into the $150.00 per month billing. So there's two action items for me over the next few days:

• apply to GitHub Sponsors so that others can help contribute to these costs
• explore alternative hosting options that could cache better and reduce costs without abusing the platform

[shiftkey]

Well that forecasting was way off the mark. I just got the notification that we've already used 50% of the allocated bandwidth in the space of a week, so it looks like people are using it more than I anticipated 🎉.

I started the application process for GitHub Sponsors early in the week but that's going to take some time (and the first payout won't occur until 90 days from when that completes, based on the ToS).

[shiftkey]

My application to GitHub Sponsors was approved just now, so I've added the relevant details to the repository to make this visible:

If you want to help out with these costs it'd be greatly appreciated.

[shiftkey]

I gather this repository is being shared around the place recently because I just got the 90% warning overnight, and am now at 99% of bandwidth used.

I've upgraded us to the Medium plan (now it's $150 per month for 3x the bandwidth) so it'll continue to work, but if you can chip in with these costs it'd be greatly appreciated.

[shiftkey]

I'm a bit confused about how they're crunching the numbers after I upgraded, so after downloading 167GB of bandwidth for this month the account has been suspended (rather continuing to pay overages):

I believe this will reset on the 22nd of June, so if you're continuing to try and install the app and its failing it should come good on Monday.

[SaladinAyyub]

why don't use OBS (Open build service) instead its free and you can build for all the distros..

[adamsmd]

@jatin-cbs In a comment at #337 (comment), shiftkey says that he needs an alternative to do all the following. I can't tell from the webpage, does OBS do all of these?

• hosted infrastructure
• accepts .deb directly
• handles GPG signing natively
• also supports RPM hosting

[SaladinAyyub]

@adamsmd Yes OBS supports debian and rpm packages and gpg signing keys too ! Many packages are hosted on OBS.. You can host packages for any major linux distro and its free :)
https://openbuildservice.org/

[nektro]

+1 on using OBS as PackageCloud is still erroring for updates.

Err:3 https://packagecloud.io/shiftkey/desktop/any any InRelease                                                                                                                                                  
  429  Too Many Requests [IP: REDACTED 443]

W: Failed to fetch https://packagecloud.io/shiftkey/desktop/any/dists/any/InRelease  429  Too Many Requests [IP: REDACTED 443]

[TopView]

+1 also getting: W: Failed to fetch https://packagecloud.io/shiftkey/desktop/any/dists/any/InRelease 429 Too Many Requests [IP: 54.183.38.243 443]

By chiming in here, will i hear when this is moved/fixed? Hope so.

[shiftkey]

By chiming in here, will i hear when this is moved/fixed? Hope so.

I've opened #363 to explore OBS but I haven't had time to understand how to integrate without throwing away my build and deployment infrastructure

[Star-Tube]

Was about to install using this. Could the readme be updated to reflect that this may not always be available and explain an alternative? (Not sure if this needs to be a seperate issue or if here is fine... I'm fairly new to github)

[SaladinAyyub]

@Star-Tube No need to open a new issue for this, however shiftkey is still maintaining the packagecloud repository. And people who don't use packagecloud actually come back to git releases to get the updated package So they will probably be aware once a good alternative is found.

[mwt]

I've created a mirror of the Debian repo. It has IPv4/IPv6 and supports both http and https. It uses the same gpg as the official repo. So, you shouldn't have to trust me or add another gpg key. You can test it by running:

sudo sh -c 'echo "deb [arch=amd64] https://mirror.mwt.me/ghd/deb/" > /etc/apt/sources.list.d/packagecloud-shiftkey-desktop.list'

or just manually edit the file yourself. I'm open to hosting an rpm mirror as well, but this seems to be impossible in Debian without an rpm-based chroot or seprate server. If someone else has an rpm based VPS, I encourage you to mirror. If you don't have the bandwidth, I can rsync from you.

My goal with this mirror is to reduce @shiftkey's bandwidth usage. I'm hoping we can:

1. Prevent the original server from going down.
2. Eventually get @shiftkey onto a cheaper plan.

Update: I setup an rpm mirror at https://mirror.mwt.me/ghd/rpm as well. I created a separate issue, #647, so as not to derail the discussion here.

[mwt]

I currently have a script that regenerates a Debian repo upon receiving new .deb files. It detects their versions, renames them, generates all those package files, etc. It wouldn't be difficult to wrap this up in a PHP script (or even cgi-bash) so that you could POST new deb files to an endpoint. The endpoint could be protected with basic auth and a password stored as a secret for GH actions. Debs could be sent via curl.

I don't have a decent solution for RPM though. I just raise this in case someone has a good RPM solution that can resolve the other half of the problem.

[theofficialgman]

are there plans of ever updating the debian repo past version 2.9.6? This is quite out of date now and the other package distribution methods are up to date and automated

[mwt]

are there plans of ever updating the debian repo past version 2.9.6? This is quite out of date now and the other package distribution methods are up to date and automated

Btw, I can't update packages on the mirror myself (because of gpg). Updates will automatically get copied from PackageCloud once they're pushed there.

[shiftkey]

are there plans of ever updating the debian repo past version 2.9.6? This is quite out of date now and the other package distribution methods are up to date and automated

This is on my list for the coming week.

[mwt]

I don't have a decent solution for RPM though. I just raise this in case someone has a good RPM solution that can resolve the other half of the problem.

I figured out the RPM repos. I am testing a script that checks your releases at 3am each day, downloads rpm/deb files if the latest release changes, and constructs repos out of them. This seems to be working well. I've tested it on Ubuntu, Debian, and Oracle Linux (redhat based).

It could also be adapted to work some other way (eg. rsync files after building) or to add updates only when some condition is met (using variables from this endpoint).

This would remove the need for PackageCloud and the expense associated with it. Do you think that this is a good solution?

[theofficialgman]

@shiftkey looks like you either need to switch plans at packagecloud or up your storeage/bandwidth limit
I get 429 errors when apt updating on my install

Ign:9 https://packagecloud.io/shiftkey/desktop/any any InRelease
Ign:9 https://packagecloud.io/shiftkey/desktop/any any InRelease
Err:9 https://packagecloud.io/shiftkey/desktop/any any InRelease                                                                                                  
  429  Too Many Requests [IP: 2600:1f1c:2e5:6900:ea2f:7c61:44d4:731c 443]

and goes to the webpage directly redirects with this

Bandwidth or Storage Limit Exceeded

[jfgordon2]

@shiftkey looks like you either need to switch plans at packagecloud or up your storeage/bandwidth limit

I get 429 errors when apt updating on my install

Ign:9 https://packagecloud.io/shiftkey/desktop/any any InRelease

Ign:9 https://packagecloud.io/shiftkey/desktop/any any InRelease

Err:9 https://packagecloud.io/shiftkey/desktop/any any InRelease                                                                                                  

  429  Too Many Requests [IP: 2600:1f1c:2e5:6900:ea2f:7c61:44d4:731c 443]

and goes to the webpage directly redirects with this

Bandwidth or Storage Limit Exceeded

@theofficialgman I know it's not exactly the deb package, but I do highly recommend the flatpak. You can also download the debs in the releases on this repo.

While the packaging solution is being worked out, I believe he's personally out-of-pocket on the majority of these bandwidth costs. I'd rather see him get out of package cloud entirely at this point than double-down.

[theofficialgman]

@theofficialgman I know it's not exactly the deb package, but I do highly recommend the flatpak. You can also download the debs in the releases on this repo.

ngl, thats probably the worst reason to use a flatpak. LOL, never.
shiftkey can just make a github debian repo with github pages to host the debs on for free if he wants. I know plenty of projects that do that.

for ubuntu, a launchpad PPA is always a free option as well

[mwt]

You could use the mirror mentioned in the README or try the new script I mentioned that doesn't rely on PackageCloud by running:

wget -qO- "https://mirror.mwt.me/github-desktop/install.sh" | sudo sh

I have been using the above on Ubuntu 22.04 since I made it last week. It should work fine. It got the 3.0.0 update automatically during this time. It's essentially the same script that I've been using for a while with RStudio. So, I don't expect issues.

This should work on Debian/Ubuntu, RHEL/Fedora, and (Open)SUSE. Though, I haven't tested it on that last one.

[jfgordon2]

@theofficialgman I know it's not exactly the deb package, but I do highly recommend the flatpak. You can also download the debs in the releases on this repo.

ngl, thats probably the worst reason to use a flatpak. LOL, never. shiftkey can just make a github debian repo with github pages to host the debs on for free if he wants. I know plenty of projects that do that.

for ubuntu, a launchpad PPA is always a free option as well

I'm not suggesting that as a reason to try, but as a suitable alternative. If using flatpaks doesn't work for your specific situation, there's a mirror on the README that should be a swap-in replacement for the current apt repo.

I think what it comes down to is somebody has to do the work. Keep in mind when there's an open source project like this, people are volunteering their time and money to make it available for you. Hosting on github (beyond just basic artifact download availability) is almost certainly an abuse of this platform, if not a ToS violation, and Launchpad has been investigated but found incompatible with the current build script. If you'd like to contribute your expertise to make the switch to Launchpad happen, I'm sure it would be welcomed. I'm not an expert on packaging, but I know this sort of change would be a fair amount of work.

[lskillen]

This was mentioned previously, but there's always Cloudsmith as well, which is mostly compatible with the current setup, offers significant open-source storage/bandwidth (up to and beyond 1TB for sponsored projects), is fully managed with no quirks or otherwise usage restrictions, etc. :-) (I work there, happy to help with questions!)

[jfgordon2]

I just checked out the documentation @lskillen and it looks pretty straightforward to integrate as a couple steps in the GA pipeline pipeline. I presume to go beyond the standard 1GB of free bandwidth listed in the pricing, there's some approval process to go through? It might be helpful to orient @shiftkey on next steps if this is a direction he wants to take this project.

@shiftkey I'm happy to submit a PR or if you just want a second set of eyes along with @lskillen.

[lskillen]

Yep, it is just an approval process, and tbh the team is pretty flexible/helpful/supportive in general. Usually someone asks for a bump, and we say OK. The minimum we ask for is attribution that we're providing it for free, but I'd imagine thst is probably several magnitudes less onerous than @shiftkey paying out of their own pocket. :)

[aywi]

Hi, it looks like the package repository has not been updated for two months.

[mwt]

Hi, it looks like the package repository has not been updated for two months.

Yes. Packages are currently uploaded to PackageCloud manually. So nothing is broken.

---

As an update, in the last two months, I have built out the mirroring infrastructure for mirror.mwt.me considerably. There are now three origin servers (US East, US West, and Europe) with a tiered CDN that pulls from the closest origin. There is also a failover server that is used if the node near you goes down.

I mirror all of the files from PackageCloud each day to /ghd/ which is the second link in the readme.

I also have been using an alternative at /github-desktop/ which updates each day using the latest release from GitHub. This is automated, works well, and does not depend on PackageCloud.

@shiftkey so, if you stopped paying for PackageCloud today, you'd still have a working deb/rpm repo at /github-desktop/ which I could propose instructions for in the readme. I want to clarify that you could stop using PackageCloud at any time without major consequences or effort on your part.

My goal in making this mirror was to fix the bandwidth issue and I'd like to help fix this $160 issue as well. Maintaining this shouldn't cost you money. Let me know if you think this is good or if you think there's something missing. You can also do this and try out Cloudforge at the same time.

[shiftkey]

@mwt thanks for the help with the mirror here, but there's clearly enough users here that we're still getting slammed each month (without even shipping new updates to PackageCloud).

I've opened #834 to start testing my alternative feed, which no longer depends on anything PackageCloud-related to allow for hosting of these releases. I'm aiming for https://apt.packages.shiftkey.dev/ to become the canonical channel for debian packages, and I'll spin up a corresponding rpm.packages.shiftkey.dev for RPM packages once the APT feed is stable (as that's the more popular package currently).

[shiftkey]

#835 has the relevant instructions for the new RPM feed, and I've opened #836 to refresh the README so we can move away from PackageCloud.

[shiftkey]

The PackageCloud feed will continue to operate for a while, but will not receive updates.

For anyone still looking for discussions on this let's move to the new issues for each feed:

• 🆕 [Debian/Ubuntu users] Feedback on new package feed #834
• 🆕 [RPM users] Feedback on new package feed #835