You are not logged in.
Fellow BunsenLabs users
I wrote an initial jgmenu post about a year ago. At that time the project was pretty young at 80 commits and ~3000 lines of C code. Today we are at 440 and ~7500 respectively; and many of its early quirks have been ironed out.
Several of you have helped with ideas, testing and encouragement for which I'm grateful.
I've reached a point where I'm wondering two things:
a) what might be the appetite from the BL dev team and community to add a jgmenu .deb package to the backports in order to make it more accessible for those users who don't like to build themselves.
There is an AUR package which I've maintained myself since early days. More recently a Linux Void package has appeared.
b) depending on the answers to (a), I might need some help from anyone with some packaging experience to give my attempt a sanity check (@nobody/@earlybird/@johnraff???).
cd packaging ; ./make-debian.sh
dpkg -i jgmenu_0.7.2-1_amd64.deb
Johan
P.S. Simple wiki at https://github.com/johanmalm/jgmenu/wiki
Last edited by malm (2017-10-19 21:26:37)
Offline
First of all congratulations to the fantastic menu! That must have been a serious amount of work.
The screenshot with the numix-circle icon theme is awesome.
I'd like to have a .deb package, it'd make things easier.
Offline
@malm many thanks for all your work on this!
what might be the appetite from the BL dev team and community to add a jgmenu .deb package to the backports
This will depend on:
1) How much demand there is from the community.
2) How much work would be needed by the devs to implement this.
3) Whether our webmaster @nobody permits it.
So I think we have to wait a bit to evaluate 1), then 2) would be helped if you rearranged, or cloned, your git repo in the form of a Debian package source. That is, with a "debian" directory in the root, not in "packaging", and not to rely on scripts to build the .deb, but set up the repo contents so that dpkg-buildpackage and the usual debian tools can do it.
If you have a look at some existing debian source repos you'll see what I mean. Our BL packages are mostly very simple, just copying files into place, so for examples of compiling you'll need to look elsewhere.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Thanks both. That's great.
Re (2), yes happy to set it up so it minimum effort. I've read up a bit, but it would be useful to have a quick discussion at some point if we want to take it further.
Offline
I've packaged it up for Debian 8 & 9 (wheezy doesn't have libmenu-cache-dev) and several Ubuntu variants:
https://download.opensuse.org/repositor … ck:/jgmenu
Here is the debian.tar.gz file with the "debian" folder containing all of the packaging details:
https://download.opensuse.org/repositor … ian.tar.xz
@malm: the `dh_make` command (from the dh-make package) can be used to generate a template "debian" folder that can be filled out.
Offline
^Oh gosh. How did you do all that? Did you cross-compile?
@johnraff/@earlybird/@Head_on_a_Stick: Thanks. I realise that I know even less than I thought about debian packaging and associated work-flows. I did try! I simply followed Introduction to Debian Packaging as I went.
I should have explained what I had done. In summary, I:
* created the "debian" files under packaging/debian/
(sorry - I should have said)
* wrote the script make-debian.sh which
- creates the jgmenu_XXX.orig.tar.gz based on last tag (but ignoring any commits+tracked/untracked changes since that tag);
- unpacks the tarball above;
- runs debuild (dpkg-buildpackage, lintian, etc) on the unpacked tarball + debian directory.
I tried putting the debian/ directory and files in the top level directory, but
- `debuild -us -uc` complained about no .orig tarball
- I thought `git checkout <latest-version>` would be a bit clumsy (particularly for me as my repo is generally full of tracked changes which I might not want to commit at that point)
The instructions on the Debian website seemed to be written around an "upstream tarball" and guidance on how to manage this in the "upstream" git repo were numerous+varied (and not easy for me to understand).
I'm not hard over on any of this, but it would seem nice to me to manage the debian files within the current git repo (and am I right in thinking it would mean less work for everyone else). I'm grateful for any advice, on
- debian/ dir in top level directory or leave as is (but how do I avoid the "missing" .orig tarball warning)
- how important is it to update debian/changelog if it's in a git repo anyway (could I just leave it as one entry and just change the version+date?)
- without the make-debian.sh script, would the person packaging have to do a `git checkout XXX`?
- is it easier to manage the debian-packaging from a separate git-repo?
If I've completely misunderstood the whole thing, please go easy on me
Last edited by malm (2017-10-20 20:53:27)
Offline
How did you do all that? Did you cross-compile?
Not at all no, I just built the package locally on a stretch-based system then used the .debian.tar.gz & .dsc files (along with the original tarball) to generate the packages in the openSUSE Build Service Repositories.
Anybody can make an account at the OBS and forum member @stevep has written a nice guide over at fdn:
Offline
jgmenu is now available in BL jessie-backports and stretch-backports, and will be continuously updated as upstream releases new versions (@malm did all the work).
Offline
^Nice!
Where should we now post support questions and bug reports?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
@nobody: thanks for the support.
@johnraff: good point
For bugs and issues, could I suggest https://github.com/johanmalm/jgmenu/issues
For advice and general support, I think a forum thread is the best option. I'm happy to carry on using the original thread under "Scripts, Tutorials & Tips" (which I subscribe to), but do say if you prefer another category.
I'm also happy to PM or e-mail.
Offline
@malm thanks - I do have a question, but "Scripts, Tutorials & Tips" is really for sharing stuff that works, rather than Q&A, so I'll post something under "GUI & Applications" and if it turns out to be a bug, then on GitHub.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
That's great. Sounds very sensible.
Offline