debian package
it should be simple to package this as a debian package
Activity
changed milestone to %RiseupVPN 18.12
@drebs I hear you were planning to work on this, is it right?
-
@micah asked me if i was interested in helping with packaging riseupvpn for debian, and i said yes. Is bitmask-systray the same thing as riseupvpn?
not exactly, although the distinction is subtle. bitmask-systray wants to be a generic package, what we call bitmask-lite. it's a go package that produces a single binary.
riseup_vpn is a repo that has helpers and other stuff needed to package a branded build of bitmask-systray (as a snap, osx bundle, windows package etc).
right now riseup_vpn is branded for riseup (with assets, appname etc), but there are scripts that generate most of what is needed from a template, with the idea that the generic part can be extracted to a provider-agnostic repo.
short story long, riseupvpn debian package should be handled in the riseup_vpn repo, and not as a native package.
I've packaged another go piece (leap-geolocation), and the trick seems to be to vendor all the dependencies for a quick build.
Quoting Kali Kaneko (2018-12-14 10:08:45)
not exactly, although the distinction is subtle. bitmask-systray wants to be a generic package, what we call bitmask-lite. it's a go package that produces a single binary.
riseup_vpn is a repo that has helpers and other stuff needed to package a branded build of bitmask-systray (as a snap, osx bundle, windows package etc).
right now riseup_vpn is branded for riseup (with assets, appname etc), but there are scripts that generate most of what is needed from a template, with the idea that the generic part can be extracted to a provider-agnostic repo.
short story long, riseupvpn debian package should be handled in the riseup_vpn repo, and not as a native package.
I've packaged another go piece (leap-geolocation), and the trick seems to be to vendor all the dependencies for a quick build.
Thanks for the explanation. I have more questions.
-
The present issue is requesting the Debian packaging of bitmaksk-systray, and not of riseup_vpn, correct? Should a new issue for packaging of riseup vpn be created in the riseup_vpn repository?
-
What is (should be) the technical relation between Debian packaging of bitmask-systray and of riseup_vpn?
-
What is the expected timeline for each of them? Is there a precedence?
-
drebs gitlab@0xacab.org writes:
Quoting Kali Kaneko (2018-12-14 10:08:45)
not exactly, although the distinction is subtle. bitmask-systray wants to be a generic package, what we call bitmask-lite. it's a go package that produces a single binary.
riseup_vpn is a repo that has helpers and other stuff needed to package a branded build of bitmask-systray (as a snap, osx bundle, windows package etc).
right now riseup_vpn is branded for riseup (with assets, appname etc), but there are scripts that generate most of what is needed from a template, with the idea that the generic part can be extracted to a provider-agnostic repo.
short story long, riseupvpn debian package should be handled in the riseup_vpn repo, and not as a native package.
I've packaged another go piece (leap-geolocation), and the trick seems to be to vendor all the dependencies for a quick build.
Thanks for the explanation. I have more questions.
- The present issue is requesting the Debian packaging of bitmaksk-systray, and not of riseup_vpn, correct? Should a new issue for packaging of riseup vpn be created in the riseup_vpn repository?
I'm interested in making a riseup_vpn package available. Lots of the people who have been trying the beta, who are linux people, complain about the snap store, and would like an alternative.
- What is (should be) the technical relation between Debian packaging of bitmask-systray and of riseup_vpn?
I suspect the difference will be small, the -systray is used to generate a branded riseup_vpn, so if we get a riseup_vpn package working, then the -systray one would easily follow.
- What is the expected timeline for each of them? Is there a precedence?
It should be done by December 17th, at 12:38am and 82 seconds. If it is any later than that, the code will turn into a Gremlin and require a lot of food and should not be near water.
But really, there is no expected timeline... For precedence, I'd go for the riseup_vpn package first, because people are using it and installing it.
-
requesting the Debian packaging of bitmaksk-systray,
no. as I see it, we need a) a package for riseup_vpn, that ships bitmask-systray + assets. b) a way of generating branded builds of the bitmask-systray package for other providers, with custom assets etc.
bitmask-systray does not need a package on its own.
-
Kali Kaneko gitlab@0xacab.org writes:
requesting the Debian packaging of bitmaksk-systray,
no. as I see it, we need a) a package for riseup_vpn, that ships bitmask-systray + assets. b) a way of generating branded builds of the bitmask-systray package for other providers, with custom assets etc.
I started a riseup_vpn package: git@0xacab.org:micah/riseup_vpn.git (debian branch).
It basically is me running dh-make-golang and then pushing the result. It does build, but it produces simply a binary /usr/bin/helper and then the /usr/share/doc stuff. So it needs some improvement
Would be happy to work together with drebs/kali or anyone to finish it off, I suspect it wont be too difficult.
It might be more fun to do it in Ukraine, with a lot of cheese on a windowsill, or we could do it on mumble. Or boring it on irc or asymmetrically on email.
mentioned in issue #85 (closed)
mentioned in issue #92 (closed)
-
Quoting micah (2018-12-18 18:48:02)
I started a riseup_vpn package: git@0xacab.org:micah/riseup_vpn.git (debian branch).
I think i don't have access to that repo, can you share it with me/us?
-
OK, i succeeded in building the package provided in the
debianbranch of micah's repository. This is what i did:git clone --branch debian https://0xacab.org/micah/riseup_vpn cd riseup_vpn/ git archive -o ../riseup-vpn_0.0~git20181129.863c6d8.orig.tar.gz 863c6d8 sbuildThe package currently doesn't know anything about dependencies. This is the list of dependencies downloaded when I do
go get .as described inbitmask-systray's README file:src ├── 0xacab.org │ └── leap │ ├── bitmask-systray │ └── go-dialog ├── github.com │ ├── apparentlymart │ │ └── go-openvpn-mgmt │ ├── getlantern │ │ ├── context │ │ ├── errors │ │ ├── golog │ │ ├── hex │ │ ├── hidden │ │ ├── ops │ │ └── systray │ ├── go-stack │ │ └── stack │ ├── gotk3 │ │ └── gotk3 │ ├── jmshal │ │ └── go-locale │ ├── mitchellh │ │ └── go-ps │ ├── oxtoacart │ │ └── bpool │ ├── ProtonMail │ │ └── go-autostart │ └── skratchdot │ └── open-golang └── golang.org └── x └── textI found the following deps already in Debian:
- stack: https://packages.debian.org/sid/golang-github-go-stack-stack-dev
- gotk3: https://packages.debian.org/sid/golang-github-gotk3-gotk3-dev
- go-ps: https://packages.debian.org/sid/golang-github-mitchellh-go-ps-dev
- open-golang: https://packages.debian.org/sid/golang-github-skratchdot-open-golang-dev
- x-text: https://packages.debian.org/sid/golang-golang-x-text-dev
Some questions:
- Is the package being built intended to be uploaded to Debian archive?
- How do we want to handle the 12 dependencies not in Debian?
- Are there minimum versions of the dependencies (so I can compare with those already in Debian)?
-
OK, i succeeded in building the package provided in the
debianbranch of micah's repository. This is what i did:cool, thanks for pushing it :)
- Is the package being built intended to be uploaded to Debian archive?
Yes, but first we'll get it in ours.
- How do we want to handle the 12 dependencies not in Debian?
Good question... I wonder if any of them can be reduced? Or we can join the go packaging team and do 13 packages. I know that sounds crazy, but I've done that before with ruby things. The team maintenance makes it work: you put the package in the team repo, following the standards, and then it is team maintained. This is where teams actually work, because they can do full team package changes easily, and anyone can update the packages... its just a matter of getting them in the first place.
- Are there minimum versions of the dependencies (so I can compare with those already in Debian)?
kali?
How do we want to handle the 12 dependencies not in Debian?
0xacab.org/leap/go-dialog is a fork of https://github.com/sqweek/dialog to add gtk3 support. Upstream doesn't seem to be interested on having gtk3 support :(, and we can not double link to gtk2 (systray) and gkt3. Maybe we can vendor/somehow include it in the same package.
All this are very minimall libraries, that don't bring any extra dependencies. If we find it too much work to package them we could explore how to vendor/include them in our code:
- "github.com/skratchdot/open-golang"
- "github.com/ProtonMail/go-autostart"
- "github.com/jmshal/go-locale"
- "github.com/mitchellh/go-ps"
- "github.com/apparentlymart/go-openvpn-mgmt"
Basically all the dependencies come from "github.com/getlantern/systray", which is the main library that we use to display the systray. I'm not sure what is the debian policy around it, if all getlantern stuff could be packaged as one package.
To build all the icon/*.go files we use github.com/cratonica/2goarray, I'm not sure if a "proper" debian package should rebuild those. And if that means that we should also package 2goarray. But I guess we can forget about that at least for now.
Are there minimum versions of the dependencies (so I can compare with those already in Debian)?
Go toolset is pretty bad (they are currently improving it) and there is no versioning. We have being fixing many things in the systray library and we want the latest version of it, but for the rest of the libraries AFAIK the debian version should work.
changed milestone to %RiseupVPN 19.01
-
micah @micah commented 1 week ago
Good question... I wonder if any of them can be reduced? Or we can join the go packaging team and do 13 packages. I know that sounds crazy, but I've done that before with ruby things. The team maintenance makes it work: you put the package in the team repo, following the standards, and then it is team maintained. This is where teams actually work, because they can do full team package changes easily, and anyone can update the packages... its just a matter of getting them in the first place.
There is a page documenting Debian Go Packaging. The overhead to go for 13 packages right now would be the creation of 13 RFPs, then the creation of 13 packages according to the rules documented in that page, and then waiting for them to be approved, which could take a long time.
meskio @meskio commented 1 week ago
To build all the icon/*.go files we use github.com/cratonica/2goarray, I'm not sure if a "proper" debian package should rebuild those. And if that means that we should also package 2goarray. But I guess we can forget about that at least for now.
If those files are included in upstream source (and they currently are) and if it is upstream's responsibility to manually maintain them, then I guess the source package does not need to know about that. If that changes then we might need to add 2goarray as a build-dependency.
OK, so here's a summary of deps, from where to grab them, and licenses:
Dependency Info License leap / go-dialog src ISC apparentlymart / go-openvpn-mgmt src MIT getlantern / context src Apache 2.0 getlantern / errors src ? getlantern / golog src Apache 2.0 getlantern / hex src "BSD-style" referring to unexisting LICENSE file (?) getlantern / hidden src ? getlantern / ops src ? getlantern / systray src Apache 2.0 go-stack / stack deb pkg MIT gotk3 / gotk3 deb pkg ISC jmshal / go-locale src ? mitchellh / go-ps deb pkg MIT oxtoacart / bpool src Apache 2.0 ProtonMail / go-autostart src MIT skratchdot / open-golang deb pkg MIT x / text deb pkg 3-clause BSD Taking the risk of being a bit too anal retentive, I think we might need to contact the ones marked with question marks in the table above to come up with the actual licenses those deps are being distributed under. We would need that info to properly write a COPYRIGHT file, either for the bundled case or for the crazy 13-package plan.
@meskio, can you confirm that is a complete and correct list of deps and their origins and licenses (so far as we know)?
@micah, can you confirm that the next step is to contact upstreams so they properly license their code?
Once those are confirmed I can take the next step (or come up with a new next step if needed).
-
@micah, can you confirm that the next step is to contact upstreams so they properly license their code?
I think that would be correct.
I looked up the ISC license, because I didn't know it, it appears to be DFSG-free: https://wiki.debian.org/DFSGLicenses#ISC_license. it's basically BSD-2-clause and legally equivalent to MIT/Expat
-
@meskio, can you confirm that is a complete and correct list of deps and their origins and licenses (so far as we know)?
AFAIK, yes. It's a go program, which means that all this are only buid-deps. I think the only dependencies of the binary package will be:
- libgtk-3-0
- libappindicator3
I would assume all
getlantern/*packages will have the same license, but we need to ask. Could all be bundled together in the same package as liblantern or whatever? BTW all this are libraries used in lantern software, for which there is a RFP (but not movement): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828932 mentioned in issue #89 (closed)
-
The approach above seems nice, and I agree that the most intensive part is going to be to file all ITPs. In the meantime, I've introduced vendoring https://0xacab.org/leap/bitmask-systray/merge_requests/51 and have a working package done against the source tarball, check riseup_vpn!18 (merged)
Also, we are moving helpers to bitmask-systray. My idea is to include debianization in the customized script, so that the flow would be like this:
- run customizer in bitmask-vpn repo
- enter the strings and assets for a given provider
- get output (with snap/ win/ osx/ and debian/ folders) and create a new per-provider repo with that.
For the CI, my plans are that this can be generated on the fly from bitmask-vpn repo. For maintaining it "the debian way", I prefer if we just keep the package on the riseup_vpn repo (it's using quilt for that reason, I don't want it to be a native package so that riseup is one more among other per-provider builds, ie: calyx-vpn, codigosur-vpn etc).
-
I worked with anarcat to plow through these packages. We managed to create ITPs for all of them, except for the go-dialog one because this one is a fork that @meskio did that needs to have that code merged upstream before we can package it.
We created packages for go-autostart, bpool, golog, context, go-openvpn-mgmt and have uploaded those to debian, they are currently waiting in NEW now.
There were a couple packages we could not complete, because they depend on some of the ones that are not licensed, those we pushed the state to salsa (debian's gitlab), they are basically finished, just pending the dependencies being available.
Dependency Info License leap / go-dialog src ISC apparentlymart / go-openvpn-mgmt ITP, in NEW MIT getlantern / context ITP, in NEW Apache 2.0 getlantern / errors ITP Apache 2.0 getlantern / golog ITP blocked Apache 2.0 getlantern / hex ITP "BSD-style"? getlantern / hidden ITP Apache 2.0 getlantern / ops ITP Apache 2.0 getlantern / systray ITP Apache 2.0 go-stack / stack deb pkg MIT gotk3 / gotk3 deb pkg ISC jmshal / go-locale ITP ? mitchellh / go-ps deb pkg MIT oxtoacart / bpool ITP Apache 2.0 ProtonMail / go-autostart ITP MIT skratchdot / open-golang deb pkg MIT x / text deb pkg 3-clause BSD Edited by meskio -
Related to the go-dialog: go-dialog#1
And the GTK3 upstream pull-req: https://github.com/sqweek/dialog/pull/21
-
Until I write the Customizer (see #107 (closed)), I think the current package under riseup_vpn will just do the-right-thing if we get the dependencies in the build environment (and adding them as build-deps in the control file, of course).
Edited by Kali Kaneko changed milestone to %RiseupVPN 19.02
assigned to @kali
-
Just an update with the already updated licenses and links to issues created by anarcat/micah:
Dependency License getlantern / errors ? getlantern / hidden ? getlantern / ops ? jmshal / go-locale MIT -
@drebs: was the closing intentional? should we create another issue with getting the package into debian then?
mentioned in issue riseup_vpn#61 (closed)
mentioned in issue #133 (closed)
-
It is already packaged: https://riseup.net/en/vpn/linux#package-installation
@kali can we close this issue? or is there something still missing?
But not distributed via official Debian stable repos. Can we please fix that and make sure that Bitmask package is included in Debian repos?
Edited by Avinash Sonawane-
But not distributed via official Debian stable repos. Can we make please fix that and make sure that Bitmask package is included in Debian repos?
the dependencies required to make this happen have been pushed into Debian, however not bitmask/riseupvpn itself. This has been a goal for a while, but at the moment because things are changing with regards to possible different dependencies, this is currently on hold.
added packaging label
mentioned in issue #552 (closed)
changed milestone to %Desktop Backlog
I see in #466 that packages are in debian now. Maybe this can be closed?
