search

hoytech / vmtouch

Portable file system cache diagnostics and control
https://hoytech.com/vmtouch/
BSD 3-Clause "New" or "Revised" License
1.81k stars 214 forks source link

debian packaging #47

Open anarcat opened 7 years ago

anarcat commented 7 years ago

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?

hoytech commented 7 years ago

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?

anarcat commented 7 years ago

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.

anarcat commented 7 years ago

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. :)

hoytech commented 7 years ago

Sorry I read through and responded to your pull request before reading this. Your second suggestion sounds fine, thanks!

anarcat commented 7 years ago

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 ee5899d24f9aa5592d72772a0fdaebc001fe2d1e and f5112ce46fbe6446fbfa8a5ddaed05bb144ba426.

in ee5899d24f9aa5592d72772a0fdaebc001fe2d1e, 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 f5112ce46fbe6446fbfa8a5ddaed05bb144ba426, 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...

hoytech commented 7 years ago

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: 146bcec1cee14303dd2e744f09773a6c931dc6fa

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!

anarcat commented 7 years ago

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!

rutsky commented 7 years ago

What is the status of Debian packaging?

hoytech commented 7 years ago

Ack.. We're waiting on me to cut a release. I'll try to get to that today. Sorry!

hoytech commented 7 years ago

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!

anarcat commented 7 years ago

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

hoytech commented 7 years ago

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!

hoytech commented 7 years ago

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.

lnussbaum commented 7 years ago

I'm interested in getting vmtouch into Debian.

I do have two questions:

  1. who wants to co-maintain (or be the main maintainer, but I'm fine with having that role) the package in Debian?
  2. 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.
hoytech commented 7 years ago

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. :)

lnussbaum commented 7 years ago

hi,

Being a co-maintainer is mainly a statement that you will monitor (and fix, if needed) the status of the package in Debian.

hoytech commented 7 years ago

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.

anarcat commented 7 years ago

On 2017-08-06 10:26:40, Lucas Nussbaum wrote:

I'm interested in getting vmtouch into Debian.

I do have two questions:

  1. who wants to co-maintain (or be the main maintainer, but I'm fine with having that role) the package in Debian?
  2. 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.

I'm fine with anything. I can co-maintain if help is needed or sponsor uploads from time to time if that's prefered.

I do not object to any workflow. :) I figured upstream was interested in collaborating in packaging and was trying to figure out the best way to do that...

Anything goes for me.

PS: I'm at debconf and would be happy to just push this out the door here as well.

lnussbaum commented 7 years ago

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).

hoytech commented 7 years ago

@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.

lnussbaum commented 7 years ago

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)

hoytech commented 7 years ago

Thanks for the heads-up! I've registered and subscribed.

I'll chime in on the mailing list, that's not a problem.

hoytech commented 7 years ago

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.

MichaIng commented 4 years ago

@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