Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add debian packaging information to the repository #655

Closed
cweagans opened this issue Nov 6, 2015 · 18 comments

Comments

Projects
None yet
8 participants
@cweagans
Copy link
Member

commented Nov 6, 2015

Referencing #652 (comment)

@viccuad already has this information prepared for upstream Debian inclusion, but we should put the packaging information in the repo here so that it's tracked and so that contributors can submit pull requests.

@viccuad Can you please clarify how upgrades will work via the Debian package repositories? If we're locked into whatever release initially goes in, I want to make sure that release is basically 1.0.0 (as opposed to 0.1.0 or some other kind of pre-release version)

@cweagans cweagans added the Packaging label Nov 6, 2015

@cweagans cweagans added this to the Initial release milestone Nov 6, 2015

@viccuad

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2015

Current status of the Debian package:

Almost done, waiting for #92 to be fixed, and I need to use the new flags implemented in #580 :).
Also, it would be nice to have git tags and/or tar.gz releases.

About including debian packaging info in the repos:

I (as Debian's package maintainer for Universal-ctags) don't need (nor desire) to have the debian folder included in the repo, as I will not use it (the Debian packaging tools delete upstream's debian folders and don't use them). Also, Debian (as many distros) mirrors the source code in their own git repo/ftp, since that allows distros to provide FOSS projects even if upstream people dissapear. Because of that, it's bound to get out of sync with the Debian mirror/git repo.

Now, if you as upstream intend to make your own unofficial .debs, then of course you are welcome to help yourself using the official Debian packaging info folder :). But in that case, please be aware that you will need to act as distro maintainer (be up to date on the developings of the distro, dependencies, etc) and that you will lose some Debian goodies (quality assurance, CI, bug testing, reproducible build checking, ~30 architecture builds, etc).

Questions and answers:

@cweagans said:

Can you please clarify how upgrades will work via the Debian package repositories? If we're locked into whatever release initially goes in, I want to make sure that release is basically 1.0.0 (as opposed to 0.1.0 or some other kind of pre-release version)

You will not be locked on any release :). Debian Unstable and Debian Testing are rolling releases, so they will always enjoy new versions.

@cweagans said (in other issue):

What does the update process for an official debian package look like?

This is the normal scheme:

There exist 3 Debian distributions: Debian Stable, Debian Testing, and Debian Unstable, each of one more faster updating than the other:

  1. Upstream publishes a release (by git tags and/or a tar.gz). Yay! Congratulations :)
  2. Debian package maintainer gets automatically notified thanks to the debian/watch file and Debian scrappers.
  3. Debian package maintainer merges the new version, sees if there are any quirks to be fixed, tries to fix them by making patches, sends those patches upstream and/or patches the Debian version meanwhile.
  4. Right following to that, uploads the new version to the Debian FTP repos, normally Debian Unstable.
  5. Debian Unstable users can apt-get it, yay! :)
  6. If in 5/10 days (configurable) that version hasn't received any Release Critical bugs, it automatically gets uploaded to Debian Testing. Debian Testing users can apt-get it, yay! :)
  7. Every 2 years more or less, there's a Debian release, which consists on taking a snapshot of the state of Debian Testing, and freezing those packages, which will only receive bugfixes (as new versions always add new bugs). You can install new versions of selected packages in Stable by using Debian Backports, though.

Also, Debian Experimental exists: it normally contains, well, experimental versions, to be used in conjuction with Debian Testing and/or Unstable (eg: tmux, notice the Accepted tmux 2.1~git20151017-1 (source) into experimental)

In parallel to all of that, twice a year Ubuntu takes a snapshot of Debian Unstable (with a couple of touches) and calls that an Ubuntu release. Among other Debian derivatives.

If you want to learn more about how Debian works, don't hesistate to come by the ircs (#debian, #debian-next on oftc.net) or have a look here and here for example.

@vhda said (in other issue):

@viccuad would you be willing to create a PR (at the time you find appropriate) to have the debian folder merged into our repository?

Let me fix the quirks already there so there's a working Debian package that doesn't need preinstall/postremove hooks to clean changed config folders (I don't want to package it and do a half-job or not care about quality), and I would be happy to create a PR to include the debian folder in this repo if that's what Universal-ctags desires (but please, take into consideration what I have said before).

@cweagans

This comment has been minimized.

Copy link
Member Author

commented Nov 6, 2015

Thanks for the very detailed information! This is all good stuff to know about.

I was under the impression that we needed to include the debian packaging scripts in the repo, but if that's not the case, I'm definitely okay leaving it out, especially given the benefits that come from letting Debian do it's own thing (reproducible builds and all that). @vhda - that okay? One less thing for us to maintain.

Also, Debian (as many distros) mirrors the source code in their own git repo/ftp, since that allows distros to provide FOSS projects even if upstream people dissapear.

Does that mirror automatically update whenever we commit something to this repo? Happy to set up a web hook or something for you if that would help.

Re debian release process (last question, I promise):

If we are alerted to some kind of security bug or something, is there a process for getting a patch to fix that into Debian Stable, rather than waiting some number of years to it to eventually trickle down? I see that Debian Stable allows for bug fixes, but I'm not clear on how they will get from this github repo to the package in Debian Stable.

@viccuad

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2015

Does that mirror automatically update whenever we commit something to this repo? Happy to set up a web hook or something for you if that would help.

We can manually do a git pull at any time, or get it automatically updated with tags. Since the Debian packages are going to track your (upstream) releases, I don't really see a need for automatically update for every commit. If you want faster moving versions, then, release early release often they say :P.

If we are alerted to some kind of security bug or something, is there a process for getting a patch to fix that into Debian Stable, rather than waiting some number of years to it to eventually trickle down? I see that Debian Stable allows for bug fixes, but I'm not clear on how they will get from this github repo to the package in Debian Stable.

Yes, of course, bug fixes get backported to the Stable versions (that's my job): when we all notice a security bug, we (normally you because you know the codebase better) implement a fix, you ship your version, and I backport the fix to Stable.

Normally a Debian foobar package (or other distro packages) have the following version numbering/naming:

  pkgname-upstreamversion-distroversion   ( eg: foobar-3.4-3 )

In the specific case of Debian Stable, the bugfixes (applied by me) would bump the distroversion only.

@cweagans

This comment has been minimized.

Copy link
Member Author

commented Nov 12, 2015

Closing this, as there's nothing for us to do here. I'll make a note to update this issue when we have our release.

@TomRoche

This comment has been minimized.

Copy link

commented Oct 5, 2016

What is the status of the Universal Ctags Debian packaging? As of 0200 UTC 5 Oct 2016, when I search packages.debian.org on ctags, I see only 2011 builds of Exuberant. When I search on universal, I don't see anything tag-related. Am I missing something?

@viccuad

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2016

Hi, I'm the current one listed on the ITP (Intend To Package) Debian bug for universal-ctags, which I opened with the intention to have universal-ctags be my first maintainership of a package in Debian.

In that moment, I stated in this message my desire to get a 1.0 release and have some issues resolved before starting maintaining universal-ctags,.

In the meanwhile, I have started maintaining several packages in Debian, and also have moved to Emacs (for which Global meets my needs), so I have to say that sadly I'm stepping down from making the legwork to have universal-ctags included in Debian; I would not have the time nor the will for it.

I will take myself out of the Debian's ITP (Intend To Package) bug open for universal-ctags, and put it back to a RFP (Request For Packaging), for someone to grab. I would be glad to give any pointers to anybody that wishes to maintain a Debian universal-ctags package, and I would love to see somebody to step in :).

@ardumont

This comment has been minimized.

Copy link

commented Oct 24, 2016

Hello,

I would be glad to give any pointers to anybody that wishes to maintain a Debian universal-ctags package, and I would love to see somebody to step in :).

@viccuad step in :D

In that moment, I stated in this message my desire to get a 1.0 release and have some issues resolved before starting maintaining universal-ctags,.

Well, as a first approximation, using it as is is ok with me :D

I will take myself out of the Debian's ITP (Intend To Package) bug open for universal-ctags, and put it back to a RFP (Request For Packaging), for someone to grab.

For now, i need to package it for the Software Heritage project.
And if it's all good, it'd be worth the effort to push it all the way to debian and i'll do it.

My alioth nick is ardumont-guest (i have packaged some python ones).

For the sake of not duplicating efforts, do you have any available repository from where i could continue your initial work?

Thanks in advance

Cheers,

@viccuad

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2016

@viccuad step in :D

That makes me happy! :)

For the sake of not duplicating efforts, do you have any available repository from where i could continue your initial work?

I forgot to attach the status of the package when I left the ITP, I
have done it now :)

@ardumont

This comment has been minimized.

Copy link

commented Oct 28, 2016

I forgot to attach the status of the package when I left the ITP, I
have done it now :)

Thanks, I'll merge in your work in mine :D
(I mostly work with the rules so far and within it not the doc part)

Cheers,

@ardumont

This comment has been minimized.

Copy link

commented Oct 28, 2016

FWIW, work in progress is https://github.com/ardumont/universal-ctags

(It's WIP so the master branch will get rewritten.)

@sim590

This comment has been minimized.

Copy link

commented Dec 31, 2016

@ardumont. I see you have taken responsability of the debian package. What's the status? I know that it is not yet either in testing or unstable. Is there a package source I can safely build myself in the meantime?

@ardumont

This comment has been minimized.

Copy link

commented Dec 31, 2016

Hello,

What's the status?

I successfully built and deployed a version (from end of october 2016, ardumont/universal-ctags@7859817).
This is from the current master branch of my fork.

Note: Technically i deployed the package built from 'swh' branch which is one commit more from the master one. (for detail: ardumont/universal-ctags@66c5a95).

But for building, using the master one is sufficient.

I know that it is not yet either in testing or unstable.

Indeed.
I did not yet make the time to push it towards Debian.

Is there a package source I can safely build myself in the meantime?

Well, you could build from my fork from the master branch using gbp buildpackage.
Like i said, it worked at the time.

I did not check it still builds though...
Well, scratch that, i did with:

git clone git@github.com:ardumont/universal-ctags.git
git checkout master
# if not installed (note that i'm on testing and i needed it for jessie).
# sudo apt install cowbuilder; git-pbuilder create
gbp buildpackage --git-pbuilder

And it's still ok.

Cheers,

@jcharaoui

This comment has been minimized.

Copy link

commented Mar 30, 2018

Just for the record, universal-ctags is now part of the Debian package archive. Congrats!

@masatake

This comment has been minimized.

Copy link
Member

commented Mar 31, 2018

Thank you.

I tried it.
I have two comments.
It seems that the man pages are not included. Though the pages are written in progress, they will be useful (even for me).
libxml2 is not linked. If it is linked, ctags can handle more xml based languages.

@hnakamur

This comment has been minimized.

Copy link

commented Jun 7, 2018

Hello, I just built a deb package for Ubuntu 18.04 LTS based on the Debian universal-ctags package.

I made three modifications:

  • included the man pages and also add ctags.1.gz to update-alternatives.
  • linked with libxml2, libjansson, libseccomp, libyaml, and libaspell.
  • add a patch for skipping one test: Tmain parser-own-fields stdout comparison (This is needed to avoid the following diff which happens only on the Ubuntu PPA build. This diff does not happen on my local build using pbuilder.).
--- /<<BUILDDIR>>/universal-ctags-0+SNAPSHOT20180606/Tmain/parser-own-fields.d/stdout-actual.txt      2018-06-07 13:20:17.380303536 +0000
+++ ./Tmain/parser-own-fields.d/stdout-expected.txt   2018-06-07 05:45:08.000000000 +0000
@@ -1,0 +2,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f   
+baz  input.unknown   /^private func baz(n,...);$/;"  f
+foo  input.unknown   /^public func foo(n, m);$/;"    f   
@@ -2,0 +6,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f       signature:(n)
+baz  input.unknown   /^private func baz(n,...);$/;"  f       signature:(n,...)
+foo  input.unknown   /^public func foo(n, m);$/;"    f       signature:(n, m)
@@ -3,0 +10,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f       protection:protected
+baz  input.unknown   /^private func baz(n,...);$/;"  f       protection:private
+foo  input.unknown   /^public func foo(n, m);$/;"    f       protection:public
@@ -4,0 +14,3 @@
+bar  input.unknown   /^protected func bar(n);$/;"    f       protection:protected    signature:(n)
+baz  input.unknown   /^private func baz(n,...);$/;"  f       protection:private      signature:(n,...)
+foo  input.unknown   /^public func foo(n, m);$/;"    f       protection:public       signature:(n, m)
@masatake

This comment has been minimized.

Copy link
Member

commented Jun 7, 2018

@hnakamur, thank you for reporting.

libaspell is not needed for normal users. It is linked for developing ctags itself.
About the failure of Tmain parser-own-fields, could you open a new issue for it?

masatake added a commit to masatake/ctags that referenced this issue Jun 8, 2018

Tmain: verify the stderr output of parser-own-field test case
As @hnakamur reported on universal-ctags#655, parser-own-field.d is failed
when runnint it on "Ubuntu PPA build". stderr output of the
case is needed to make the root cause clear.

Signed-off-by: Masatake YAMATO <yamato@redhat.com>

hnakamur added a commit to hnakamur/universal-ctags-deb that referenced this issue Jun 8, 2018

Stop linking to libaspell
Since it is only needed for developing ctags itself.
universal-ctags/ctags#655 (comment)
@hnakamur

This comment has been minimized.

Copy link

commented Dec 15, 2018

#655 (comment)
My merge requests for adding manpages and adding libxml2 to the official Debian package are now merged.

@masatake

This comment has been minimized.

Copy link
Member

commented Dec 15, 2018

@hnakamur, thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.