debian packaging
anarcat opened this issue · comments
hi
i see that Debian packaging for this tool has mostly stalled. it looks like the biggest blocker is finding a sponsor to upload the package... while I am not directly a user of this, i think it could be useful and would consider sponsoring uploads if you would be ready to maintain the debian/ directory here upstream. i could do a few small updates to bring it to speed to latest changes (e.g. debhelper 10, automatic dbgsym packages and so on) and hand it back to you.
what do you think?
Thanks very much for the offer! I'm happy to accept patches for the debian/ directory, although I'm not very familiar with debian packaging policies. Hopefully somebody from debian will just email me and/or submit a pull request when something needs upstreaming?
i'm from debian. :) i see that most of the work was already done - i could send pull requests, but it would be best if you were familiar enough with the package to deal with routine tasks (e.g. updating debian/changelog, mostly) and ping the sponsor (e.g. me) when a new release is done so i can upload it.
i've made a PR in #48 that covers most of the stuff i found needed updating with the package. it would not quite make sense to make a package out of 1.2.0 just yet, because there has been commits on top of it. we would need to coordinate the 1.2.1 release... ideally you would how to do this yourself: it's just an addition to debian/changelog, see #48 for a discussion about where to maintain CHANGES...
basically, doing a release could be as simple as:
dch -D unstable -U new release
git commit -m'prepare new debian package'
git push
mail anarcat@debian.org -s 'please upload latest vmtouch, ktxbye' < /dev/null
if you want to manage the changelog automatically, this would become:
gbp dch
dch -D unstable
git commit -m'update changelog'
git push
mail anarcat@debian.org -s 'please upload latest vmtouch, ktxbye' < /dev/null
In the above, you used the git-buildpackage (gbp) and devscripts (dch) debian package, on top of git and mail which i assume you already know. :)
Sorry I read through and responded to your pull request before reading this. Your second suggestion sounds fine, thanks!
okay then - i guess the only thing that remain is to merge CHANGES and debian/changelog and to make a new 1.2.1 release?
also, i didn't underline this in the PR, but you may specifically want to review ee5899d and f5112ce.
in ee5899d, i had to override MANDIR because your Makefile installs the manpages in a non-standard location (/usr/man instead of /usr/share/man). well, maybe /usr/man is some standard (FSSTND, from 1995) but most distributions seem to have switched to /usr/share/man (including Debian and FreeBSD, at least).
in f5112ce, i made a mostly cosmetic change to simplify the install target (remove a fork for pwd) but that stuff shouldn't be necessary, as debhelper usually passes DESTDIR and PREFIX to ./configure when building... we don't have ./configure, so I am not sure how this is supposed to be passed, but it would probably be nice to support DESTDIR in the makefile, which would shorten that install line slightly...
Sorry about the delay, I'm back now.
Regarding your first point about the man paths, I updated the main Makefile and got rid of your override here: 146bcec
For the second point, I agree, calling out to pwd was unnecessary, thanks for fixing that. I'll hold off on adding DESTDIR to the Makefile since the line in debian/rules seems fine to me.
I'll write up the CHANGES and merge them into debian/changelog so we can do a release. I'd like to give you credit in the CHANGES file, what do you prefer, just "anarcat"?
Merci beaucoup!
excellent. regarding DESTDIR, it's just more convenient for other distributions, but not mandatory... it's a quite common practice, however, and i recommend you follow it.
"anarcat" is fine for credits, thanks!
What is the status of Debian packaging?
Ack.. We're waiting on me to cut a release. I'll try to get to that today. Sorry!
OK I have released 1.3.0, hopefully with a reasonable debian/changelog.
@anarcat - sorry for the delay, I'm going to ping you by email and ask for the upload. Thanks!
i unfortunately do not have much time to followup on this right now, and i'm not currently using vmtouch. i suggest you find another sponsor unless you are ready to wait until i am free... the following links may be helpful in that regard:
https://mentors.debian.net/
https://wiki.debian.org/DebianMentorsFaq
No worries, let's just wait until you have spare time. As far as I'm concerned there's no hurry. I think you are still listed as the uploader in the control file (not sure what that means exactly). Thanks!
I created an Ubuntu PPA, so if you're on 16.04 you should be able to do:
sudo add-apt-repository ppa:hoytech/vmtouch sudo apt-get update sudo apt-get install vmtouch
Please let me know if there are any packaging problems.
I'm interested in getting vmtouch into Debian.
I do have two questions:
- who wants to co-maintain (or be the main maintainer, but I'm fine with having that role) the package in Debian?
- does someone object to using a simple workflow where we just use upstream release tarballs (+ patches if needed) ? I find the workflows where we track upstream's git tree inside the packaging tree more complex than necessary for such a "simple" package.
Thanks! I'm not very familiar with the debian workflow. What does being a co-maintainer entail? I'm happy to accept patches to ease integration, push new tarballs when I tag releases, and so on.
I have no objection to simple tarball releases. All else being equal I prefer simple solutions. :)
hi,
Being a co-maintainer is mainly a statement that you will monitor (and fix, if needed) the status of the package in Debian.
OK that is not a problem, I can co-maintain the package. Just send me a PR if you want to modify the debian/ directory in the vmtouch repo. I'm also fine with starting from scratch if you prefer.
so, I've uploaded vmtouch. The git repo for the Debian packaging is at
https://anonscm.debian.org/cgit/collab-maint/vmtouch.git
@hoytech could you please apply
https://anonscm.debian.org/cgit/collab-maint/vmtouch.git/tree/debian/patches/add-LDFLAGS-to-cc-call.patch so it's included in the next release?
I've done minor fixes to the packaging, you might also want to sync your own git repo so that out-of-Debian packages behave the same.
I'll report back when the package gets accepted in Debian. At that point you will be able to subscribe to information about the package on https://tracker.debian.org/pkg/vmtouch (but that will only exist when the package gets accepted, which should take a few weeks at least).
@lnussbaum / @anarcat : thank you!
I've pushed the LDFLAGS patch and I'll sync the repo soon, or perhaps when it gets added to the tracker.
hi!
vmtouch is now in Debian: https://tracker.debian.org/pkg/vmtouch
you might want to use the above page to "subscribe" to the package's bug reports etc.
And... there's already a bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874145
How do you want to handle it? Do you prefer to shime in directly in the Debian bug, or do you prefer me to open an issue on github? Both work for me. (we can probably provide a shell account on a Debian GNU/kfreebsd box, and on a Debian GNU/Hurd box, if you want to look into this specific issue yourself)
Thanks for the heads-up! I've registered and subscribed.
I'll chime in on the mailing list, that's not a problem.
I've created a github issue for these platforms: #58.
@lnussbaum : Thanks for the offer of shell accounts. I imagine we can solve the compile problems without, but if you have a shell handy I can test to see if page eviction is possible on these platforms. I imagine kFreeBSD will just be msync(MS_INVALIDATE) but I have no idea about hurd.
@hoytech @lnussbaum @anarcat
I found the debian/ files out of sync for a while, probably the few formal changes from downstream could be committed into upstream.
As you were discussiing the work flow: Probably it is easiest to commit all Debian-side changes into upstream directly and commit back to Debian sources from there? Since also Ubuntu uses the unchanged Debian sources (same maintainer anyway 🙂) and you three are the mentioned (co-)maintainers in control file, there are hopefully no conflicts. Even the "Maintainer" and "Uploaders" fields make sense then as they are in Debian sources, taking into account that this is for package integration and these meta/formal package things are best maintained by an experienced Debian maintainer anyway 😉.
Another topic: #77