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.

Sign up for GitHub

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

Jump to bottom

Packaging OpenBoard for Debian #170

Open
sunweaver opened this issue Sep 21, 2018 · 19 comments
Open

Packaging OpenBoard for Debian #170

sunweaver opened this issue Sep 21, 2018 · 19 comments
Labels
building / packaging

Comments

@sunweaver
Copy link

Dear upstream maintainers of OpenBoard,

I am currently in the process of bringing OpenBoard to Debian unstable (and finally to upcoming Debian 10 and all derivatives of Debian).

I will provide OpenBoard preview packages for Debian stretch and Debian testing soon and I'd love to get some feedback on the functionality (that you know much better than me).

I found some issues already, that I hope to iron out with your help (e.g. the podcast recorder does not work).

Package URL will come, once the packages are available online.

Thanks for working on OpenBoard,
Mike
@sunweaver
Copy link
Author

http://packages.it-zukunft-schule.de/debian/pool/main/o/openboard/

@mariodebian
Copy link
Contributor

@sunweaver Can you change build-deps to libquazip5-dev?

You also need to edit 2001_no-third-party-software.patch file to change includes path <quazip/xxxx.h> => <quazip5/xxxxh> and LIBS += -lquazip5

libquazip-dev is build with Qt4 and OpenBoard segfault when you try to export a board to file in ubz format.

Thanks for packaging !!!

@mariodebian mariodebian mentioned this issue Oct 1, 2018
Closed
@sunweaver
Copy link
Author

sunweaver commented Oct 1, 2018 via email

@sunweaver
Copy link
Author

sunweaver commented Oct 1, 2018 via email

This was referenced Oct 24, 2018
Closed
Open
@claurita
Copy link

Hi all,
I finally found the time to test the deb source package to compile on an unstable i686.
First of all, thank you very much for your work.
I first tried the 1.4.1 package at http://packages.it-zukunft-schule.de/debian/pool/main/o/openboard/
Just a couple of notes about it (it's anyway the only "full" package I found and later works still suffer the same problems)

  1. I had pkg-config 0.26-1 and there was no i686-linux-gnu-pkg-config, that is required by qmake. I had to update to 0.29. It took me a bit to understand the problem, so a check for the version could be a good idea, but I don't know when the cross-compiling feature was added exactly.
  2. There are strange dependencies warning fired by dpkg-shlibdeps:
    dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/openboard/usr/bin/OpenBoard was not linked against libva-x11.so.2 (it uses none of the library's symbols)
    The same warning applies to libxcb-xfixes, libtheoraenc, libpulse, libxcb, libx264, libva, liblzma, libxcb-render, libtheoradec, libvorbisenc, libxcb-shape, libGL, libglib, libSDL-1.2, libopus, libvpx, libmp3lame, libpulse-mainloop-glib, libbz2, libasound, libass, libvorbis, libdl, libxcb-shm, libogg, libfreetype, libQt5XmlPatterns
    Sincerely I cannot understand if these warnings are false positives.

Then I looked at salsa openboard project(s), and the first (obvious) question is "why two different projects?"
Anyway I focused on the one where Mike is involved (it seams the natural prosecution of the present thread).
I decided to directly try it with the 1.5.1 version of openboard.
The only thing that is not working is the 2006 patch (the fonts credits). But the whole package gets successfully built (the "problems" of 1.4.1 remain) and the program runs well.
Then I tried to compare the project with the one by Jonah Brüchert (that is already updated to 1.5.1, but no changes were made from 1.5.0 to 1.5.1, but the changelog).
The patching approach is a bit different, maybe simpler, so is there any way to discuss the different choices made and eventually to merge them?

Thank you
Claudio

@sunweaver
Copy link
Author

sunweaver commented Dec 21, 2018 via email

@claurita
Copy link

Oops! I got confused with the other post where I presented myself. Really sorry!
Seven years ago I started a Sid based diskless project for Italian schools (it's named ics = Informatica Condivisa e Sostenibile) as I did not found anything like what I had in mind. It's a very small project (about 40 schools and 3000 PC), because I'm still the only developer involved and the ministry keeps ignoring us.
I'm a (rather old, sigh) C programmer specialized in kernel drivers and network protocols on embedded systems (but on PCs too). Not a native system maintainer, but I'm doing my best. School is my other big passion and I really hate Italian school total dependency from microsoft, so I'm trying to do my share of work to change things (but it's a veeery looong way, here).

Coming to openboard, the two projects I mentioned were yours and Jonah Brüchert's, both on salsa:
https://salsa.debian.org/jbb-guest/openboard-packaging

I suspected that most of your patching was to honour DFSG; Jonah seems a bit more flexible on this. But there is something about QtSingleApplication that I cannot fully evaluate (I use only GTK & co, shame on me) but attracted my attention (your 2003 vs. Jonah's 0004). Anyway, first of all, let's work together, don't you agree?

About my vintage pkg-config, it's my fault, I already accused myself, even if I don't understand why no build tool reclaimed it (qmake absolutely should, in my opinion). The only packages I must compile myself on ics are kernel drivers of some whiteboards and a bunch of X11 drivers too old to be true.

About dpkg-shlibdeps, I admit my ignorance about official Debian requirements, but in my opinion a lib dependency should only be direct.
And I feel that none of those libraries are directly called by openboard, so I think it could be fine (maybe wise?) to trust dpkg-shlibdeps and clean up the dependency part.

One last prayer, can you please take a look at my issue #133 ?
It refers to my very first openboard compilation (1.4.0), in a totally manual fashion. But music has not changed, unfortunately.
My dirty workaround is not fully functional (icons are ok, but the pen colour is not selected on start) and I really wonder what's going on and why I'm the only one on earth with this problem (I really don't think about another vintage piece of sw, this time, they cannot hide themselves forever...).
Claudio

@sunweaver
Copy link
Author

sunweaver commented Dec 21, 2018 via email

@jbruechert
Copy link
Contributor

jbruechert commented Dec 21, 2018 •
edited

@sunweaver I would be interested in helping on your official packaging. We started packaging nearly at the same time, and because I didn't manage to build your package last time I tried, I kept maintaining my repository as well. So far not much work went into it, since I basically merged over my patches I worked on for the flatpak (https://github.com/flathub/ch.openboard.OpenBoard) anyway.

My motivation for packaging OpenBoard is mostly making it easier to use in my school, although I can't yet say whether it will be used in my school in the end at all.

@jbruechert
Copy link
Contributor

The QtSingleApplication has been just patched out for the flatpak, since I didn't get it to work inside the sandbox anyway.

@sunweaver
Copy link
Author

sunweaver commented Dec 21, 2018 via email

@claurita
Copy link

Hi, sorry for the delay. I had to work today.

The QtSingleApplication stuff attracted my attention because I faced, on 1.4.0, another very annoying problem with some whiteboards, all managed by hid-multitouch driver (at least three different models). Sometimes openboard totally freezes, even if pointer keeps on moving and keyboard remain partially functional (I can switch to another console and kill openboard). The simplest deterministic way to obtain this, is just opening the File menu by touch (!). Notice that Sankore has no problem with the same WBs. I haven't tried 1.5.1 yet.
Obviously, working with the mouse does not trigger the bug and I have no whiteboard in my office, so it's very difficult to investigate, but it smells like a semaphore out of control. Hence the initial interest in that "Single" and in the Jonah's approach to cut it totally off (it gains my vote, anyway; I prefer "simple" to "single").

I preferred to comment here this time in the hope that someone else has a similar problem.
But I agree to avoid spamming github.

Claudio

@kaamui kaamui mentioned this issue Jan 9, 2019
Closed
@kaamui
Copy link
Member

kaamui commented Jan 9, 2019

Hi everyone,

First of all, thank you for the huge work and amount of time that you all devote to OpenBoard. It is a real pleasure to see such an active community with us, to help handling every aspect of uses and every expectation.

We are aware that we don't spend enough time answering/helping you all, and are doing our best to do more, but as you may have read a couple of times in the issue tracker, we currently have very limited resources.

The cross-platform development of OpenBoard, testing on the three official supported operating systems, fixing, improvement or adding of functionalities, translations, on multiple devices, etc has to be done in the couple of weeks per year we have. As a small team, we do our best to manage as well as possible Github, and take time to discuss with you all is one of the most important missing aspects of this project, with documentation. We are aware of it. However, the many challenges that await us every year prevent us to do as much as we want, and we can only hope that you'll understand.

In a more technical overview, as the only active developer for the moment, it is impossible for me to take time to test on other operating systems how the build/packaging is behaving, neither to investigate what is currently the most perfect solution to consider on this question. The issue with the old version of QtSingleApplication (causing some crashes when closing OpenBoard), the openSSL handling, the switch to ffmpeg4 on every supported os, the xpdf API, and more globally the third-dependencies that we also would like to avoid, are just a little part of the "todo list" on witch we can't go forward that much at this time.

From the whole team, thank you all, and keep up the good work. Thank you for your precious help, maintaining alive the community and the issue tracker ;)

@sunweaver
Copy link
Author

New builds for Debian stretch have arrived in one of my unofficial Debian add-on repositories (builds for testing/unstable are w-i-p):
http://packages.it-zukunft-schule.de/debian/pool/main/o/openboard/

@sunweaver
Copy link
Author

sunweaver commented Jan 9, 2019 via email

@kaamui kaamui pinned this issue Jan 9, 2019
@kaamui
Copy link
Member

kaamui commented Jan 9, 2019

To me it seems that you have an internal development workflow and
probably also internal issue tracking. As your issues don't appear on
Github. Or do they? - Is that so?

We indeed have an internal issue tracker specially made for the team, and only used by it. The reason is that it is again time-consuming to have a public issue tracker, with end-users that are not always aware of issue tracking best practices. It saves me a lot of time that the issues in our tracker are confirmed, identified, os-specified and with a reproduction scenario before I even read it. Thus, we work closely with swiss teachers, who compose a big part of the team, and have to prioritize their needs as a very big part of Geneva's schools use it daily.

May I suggest merging internal workflow tools / bug tracking with the
tools on Github? Merging can either mean: move everything to Github or
mark Github as a mirrored repository and provide access to your
internal Vcs and bug tracking tools. (I could help with that).

For the reasons described above, we prefer maintain both tools, each with their own goals. We are doing our best to obtain some time to manage/share more with the community (as you can see since the start of the year :) )

Also, you could ask other developers (who deploy or use OpenBoard) to
work on specific issues and thus outsource some of the workload to
community members

Same reason. It is impossible for us at the moment to add something else in the pipeline (where we'll have to validate the code, test on each platform, etc). It is a extremely long term process, but we also work at finding more fundings for this to become possible.

Furthermore, may I suggest making your work more visible and
transparent, so that people see and know, what you are working on and
that you are actually working on stuff at all (and when).

You can already check it out in the wiki section :) => https://github.com/OpenBoard-org/OpenBoard/wiki/Roadmap

it is updated on each release.

If more input is wanted, please let me know. Also feel free to get in
touch with me via mail (sunweaver@debian.org) / phone (you should have
a mail from me with my phone number) / IRC (sunweaver on Freenode).

Thank you, I'll contact you soon. The next day I'm on OpenBoard is in 2 weeks, so just be patient :)

We should stop this here so your topic keeps being only related to Debian packaging ^^

@helge42
Copy link

helge42 commented Mar 20, 2019

@sunweaver I have an issue with the your deb-version in connection with gnome (stretch 1.5.1). Is it possible that you make a package for version 1.5.2 ? So I can decide if the issue come from the packaging or the version of openboard.

Thank for your work on making the packaging for Debian available,
Helge

@jbruechert
Copy link
Contributor

GNOME is known to cause issues with drawing on the desktop. Is this the issue you are facing?

@helge42
Copy link

helge42 commented Mar 20, 2019

Yes. The drawings on the desktop become only visible if I click on the keyboard-icon of openboard.
Ah, I have found your comment on #192.

On the roadmap (https://github.com/OpenBoard-org/OpenBoard/wiki/Roadmap) is mentioned that 1.5.3 will work on ubuntu 18.04. Since ubuntu use gnome I hope there will be a solution. But I will write an issue.

@kaamui kaamui unpinned this issue May 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
building / packaging
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@sunweaver @mariodebian @claurita @kaamui @jbruechert @helge42