Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#887394: ITP: veyon -- Computer Monitoring and Classroom Management Software
123 views
Skip to first unread message
Mike Gabriel
Jan 15, 2018, 3:40:03 PM1/15/18
to
Package: wnpp
Severity: wishlist
Owner: Mike Gabriel <mike.g...@das-netzwerkteam.de>
* Package name : veyon
Version : 4.0.3
Upstream Author : Tobias Doerffel <tobias....@gmail.com>
* URL : https://github.com/veyon/veyon
* License : GPL-2+
Programming Lang: C++
Description : Computer Monitoring and Classroom Management Software
Veyon is a free and Open Source software for computer monitoring and
classroom management supporting Windows and Linux. It enables teachers
to view and control computer labs and interact with students. Veyon is
available in different languages and provides lots of useful features:
- see what's going on in computer labs in overview mode and take screenshots
- remote control computers to support and help users
- broadcast teacher's screen to students in realtime by using demo mode (either
in fullscreen or in a window)
- lock workstations for attracting attention to teacher
- send text messages to students
- powering on/off and rebooting computers remote
- remote logoff and remote execution of arbitrary commands/scripts
- home schooling - Veyon's network technology is not restricted to a subnet
and therefore students at home can join lessons via VPN connections just
by installing the Veyon service
.
Veyon is Tobias Doerffel's continuation of iTALC. The iTALC author asked
me to replace italc by Veyon in Debian, which I plan to do.
.
Saying this, iTALC has become unmaintained upstream due to this switch
and name change.
Severity: wishlist
Owner: Mike Gabriel <mike.g...@das-netzwerkteam.de>
* Package name : veyon
Version : 4.0.3
Upstream Author : Tobias Doerffel <tobias....@gmail.com>
* URL : https://github.com/veyon/veyon
* License : GPL-2+
Programming Lang: C++
Description : Computer Monitoring and Classroom Management Software
Veyon is a free and Open Source software for computer monitoring and
classroom management supporting Windows and Linux. It enables teachers
to view and control computer labs and interact with students. Veyon is
available in different languages and provides lots of useful features:
- see what's going on in computer labs in overview mode and take screenshots
- remote control computers to support and help users
- broadcast teacher's screen to students in realtime by using demo mode (either
in fullscreen or in a window)
- lock workstations for attracting attention to teacher
- send text messages to students
- powering on/off and rebooting computers remote
- remote logoff and remote execution of arbitrary commands/scripts
- home schooling - Veyon's network technology is not restricted to a subnet
and therefore students at home can join lessons via VPN connections just
by installing the Veyon service
.
Veyon is Tobias Doerffel's continuation of iTALC. The iTALC author asked
me to replace italc by Veyon in Debian, which I plan to do.
.
Saying this, iTALC has become unmaintained upstream due to this switch
and name change.
Mike Gabriel
Jan 18, 2018, 6:50:03 AM1/18/18
to
Hi Tobias,
(Cc:ing the ITP bug veyon: https://bugs.debian.org/887394)
On Fr 01 Dez 2017 09:05:46 CET, Tobias Doerffel wrote:
> Hi Mike,
>
> can you have a look at Veyon (veyon.io), the official successor of
> iTALC? It would be nice to have it packaged in Debian (even if we
> provide binaries for download) to replace the legacy iTALC.
>
> All requirements are listed in
> https://github.com/veyon/veyon/blob/master/.travis/linux.debian.stretch/Dockerfile
> while build instructions can be found in
> https://github.com/veyon/veyon/blob/master/.travis/common/linux-build.sh
Thanks, the build script is quite informative. However, for official
Debian packaging it cannot be used.
My main issue with the packaging is the 3rdparty/ folder. I know that
iTALC had embedded code, too, and that you maintain it thoroughly.
What's the status of that with Veyon.
Is there any chance to use Debian unstable's versions of those
3rdparty libs? If not, I am concerned, that we will have problems
getting Veyon into Debian as is.
Also, what of those dependencies are tightly compiled into Veyon?
1. I guess ultravnc is for the Windows build, only, is it?
2. Can kldap be used from Debian?
3. Can libvncserver be used from Debian?
4. Can x11vnc be used from Debian (my sense here is not)?
Please get back to me on this once you find time, packaging needs to
wait before these questions are discussed and clarified.
Mike
--
mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: sunw...@debian.org, http://sunweavers.net
(Cc:ing the ITP bug veyon: https://bugs.debian.org/887394)
On Fr 01 Dez 2017 09:05:46 CET, Tobias Doerffel wrote:
> Hi Mike,
>
> can you have a look at Veyon (veyon.io), the official successor of
> iTALC? It would be nice to have it packaged in Debian (even if we
> provide binaries for download) to replace the legacy iTALC.
>
> All requirements are listed in
> https://github.com/veyon/veyon/blob/master/.travis/linux.debian.stretch/Dockerfile
> while build instructions can be found in
> https://github.com/veyon/veyon/blob/master/.travis/common/linux-build.sh
Thanks, the build script is quite informative. However, for official
Debian packaging it cannot be used.
My main issue with the packaging is the 3rdparty/ folder. I know that
iTALC had embedded code, too, and that you maintain it thoroughly.
What's the status of that with Veyon.
Is there any chance to use Debian unstable's versions of those
3rdparty libs? If not, I am concerned, that we will have problems
getting Veyon into Debian as is.
Also, what of those dependencies are tightly compiled into Veyon?
1. I guess ultravnc is for the Windows build, only, is it?
2. Can kldap be used from Debian?
3. Can libvncserver be used from Debian?
4. Can x11vnc be used from Debian (my sense here is not)?
Please get back to me on this once you find time, packaging needs to
wait before these questions are discussed and clarified.
Mike
--
mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: sunw...@debian.org, http://sunweavers.net
Tobias Doerffel
Jan 18, 2018, 7:30:03 AM1/18/18
to
Hi Mike,
2018-01-18 12:38 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
> My main issue with the packaging is the 3rdparty/ folder. I know that iTALC
> had embedded code, too, and that you maintain it thoroughly. What's the
> status of that with Veyon.
The same here.
> Is there any chance to use Debian unstable's versions of those 3rdparty
> libs?
Partially, see below.
> Also, what of those dependencies are tightly compiled into Veyon?
>
> 1. I guess ultravnc is for the Windows build, only, is it?
Yes, it's not used for Linux builds.
> 2. Can kldap be used from Debian?
Theoretically this would work however this would introduce a strong
dependency on KDE while Veyon uses only a small part of the kldap
library without any dependencies on KDE at all. Veyon's LDAP support
plugin uses some (Qt-based) core classes of kldap but none of it's
KDE-specific model and widget classes. For all non-KDE users this
would unnecessarily install many KDE libraries and make them think
Veyon is a KDE program (which it isn't).
> 3. Can libvncserver be used from Debian?
Inside libvncserver there are two libraries: libvncclient and
libvncserver. We have to use a customized version of libvncclient in
order to implement our own authentication schema. This means the
libraries from the libvncclient1 package are not compatible with Veyon
and the 3rdparty version has to be used. The libvncserver1 package is
only required by x11vnc so this all depends on how we deal with
x11vnc:
> 4. Can x11vnc be used from Debian (my sense here is not)?
In Veyon we use a builtin version of x11vnc, i.e. call the main entry
point directly where needed. With iTALC we also extended x11vnc with
our protocol extensions. With Veyon the Veyon server acts as a VNC
proxy, filters out and handles Veyon-specific traffic and thus can use
an unmodified VNC server as a backend. This means I could provide a
patch which optionally builds the VNC server plugin without x11vnc
builtin but calls an external x11vnc process.
Best regards
Tobias
2018-01-18 12:38 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
> My main issue with the packaging is the 3rdparty/ folder. I know that iTALC
> had embedded code, too, and that you maintain it thoroughly. What's the
> status of that with Veyon.
> Is there any chance to use Debian unstable's versions of those 3rdparty
> libs?
> Also, what of those dependencies are tightly compiled into Veyon?
>
> 1. I guess ultravnc is for the Windows build, only, is it?
> 2. Can kldap be used from Debian?
dependency on KDE while Veyon uses only a small part of the kldap
library without any dependencies on KDE at all. Veyon's LDAP support
plugin uses some (Qt-based) core classes of kldap but none of it's
KDE-specific model and widget classes. For all non-KDE users this
would unnecessarily install many KDE libraries and make them think
Veyon is a KDE program (which it isn't).
> 3. Can libvncserver be used from Debian?
libvncserver. We have to use a customized version of libvncclient in
order to implement our own authentication schema. This means the
libraries from the libvncclient1 package are not compatible with Veyon
and the 3rdparty version has to be used. The libvncserver1 package is
only required by x11vnc so this all depends on how we deal with
x11vnc:
> 4. Can x11vnc be used from Debian (my sense here is not)?
point directly where needed. With iTALC we also extended x11vnc with
our protocol extensions. With Veyon the Veyon server acts as a VNC
proxy, filters out and handles Veyon-specific traffic and thus can use
an unmodified VNC server as a backend. This means I could provide a
patch which optionally builds the VNC server plugin without x11vnc
builtin but calls an external x11vnc process.
Best regards
Tobias
Mike Gabriel
Jan 18, 2018, 7:50:02 AM1/18/18
to
Hi Tobias,
thanks for the prompt reply.
On Do 18 Jan 2018 13:21:06 CET, Tobias Doerffel wrote:
> Hi Mike,
>
>
> 2018-01-18 12:38 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
>> My main issue with the packaging is the 3rdparty/ folder. I know that iTALC
>> had embedded code, too, and that you maintain it thoroughly. What's the
>> status of that with Veyon.
>
> The same here.
>
>
>> Is there any chance to use Debian unstable's versions of those 3rdparty
>> libs?
>
> Partially, see below.
>
>
>> Also, what of those dependencies are tightly compiled into Veyon?
>>
>> 1. I guess ultravnc is for the Windows build, only, is it?
>
> Yes, it's not used for Linux builds.
Ack.
>> 2. Can kldap be used from Debian?
>
> Theoretically this would work however this would introduce a strong
> dependency on KDE while Veyon uses only a small part of the kldap
> library without any dependencies on KDE at all. Veyon's LDAP support
> plugin uses some (Qt-based) core classes of kldap but none of it's
> KDE-specific model and widget classes. For all non-KDE users this
> would unnecessarily install many KDE libraries and make them think
> Veyon is a KDE program (which it isn't).
Let me check the deps tree myself here. I'll get back to you on this.
>> 3. Can libvncserver be used from Debian?
>
> Inside libvncserver there are two libraries: libvncclient and
> libvncserver. We have to use a customized version of libvncclient in
> order to implement our own authentication schema. This means the
> libraries from the libvncclient1 package are not compatible with Veyon
> and the 3rdparty version has to be used. The libvncserver1 package is
> only required by x11vnc so this all depends on how we deal with
> x11vnc:
Then we should keep libvncclient, but ignore libvncserver on Debian.
>> 4. Can x11vnc be used from Debian (my sense here is not)?
>
> In Veyon we use a builtin version of x11vnc, i.e. call the main entry
> point directly where needed. With iTALC we also extended x11vnc with
> our protocol extensions. With Veyon the Veyon server acts as a VNC
> proxy, filters out and handles Veyon-specific traffic and thus can use
> an unmodified VNC server as a backend. This means I could provide a
> patch which optionally builds the VNC server plugin without x11vnc
> builtin but calls an external x11vnc process.
Please do.
Thanks once more!
thanks for the prompt reply.
On Do 18 Jan 2018 13:21:06 CET, Tobias Doerffel wrote:
> Hi Mike,
>
>
> 2018-01-18 12:38 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
>> My main issue with the packaging is the 3rdparty/ folder. I know that iTALC
>> had embedded code, too, and that you maintain it thoroughly. What's the
>> status of that with Veyon.
>
> The same here.
>
>
>> Is there any chance to use Debian unstable's versions of those 3rdparty
>> libs?
>
> Partially, see below.
>
>
>> Also, what of those dependencies are tightly compiled into Veyon?
>>
>> 1. I guess ultravnc is for the Windows build, only, is it?
>
> Yes, it's not used for Linux builds.
>> 2. Can kldap be used from Debian?
>
> Theoretically this would work however this would introduce a strong
> dependency on KDE while Veyon uses only a small part of the kldap
> library without any dependencies on KDE at all. Veyon's LDAP support
> plugin uses some (Qt-based) core classes of kldap but none of it's
> KDE-specific model and widget classes. For all non-KDE users this
> would unnecessarily install many KDE libraries and make them think
> Veyon is a KDE program (which it isn't).
>> 3. Can libvncserver be used from Debian?
>
> Inside libvncserver there are two libraries: libvncclient and
> libvncserver. We have to use a customized version of libvncclient in
> order to implement our own authentication schema. This means the
> libraries from the libvncclient1 package are not compatible with Veyon
> and the 3rdparty version has to be used. The libvncserver1 package is
> only required by x11vnc so this all depends on how we deal with
> x11vnc:
>> 4. Can x11vnc be used from Debian (my sense here is not)?
>
> In Veyon we use a builtin version of x11vnc, i.e. call the main entry
> point directly where needed. With iTALC we also extended x11vnc with
> our protocol extensions. With Veyon the Veyon server acts as a VNC
> proxy, filters out and handles Veyon-specific traffic and thus can use
> an unmodified VNC server as a backend. This means I could provide a
> patch which optionally builds the VNC server plugin without x11vnc
> builtin but calls an external x11vnc process.
Thanks once more!
Tobias Doerffel
Jan 25, 2018, 3:40:03 AM1/25/18
to
Hi Mike,
FYI: Veyon 4.0.4 is available at
https://github.com/veyon/veyon/releases/tag/v4.0.4
I integrated the possibility to build without x11vnc builtin but
instead use an external x11vnc binary (do not get confused that the
plugin is still called "builtin-x11vnc.so" but it should be notably
smaller). Simply pass -DVEYON_X11VNC_EXTERNAL=ON to cmake. No need for
applying a patch.
2018-01-18 13:42 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
>>> 2. Can kldap be used from Debian?
>>
>>
>> Theoretically this would work however this would introduce a strong
>> dependency on KDE while Veyon uses only a small part of the kldap
>> library without any dependencies on KDE at all. Veyon's LDAP support
>> plugin uses some (Qt-based) core classes of kldap but none of it's
>> KDE-specific model and widget classes. For all non-KDE users this
>> would unnecessarily install many KDE libraries and make them think
>> Veyon is a KDE program (which it isn't).
>
>
> Let me check the deps tree myself here. I'll get back to you on this.
Any news? I still encourage you to keep things as they are as
everything else will make things unnecessarily complicated for
everyone without any notable benefit for the end user (except saving a
few KB disk space in case KDE is installed vs. many MB disk space
additionally in every other case).
Best regards
Tobias
FYI: Veyon 4.0.4 is available at
https://github.com/veyon/veyon/releases/tag/v4.0.4
I integrated the possibility to build without x11vnc builtin but
instead use an external x11vnc binary (do not get confused that the
plugin is still called "builtin-x11vnc.so" but it should be notably
smaller). Simply pass -DVEYON_X11VNC_EXTERNAL=ON to cmake. No need for
applying a patch.
2018-01-18 13:42 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
>>> 2. Can kldap be used from Debian?
>>
>>
>> Theoretically this would work however this would introduce a strong
>> dependency on KDE while Veyon uses only a small part of the kldap
>> library without any dependencies on KDE at all. Veyon's LDAP support
>> plugin uses some (Qt-based) core classes of kldap but none of it's
>> KDE-specific model and widget classes. For all non-KDE users this
>> would unnecessarily install many KDE libraries and make them think
>> Veyon is a KDE program (which it isn't).
>
>
> Let me check the deps tree myself here. I'll get back to you on this.
everything else will make things unnecessarily complicated for
everyone without any notable benefit for the end user (except saving a
few KB disk space in case KDE is installed vs. many MB disk space
additionally in every other case).
Best regards
Tobias
Mike Gabriel
Feb 5, 2018, 12:00:03 PM2/5/18
to
Hi Tobias,
I need some more feedback on the distribution of files over the
various packages:
Package: veyon-master
Package: veyon-service
Package: veyon-configurator
Package: libveyon-core
And in debian/tmp I see these files directly after the build:
./usr/lib/x86_64-linux-gnu/veyon/powercontrol.so
./usr/lib/x86_64-linux-gnu/veyon/servicecontrol.so
./usr/lib/x86_64-linux-gnu/veyon/desktopservices.so
./usr/lib/x86_64-linux-gnu/veyon/localdata.so
./usr/lib/x86_64-linux-gnu/veyon/demo.so
./usr/lib/x86_64-linux-gnu/veyon/ldap.so
./usr/lib/x86_64-linux-gnu/veyon/linux-platform.so
./usr/lib/x86_64-linux-gnu/veyon/builtin-x11vnc-server.so
./usr/lib/x86_64-linux-gnu/veyon/textmessage.so
./usr/lib/x86_64-linux-gnu/veyon/screenlock.so
./usr/lib/x86_64-linux-gnu/veyon/config.so
./usr/lib/x86_64-linux-gnu/veyon/remoteaccess.so
./usr/lib/x86_64-linux-gnu/veyon/screenshot.so
./usr/share/icons/hicolor/scalable/apps/veyon-configurator.svg
./usr/share/icons/hicolor/scalable/apps/veyon-master.svg
./usr/share/icons/hicolor/48x48/apps/veyon-configurator.png
./usr/share/icons/hicolor/48x48/apps/veyon-master.png
./usr/share/pixmaps/veyon-configurator.xpm
./usr/share/pixmaps/veyon-master.xpm
./usr/share/polkit-1/actions/io.veyon.veyon-configurator.policy
./usr/share/applications/veyon-configurator.desktop
./usr/share/applications/veyon-master.desktop
./usr/bin/veyon-master
./usr/bin/veyon-ctl
./usr/bin/veyon-auth-helper
./usr/bin/veyon-configurator
./usr/bin/veyon-service
./usr/bin/veyon-worker
How shall I distribute these files over the above named packages? And:
do I need another package (e.g. veyon-ctl or veyon-worker? Or a
plugins package?).
Does it make sense to package plugins separately so that the site
admin can add/remove features?
various packages:
Package: veyon-master
Package: veyon-service
Package: veyon-configurator
Package: libveyon-core
And in debian/tmp I see these files directly after the build:
./usr/lib/x86_64-linux-gnu/veyon/powercontrol.so
./usr/lib/x86_64-linux-gnu/veyon/servicecontrol.so
./usr/lib/x86_64-linux-gnu/veyon/desktopservices.so
./usr/lib/x86_64-linux-gnu/veyon/localdata.so
./usr/lib/x86_64-linux-gnu/veyon/demo.so
./usr/lib/x86_64-linux-gnu/veyon/ldap.so
./usr/lib/x86_64-linux-gnu/veyon/linux-platform.so
./usr/lib/x86_64-linux-gnu/veyon/builtin-x11vnc-server.so
./usr/lib/x86_64-linux-gnu/veyon/textmessage.so
./usr/lib/x86_64-linux-gnu/veyon/screenlock.so
./usr/lib/x86_64-linux-gnu/veyon/config.so
./usr/lib/x86_64-linux-gnu/veyon/remoteaccess.so
./usr/lib/x86_64-linux-gnu/veyon/screenshot.so
./usr/share/icons/hicolor/scalable/apps/veyon-configurator.svg
./usr/share/icons/hicolor/scalable/apps/veyon-master.svg
./usr/share/icons/hicolor/48x48/apps/veyon-configurator.png
./usr/share/icons/hicolor/48x48/apps/veyon-master.png
./usr/share/pixmaps/veyon-configurator.xpm
./usr/share/pixmaps/veyon-master.xpm
./usr/share/polkit-1/actions/io.veyon.veyon-configurator.policy
./usr/share/applications/veyon-configurator.desktop
./usr/share/applications/veyon-master.desktop
./usr/bin/veyon-master
./usr/bin/veyon-ctl
./usr/bin/veyon-auth-helper
./usr/bin/veyon-configurator
./usr/bin/veyon-service
./usr/bin/veyon-worker
How shall I distribute these files over the above named packages? And:
do I need another package (e.g. veyon-ctl or veyon-worker? Or a
plugins package?).
Does it make sense to package plugins separately so that the site
admin can add/remove features?
Tobias Doerffel
Feb 6, 2018, 7:00:02 AM2/6/18
to
Hi Mike,
2018-02-05 17:50 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
> I need some more feedback on the distribution of files over the various
> packages:
>
> Package: veyon-master
> Package: veyon-service
> Package: veyon-configurator
> Package: libveyon-core
You should add "veyon-ctl" with the CLI tool built in and make it a
recommended package.
> ./usr/lib/x86_64-linux-gnu/veyon/powercontrol.so
> ./usr/lib/x86_64-linux-gnu/veyon/servicecontrol.so
> ./usr/lib/x86_64-linux-gnu/veyon/desktopservices.so
> ./usr/lib/x86_64-linux-gnu/veyon/localdata.so
> ./usr/lib/x86_64-linux-gnu/veyon/demo.so
> ./usr/lib/x86_64-linux-gnu/veyon/ldap.so
> ./usr/lib/x86_64-linux-gnu/veyon/linux-platform.so
> ./usr/lib/x86_64-linux-gnu/veyon/builtin-x11vnc-server.so
> ./usr/lib/x86_64-linux-gnu/veyon/textmessage.so
> ./usr/lib/x86_64-linux-gnu/veyon/screenlock.so
> ./usr/lib/x86_64-linux-gnu/veyon/config.so
> ./usr/lib/x86_64-linux-gnu/veyon/remoteaccess.so
> ./usr/lib/x86_64-linux-gnu/veyon/screenshot.so
These belong to "veyon-plugins". Splitting them into individual
packages doesn't make sense ATM. They should be available to make
Veyon function properly and are mainly realized as plugins for
architectural reasons. Users can still disable non-required features
through Configurator.
> ./usr/share/icons/hicolor/scalable/apps/veyon-configurator.svg
> ./usr/share/icons/hicolor/scalable/apps/veyon-master.svg
> ./usr/share/icons/hicolor/48x48/apps/veyon-configurator.png
> ./usr/share/icons/hicolor/48x48/apps/veyon-master.png
> ./usr/share/pixmaps/veyon-configurator.xpm
> ./usr/share/pixmaps/veyon-master.xpm
> ./usr/share/polkit-1/actions/io.veyon.veyon-configurator.policy
> ./usr/share/applications/veyon-configurator.desktop
> ./usr/share/applications/veyon-master.desktop
These belong to "veyon-master" and "veyon-configurator."
> ./usr/bin/veyon-auth-helper
This binary is required by veyon-service to handle authentication
requests so it should be packaged inside veyon-service.
> ./usr/bin/veyon-worker
This binary is used by veyon-service to start features e.g. in user sessions.
An alternative approach would be to provide a package called
"veyon-core" which contains plugins, veyon-ctl, veyon-worker and
veyon-auth-helper.
Don't hesitate to ask further questions.
Best regards
Tobias
2018-02-05 17:50 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
> I need some more feedback on the distribution of files over the various
> packages:
>
> Package: veyon-master
> Package: veyon-service
> Package: veyon-configurator
> Package: libveyon-core
recommended package.
> ./usr/lib/x86_64-linux-gnu/veyon/powercontrol.so
> ./usr/lib/x86_64-linux-gnu/veyon/servicecontrol.so
> ./usr/lib/x86_64-linux-gnu/veyon/desktopservices.so
> ./usr/lib/x86_64-linux-gnu/veyon/localdata.so
> ./usr/lib/x86_64-linux-gnu/veyon/demo.so
> ./usr/lib/x86_64-linux-gnu/veyon/ldap.so
> ./usr/lib/x86_64-linux-gnu/veyon/linux-platform.so
> ./usr/lib/x86_64-linux-gnu/veyon/builtin-x11vnc-server.so
> ./usr/lib/x86_64-linux-gnu/veyon/textmessage.so
> ./usr/lib/x86_64-linux-gnu/veyon/screenlock.so
> ./usr/lib/x86_64-linux-gnu/veyon/config.so
> ./usr/lib/x86_64-linux-gnu/veyon/remoteaccess.so
> ./usr/lib/x86_64-linux-gnu/veyon/screenshot.so
packages doesn't make sense ATM. They should be available to make
Veyon function properly and are mainly realized as plugins for
architectural reasons. Users can still disable non-required features
through Configurator.
> ./usr/share/icons/hicolor/scalable/apps/veyon-configurator.svg
> ./usr/share/icons/hicolor/scalable/apps/veyon-master.svg
> ./usr/share/icons/hicolor/48x48/apps/veyon-configurator.png
> ./usr/share/icons/hicolor/48x48/apps/veyon-master.png
> ./usr/share/pixmaps/veyon-configurator.xpm
> ./usr/share/pixmaps/veyon-master.xpm
> ./usr/share/polkit-1/actions/io.veyon.veyon-configurator.policy
> ./usr/share/applications/veyon-configurator.desktop
> ./usr/share/applications/veyon-master.desktop
> ./usr/bin/veyon-auth-helper
This binary is required by veyon-service to handle authentication
requests so it should be packaged inside veyon-service.
> ./usr/bin/veyon-worker
This binary is used by veyon-service to start features e.g. in user sessions.
An alternative approach would be to provide a package called
"veyon-core" which contains plugins, veyon-ctl, veyon-worker and
veyon-auth-helper.
Don't hesitate to ask further questions.
Best regards
Tobias
mike.g...@das-netzwerkteam.de
Feb 6, 2018, 8:30:03 AM2/6/18
to
Hi Tobias,
a quick top posted mail... Can you also describe the dependency tree?
Master needs service and libveyon-core.
Configurator? Would it work standalone?
Master should probably recommend configurator.
Service needs Auth-Helper and Worker (they should be in the same package... IMHO).
veyon-ctl is useful for whom? For the PC running the Master application? Or is it more useful on the PCs running the Service?
And the Plugins? Needed on Master or on client systems running the Service?
Thanks, Mike
On Tuesday, February 6, 2018, Tobias Doerffel wrote:
> Hi Mike,
>
>
> 2018-02-05 17:50 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
> > I need some more feedback on the distribution of files over the various
> > packages:
> >
> > Package: veyon-master
> > Package: veyon-service
> > Package: veyon-configurator
> > Package: libveyon-core
>
Sent from my Fairphone 2 (running Sailfish OS)
a quick top posted mail... Can you also describe the dependency tree?
Master needs service and libveyon-core.
Configurator? Would it work standalone?
Master should probably recommend configurator.
Service needs Auth-Helper and Worker (they should be in the same package... IMHO).
veyon-ctl is useful for whom? For the PC running the Master application? Or is it more useful on the PCs running the Service?
And the Plugins? Needed on Master or on client systems running the Service?
Thanks, Mike
On Tuesday, February 6, 2018, Tobias Doerffel wrote:
> Hi Mike,
>
>
> 2018-02-05 17:50 GMT+01:00 Mike Gabriel <sunw...@debian.org>:
> > I need some more feedback on the distribution of files over the various
> > packages:
> >
> > Package: veyon-master
> > Package: veyon-service
> > Package: veyon-configurator
> > Package: libveyon-core
>
> You should add "veyon-ctl" with the CLI tool built in and make it a
> recommended package.
>
> recommended package.
>
> > ./usr/lib/x86_64-linux-gnu/veyon/powercontrol.so
> > ./usr/lib/x86_64-linux-gnu/veyon/servicecontrol.so
> > ./usr/lib/x86_64-linux-gnu/veyon/desktopservices.so
> > ./usr/lib/x86_64-linux-gnu/veyon/localdata.so
> > ./usr/lib/x86_64-linux-gnu/veyon/demo.so
> > ./usr/lib/x86_64-linux-gnu/veyon/ldap.so
> > ./usr/lib/x86_64-linux-gnu/veyon/linux-platform.so
> > ./usr/lib/x86_64-linux-gnu/veyon/builtin-x11vnc-server.so
> > ./usr/lib/x86_64-linux-gnu/veyon/textmessage.so
> > ./usr/lib/x86_64-linux-gnu/veyon/screenlock.so
> > ./usr/lib/x86_64-linux-gnu/veyon/config.so
> > ./usr/lib/x86_64-linux-gnu/veyon/remoteaccess.so
> > ./usr/lib/x86_64-linux-gnu/veyon/screenshot.so
>
> > ./usr/lib/x86_64-linux-gnu/veyon/servicecontrol.so
> > ./usr/lib/x86_64-linux-gnu/veyon/desktopservices.so
> > ./usr/lib/x86_64-linux-gnu/veyon/localdata.so
> > ./usr/lib/x86_64-linux-gnu/veyon/demo.so
> > ./usr/lib/x86_64-linux-gnu/veyon/ldap.so
> > ./usr/lib/x86_64-linux-gnu/veyon/linux-platform.so
> > ./usr/lib/x86_64-linux-gnu/veyon/builtin-x11vnc-server.so
> > ./usr/lib/x86_64-linux-gnu/veyon/textmessage.so
> > ./usr/lib/x86_64-linux-gnu/veyon/screenlock.so
> > ./usr/lib/x86_64-linux-gnu/veyon/config.so
> > ./usr/lib/x86_64-linux-gnu/veyon/remoteaccess.so
> > ./usr/lib/x86_64-linux-gnu/veyon/screenshot.so
>
> These belong to "veyon-plugins". Splitting them into individual
> packages doesn't make sense ATM. They should be available to make
> Veyon function properly and are mainly realized as plugins for
> architectural reasons. Users can still disable non-required features
> through Configurator.
>
> packages doesn't make sense ATM. They should be available to make
> Veyon function properly and are mainly realized as plugins for
> architectural reasons. Users can still disable non-required features
> through Configurator.
>
> > ./usr/share/icons/hicolor/scalable/apps/veyon-configurator.svg
> > ./usr/share/icons/hicolor/scalable/apps/veyon-master.svg
> > ./usr/share/icons/hicolor/48x48/apps/veyon-configurator.png
> > ./usr/share/icons/hicolor/48x48/apps/veyon-master.png
> > ./usr/share/pixmaps/veyon-configurator.xpm
> > ./usr/share/pixmaps/veyon-master.xpm
> > ./usr/share/polkit-1/actions/io.veyon.veyon-configurator.policy
> > ./usr/share/applications/veyon-configurator.desktop
> > ./usr/share/applications/veyon-master.desktop
>
> > ./usr/share/icons/hicolor/scalable/apps/veyon-master.svg
> > ./usr/share/icons/hicolor/48x48/apps/veyon-configurator.png
> > ./usr/share/icons/hicolor/48x48/apps/veyon-master.png
> > ./usr/share/pixmaps/veyon-configurator.xpm
> > ./usr/share/pixmaps/veyon-master.xpm
> > ./usr/share/polkit-1/actions/io.veyon.veyon-configurator.policy
> > ./usr/share/applications/veyon-configurator.desktop
> > ./usr/share/applications/veyon-master.desktop
>
> These belong to "veyon-master" and "veyon-configurator."
>
> > ./usr/bin/veyon-auth-helper
>
> This binary is required by veyon-service to handle authentication
> requests so it should be packaged inside veyon-service.
>
> > ./usr/bin/veyon-worker
>
> This binary is used by veyon-service to start features e.g. in user sessions.
>
> An alternative approach would be to provide a package called
> "veyon-core" which contains plugins, veyon-ctl, veyon-worker and
> veyon-auth-helper.
>
> Don't hesitate to ask further questions.
>
> Best regards
>
> Tobias
>
--
>
> > ./usr/bin/veyon-auth-helper
>
> This binary is required by veyon-service to handle authentication
> requests so it should be packaged inside veyon-service.
>
> > ./usr/bin/veyon-worker
>
> This binary is used by veyon-service to start features e.g. in user sessions.
>
> An alternative approach would be to provide a package called
> "veyon-core" which contains plugins, veyon-ctl, veyon-worker and
> veyon-auth-helper.
>
> Don't hesitate to ask further questions.
>
> Best regards
>
> Tobias
>
Sent from my Fairphone 2 (running Sailfish OS)
Tobias Doerffel
Feb 6, 2018, 9:00:03 AM2/6/18
to
Hi Mike,
2018-02-06 14:21 GMT+01:00 <mike.g...@das-netzwerkteam.de>:
> Master needs service and libveyon-core.
Yes, all components require libveyon-core and veyon-plugins.
> Configurator? Would it work standalone?
Yes, it's a configuration tool/frontend for Veyon installations but
not required for running master or service.
> Master should probably recommend configurator.
Right.
> Service needs Auth-Helper and Worker (they should be in the same package... IMHO).
Correct.
> veyon-ctl is useful for whom? For the PC running the Master application? Or is it more useful on the PCs running the Service?
It's the same as Configurator, it's a non-graphical frontend for
performing various (mostly administrative) Veyon installation related
tasks.
> And the Plugins? Needed on Master or on client systems running the Service?
They're required by all components since they also contain the
platform abstraction plugin which is a basic requirement of Veyon
Core.
Best regards
Tobias
2018-02-06 14:21 GMT+01:00 <mike.g...@das-netzwerkteam.de>:
> Master needs service and libveyon-core.
> Configurator? Would it work standalone?
not required for running master or service.
> Master should probably recommend configurator.
> Service needs Auth-Helper and Worker (they should be in the same package... IMHO).
> veyon-ctl is useful for whom? For the PC running the Master application? Or is it more useful on the PCs running the Service?
performing various (mostly administrative) Veyon installation related
tasks.
> And the Plugins? Needed on Master or on client systems running the Service?
platform abstraction plugin which is a basic requirement of Veyon
Core.
Best regards
Tobias
Tobias Junghans
Aug 9, 2018, 7:30:03 AM8/9/18
to
Hi Mike,
any news on packaging Veyon for Debian? We released 4.1.1 this week and it's
quite a mature release which deserves being packaged for Debian before feature
freeze.
Best regards
Tobias
Am Dienstag, 6. Februar 2018, 14:21:16 CEST schrieben Sie:
any news on packaging Veyon for Debian? We released 4.1.1 this week and it's
quite a mature release which deserves being packaged for Debian before feature
freeze.
Best regards
Tobias
Am Dienstag, 6. Februar 2018, 14:21:16 CEST schrieben Sie:
Mike Gabriel
Aug 10, 2018, 12:20:02 PM8/10/18
to
Hi Tobias,
On Thursday, August 9, 2018, Tobias Junghans wrote:
> Hi Mike,
>
> any news on packaging Veyon for Debian? We released 4.1.1 this week and it's
> quite a mature release which deserves being packaged for Debian before feature
> freeze.
>
> Best regards
>
> Tobias
It is still on my list for being uploaded to Debian before the freeze.
Sorry for the delay on my side... (paying customers come first...).
Mike
> Am Dienstag, 6. Februar 2018, 14:21:16 CEST schrieben Sie:
> > Hi Tobias,
> >
> > a quick top posted mail... Can you also describe the dependency tree?
> >
> > Master needs service and libveyon-core.
> > Configurator? Would it work standalone?
> > Master should probably recommend configurator.
> >
> > Service needs Auth-Helper and Worker (they should be in the same package...
> > IMHO).
>
> > veyon-ctl is useful for whom? For the PC running the Master application? Or
> > is it more useful on the PCs running the Service?
>
> > And the Plugins? Needed on Master or on client systems running the Service?
> >
> > Thanks, Mike
>
>
>
>
--
Sent from my Fairphone (powered by SailfishOS)
On Thursday, August 9, 2018, Tobias Junghans wrote:
> Hi Mike,
>
> any news on packaging Veyon for Debian? We released 4.1.1 this week and it's
> quite a mature release which deserves being packaged for Debian before feature
> freeze.
>
> Best regards
>
> Tobias
Sorry for the delay on my side... (paying customers come first...).
Mike
> Am Dienstag, 6. Februar 2018, 14:21:16 CEST schrieben Sie:
> > Hi Tobias,
> >
> > a quick top posted mail... Can you also describe the dependency tree?
> >
> > Master needs service and libveyon-core.
> > Configurator? Would it work standalone?
> > Master should probably recommend configurator.
> >
> > Service needs Auth-Helper and Worker (they should be in the same package...
> > IMHO).
>
> > veyon-ctl is useful for whom? For the PC running the Master application? Or
> > is it more useful on the PCs running the Service?
>
> > And the Plugins? Needed on Master or on client systems running the Service?
> >
> > Thanks, Mike
>
>
>
>
Sent from my Fairphone (powered by SailfishOS)
Mike Gabriel
Dec 6, 2018, 8:40:03 AM12/6/18
to
Hi Tobi,
On Do 09 Aug 2018 13:16:50 CEST, Tobias Junghans wrote:
> Hi Mike,
>
> any news on packaging Veyon for Debian? We released 4.1.1 this week and it's
> quite a mature release which deserves being packaged for Debian
> before feature
> freeze.
>
> Best regards
>
> Tobias
>
I worked on packaging Veyon quite a bit over the last couple of days.
I need you to review some patches, that I will add to the Debian package:
https://salsa.debian.org/debian-edu-pkg-team/veyon/tree/master/debian/patches
Esp. the 1004_improve-man-page-content.patch should make its way into
upstream. I'd highly appreciate, if you could do a review on the man
pages' modified content, if possible.
Furthermore, here comes another request: how could we bring the Veyon
documentation files (as source files, as built Sphinx documentation)
into Debian? I'd say it makes sense having those docs packaged, so
they can be made available offline.
Greets,
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
On Do 09 Aug 2018 13:16:50 CEST, Tobias Junghans wrote:
> Hi Mike,
>
> any news on packaging Veyon for Debian? We released 4.1.1 this week and it's
> quite a mature release which deserves being packaged for Debian
> before feature
> freeze.
>
> Best regards
>
> Tobias
>
I need you to review some patches, that I will add to the Debian package:
https://salsa.debian.org/debian-edu-pkg-team/veyon/tree/master/debian/patches
Esp. the 1004_improve-man-page-content.patch should make its way into
upstream. I'd highly appreciate, if you could do a review on the man
pages' modified content, if possible.
Furthermore, here comes another request: how could we bring the Veyon
documentation files (as source files, as built Sphinx documentation)
into Debian? I'd say it makes sense having those docs packaged, so
they can be made available offline.
Greets,
Mike
--
DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: mike.g...@das-netzwerkteam.de, http://das-netzwerkteam.de
landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
Tobias Junghans
Dec 6, 2018, 9:20:03 AM12/6/18
to
Hi Mike,
thank you very much for your efforts! I'll try to adopt as many of the changes
as possible for the 4.1.6 release.
Regarding the package structure: everything looks fine so far. You could put
veyon-ctl in a separate package but probably it's better to postpone this step
until Veyon 4.2 has been released (where we'll rename veyon-ctl to veyon-cli
which would lead to package renames and the first transitional packages).
Do you plan to add transitional packages for existing iTALC installations so
that users get migrated to Veyon automatically?
Regarding libvncserver/libvncclient: I'm actively working with upstream to get
all Veyon-specific changes merged in a generic manner so we can use an
existing libvncclient library from the system. Currently the only thing left
is to disable the broken (non thread-safe) IPv4 support in favor of the new
(existing and generic) IPv6 code in libvncclient. Once libvncserver 0.9.12 is
released and about to be packaged we could even solve this with a small
Debian-specific patch.
> Furthermore, here comes another request: how could we bring the Veyon
> documentation files (as source files, as built Sphinx documentation)
> into Debian? I'd say it makes sense having those docs packaged, so
> they can be made available offline.
As you probably already know the sources for the docs are available at
https://github.com/veyon/docs and can be built via sphinx easily. For future
releases I can create tags for the docs as well so you can simply download a
tarball which can be used as source tarball for a separate veyon-docs package.
Best regards
Tobias
thank you very much for your efforts! I'll try to adopt as many of the changes
as possible for the 4.1.6 release.
Regarding the package structure: everything looks fine so far. You could put
veyon-ctl in a separate package but probably it's better to postpone this step
until Veyon 4.2 has been released (where we'll rename veyon-ctl to veyon-cli
which would lead to package renames and the first transitional packages).
Do you plan to add transitional packages for existing iTALC installations so
that users get migrated to Veyon automatically?
Regarding libvncserver/libvncclient: I'm actively working with upstream to get
all Veyon-specific changes merged in a generic manner so we can use an
existing libvncclient library from the system. Currently the only thing left
is to disable the broken (non thread-safe) IPv4 support in favor of the new
(existing and generic) IPv6 code in libvncclient. Once libvncserver 0.9.12 is
released and about to be packaged we could even solve this with a small
Debian-specific patch.
> Furthermore, here comes another request: how could we bring the Veyon
> documentation files (as source files, as built Sphinx documentation)
> into Debian? I'd say it makes sense having those docs packaged, so
> they can be made available offline.
https://github.com/veyon/docs and can be built via sphinx easily. For future
releases I can create tags for the docs as well so you can simply download a
tarball which can be used as source tarball for a separate veyon-docs package.
Best regards
Tobias
Mike Gabriel
Dec 6, 2018, 10:10:03 AM12/6/18
to
Hi Tobi,
On Do 06 Dez 2018 15:04:32 CET, Tobias Junghans wrote:
> Hi Mike,
>
> thank you very much for your efforts! I'll try to adopt as many of
> the changes
> as possible for the 4.1.6 release.
:-)
> Regarding the package structure: everything looks fine so far. You could put
> veyon-ctl in a separate package but probably it's better to postpone
> this step
> until Veyon 4.2 has been released (where we'll rename veyon-ctl to veyon-cli
> which would lead to package renames and the first transitional packages).
Ok. Sounds like a plan...
> Do you plan to add transitional packages for existing iTALC installations so
> that users get migrated to Veyon automatically?
No. I won't either offer a pre-configuration debconf question journey.
The new ACL model in Veyon is so highly flexible, a default setup can
only be wrong for someone.
> Regarding libvncserver/libvncclient: I'm actively working with
> upstream to get
> all Veyon-specific changes merged in a generic manner so we can use an
> existing libvncclient library from the system. Currently the only thing left
> is to disable the broken (non thread-safe) IPv4 support in favor of the new
> (existing and generic) IPv6 code in libvncclient. Once libvncserver 0.9.12 is
> released and about to be packaged we could even solve this with a small
> Debian-specific patch.
That is awesome news!!!
>> Furthermore, here comes another request: how could we bring the Veyon
>> documentation files (as source files, as built Sphinx documentation)
>> into Debian? I'd say it makes sense having those docs packaged, so
>> they can be made available offline.
>
> As you probably already know the sources for the docs are available at
> https://github.com/veyon/docs and can be built via sphinx easily. For future
> releases I can create tags for the docs as well so you can simply download a
> tarball which can be used as source tarball for a separate
> veyon-docs package.
+1 from here!
Thanks+Greets,
Mike
PS: upload will come soon...
On Do 06 Dez 2018 15:04:32 CET, Tobias Junghans wrote:
> Hi Mike,
>
> thank you very much for your efforts! I'll try to adopt as many of
> the changes
> as possible for the 4.1.6 release.
> Regarding the package structure: everything looks fine so far. You could put
> veyon-ctl in a separate package but probably it's better to postpone
> this step
> until Veyon 4.2 has been released (where we'll rename veyon-ctl to veyon-cli
> which would lead to package renames and the first transitional packages).
> Do you plan to add transitional packages for existing iTALC installations so
> that users get migrated to Veyon automatically?
The new ACL model in Veyon is so highly flexible, a default setup can
only be wrong for someone.
> Regarding libvncserver/libvncclient: I'm actively working with
> upstream to get
> all Veyon-specific changes merged in a generic manner so we can use an
> existing libvncclient library from the system. Currently the only thing left
> is to disable the broken (non thread-safe) IPv4 support in favor of the new
> (existing and generic) IPv6 code in libvncclient. Once libvncserver 0.9.12 is
> released and about to be packaged we could even solve this with a small
> Debian-specific patch.
>> Furthermore, here comes another request: how could we bring the Veyon
>> documentation files (as source files, as built Sphinx documentation)
>> into Debian? I'd say it makes sense having those docs packaged, so
>> they can be made available offline.
>
> As you probably already know the sources for the docs are available at
> https://github.com/veyon/docs and can be built via sphinx easily. For future
> releases I can create tags for the docs as well so you can simply download a
> tarball which can be used as source tarball for a separate
> veyon-docs package.
Thanks+Greets,
Mike
PS: upload will come soon...
Tobias Junghans
Dec 7, 2018, 2:30:03 AM12/7/18
to
Hi Mike,
> Uploaded 20min ago.
Perfect, thanks a lot! A few questions and suggestions for future uploads
though:
* switch project website (https://veyon.io) to https in Homepage field
* use lower-case for github group for Source field
* update to 4.1.5
* replace "iTALC" with "Veyon" in copyright
* why is kde-baseapps-bin recommended? Veyon is not KDE-related at all
* as of upcoming 4.1.6 release you should reconsider to not repack the source
tarball as all unused source files (except for x11vnc/libvncserver) will get
stripped anyway (https://github.com/veyon/veyon/commit/
cc54151fb31524bd67a6160acaac1204f55e9ccd).
Best regards
Tobias
> Uploaded 20min ago.
Perfect, thanks a lot! A few questions and suggestions for future uploads
though:
* switch project website (https://veyon.io) to https in Homepage field
* use lower-case for github group for Source field
* update to 4.1.5
* replace "iTALC" with "Veyon" in copyright
* why is kde-baseapps-bin recommended? Veyon is not KDE-related at all
* as of upcoming 4.1.6 release you should reconsider to not repack the source
tarball as all unused source files (except for x11vnc/libvncserver) will get
stripped anyway (https://github.com/veyon/veyon/commit/
cc54151fb31524bd67a6160acaac1204f55e9ccd).
Best regards
Tobias
Mike Gabriel
Dec 7, 2018, 4:50:03 AM12/7/18
to
Hi Tobi,
On Fr 07 Dez 2018 08:16:35 CET, Tobias Junghans wrote:
> Hi Mike,
>
>> Uploaded 20min ago.
>
> Perfect, thanks a lot! A few questions and suggestions for future uploads
> though:
>
> * switch project website (https://veyon.io) to https in Homepage field
done
> * use lower-case for github group for Source field
done (some other places within debian/ subfolder)
> * update to 4.1.5
I would like to skip 4.1.5. See below.
> * replace "iTALC" with "Veyon" in copyright
found + fixed
> * why is kde-baseapps-bin recommended? Veyon is not KDE-related at all
In Debian, we had a wrapper script around the ica client executable
that did some error handling if users were not in the correct group(s).
As veyon-service is now a systemd system service, the wrapper script
has been dropped. And so should the Recommends: field.
-> done.
> * as of upcoming 4.1.6 release you should reconsider to not repack the source
> tarball as all unused source files (except for x11vnc/libvncserver) will get
> stripped anyway (https://github.com/veyon/veyon/commit/
> cc54151fb31524bd67a6160acaac1204f55e9ccd).
That is great news!!! When is the due date of 4.1.6. Will you make it
for Debian buster's soft freeze (midst of February)?
https://wiki.debian.org/DebianBuster
On Fr 07 Dez 2018 08:16:35 CET, Tobias Junghans wrote:
> Hi Mike,
>
>> Uploaded 20min ago.
>
> Perfect, thanks a lot! A few questions and suggestions for future uploads
> though:
>
> * switch project website (https://veyon.io) to https in Homepage field
> * use lower-case for github group for Source field
> * update to 4.1.5
I would like to skip 4.1.5. See below.
> * replace "iTALC" with "Veyon" in copyright
> * why is kde-baseapps-bin recommended? Veyon is not KDE-related at all
that did some error handling if users were not in the correct group(s).
As veyon-service is now a systemd system service, the wrapper script
has been dropped. And so should the Recommends: field.
-> done.
> * as of upcoming 4.1.6 release you should reconsider to not repack the source
> tarball as all unused source files (except for x11vnc/libvncserver) will get
> stripped anyway (https://github.com/veyon/veyon/commit/
> cc54151fb31524bd67a6160acaac1204f55e9ccd).
for Debian buster's soft freeze (midst of February)?
https://wiki.debian.org/DebianBuster
Tobias Junghans
Dec 27, 2018, 11:10:03 AM12/27/18
to
Hi Mike,
Am Freitag, 7. Dezember 2018, 10:45:16 CET schrieb Mike Gabriel:
> > * as of upcoming 4.1.6 release you should reconsider to not repack the
> > source tarball as all unused source files (except for
> > x11vnc/libvncserver) will get stripped anyway
> > (https://github.com/veyon/veyon/commit/
> > cc54151fb31524bd67a6160acaac1204f55e9ccd).
>
> That is great news!!! When is the due date of 4.1.6. Will you make it
> for Debian buster's soft freeze (midst of February)?
> https://wiki.debian.org/DebianBuster
FYI: 4.1.6 has been released about 1 week ago and includes most of your
patches.
Best regards
Tobias
Am Freitag, 7. Dezember 2018, 10:45:16 CET schrieb Mike Gabriel:
> > * as of upcoming 4.1.6 release you should reconsider to not repack the
> > source tarball as all unused source files (except for
> > x11vnc/libvncserver) will get stripped anyway
> > (https://github.com/veyon/veyon/commit/
> > cc54151fb31524bd67a6160acaac1204f55e9ccd).
>
> That is great news!!! When is the due date of 4.1.6. Will you make it
> for Debian buster's soft freeze (midst of February)?
> https://wiki.debian.org/DebianBuster
patches.
Best regards
Tobias
Tobias Junghans
Dec 29, 2018, 11:50:05 AM12/29/18
to
Hi Mike,
Am Freitag, 28. Dezember 2018, 11:12:01 CET schrieb Mike Gabriel:
> in some previous mail, you mentioned that you have dropped some copies
> of code (or that it is possible to do that when repacking).
>
> Can you be more specific on that?
All non-required 3rdparty files are deleted before creating the source
tarball, see the strip-scripts at https://github.com/veyon/veyon/tree/
4.1/.travis/common for details. The source tarball now only includes files
required for building Veyon.
Best regards
Tobias
Am Freitag, 28. Dezember 2018, 11:12:01 CET schrieb Mike Gabriel:
> in some previous mail, you mentioned that you have dropped some copies
> of code (or that it is possible to do that when repacking).
>
> Can you be more specific on that?
tarball, see the strip-scripts at https://github.com/veyon/veyon/tree/
4.1/.travis/common for details. The source tarball now only includes files
required for building Veyon.
Best regards
Tobias
Mike Gabriel
Jan 14, 2019, 5:10:04 AM1/14/19
to
Hi Tobias,
On Do 27 Dez 2018 17:07:20 CET, Tobias Junghans wrote:
Veyon is now in Debian unstable. I have just uploaded 4.1.6. I guess,
I will skip 4.1.90. When do you expect 4.2.0 do be out? Will you make
it before the Debian soft freeze (2019-02-12)?
Please also test the official Debian packages. Thanks.
Greets,
On Do 27 Dez 2018 17:07:20 CET, Tobias Junghans wrote:
I will skip 4.1.90. When do you expect 4.2.0 do be out? Will you make
it before the Debian soft freeze (2019-02-12)?
Please also test the official Debian packages. Thanks.
Greets,
Tobias Junghans
Jan 30, 2019, 9:40:03 AM1/30/19
to
Hi Mike,
Am Montag, 14. Januar 2019, 11:06:36 CET schrieb Mike Gabriel:
> Veyon is now in Debian unstable.
Perfect, thanks a lot for your work on this!
> I have just uploaded 4.1.6.
OK. If you want you can update to 4.1.7 which simply adds new translations and
updates existing ones (no other changes for Linux in this release).
> I will skip 4.1.90. When do you expect 4.2.0 do be out? Will you make
> it before the Debian soft freeze (2019-02-12)?
No, Veyon 4.2 will be finished not before the end of Q1/2019. Besides that I
fear it initially won't be as stable as Veyon 4.1.x is now due to some major
internal changes.
Best regards
Tobias
Am Montag, 14. Januar 2019, 11:06:36 CET schrieb Mike Gabriel:
> Veyon is now in Debian unstable.
> I have just uploaded 4.1.6.
updates existing ones (no other changes for Linux in this release).
> I will skip 4.1.90. When do you expect 4.2.0 do be out? Will you make
> it before the Debian soft freeze (2019-02-12)?
fear it initially won't be as stable as Veyon 4.1.x is now due to some major
internal changes.
Best regards
Tobias
Mike Gabriel
Jan 31, 2019, 5:40:03 AM1/31/19
to
Hi Tobi.
On Mi 30 Jan 2019 15:33:38 CET, Tobias Junghans wrote:
> Hi Mike,
>
> Am Montag, 14. Januar 2019, 11:06:36 CET schrieb Mike Gabriel:
>> Veyon is now in Debian unstable.
>
> Perfect, thanks a lot for your work on this!
:-)
>> I have just uploaded 4.1.6.
>
> OK. If you want you can update to 4.1.7 which simply adds new
> translations and
> updates existing ones (no other changes for Linux in this release).
>
Uploaded 4.1.7 just now.
>> I will skip 4.1.90. When do you expect 4.2.0 do be out? Will you make
>> it before the Debian soft freeze (2019-02-12)?
>
> No, Veyon 4.2 will be finished not before the end of Q1/2019. Besides that I
> fear it initially won't be as stable as Veyon 4.1.x is now due to some major
> internal changes.
Ok. Please be so kind an ping me whenever you have a new release on
the 4.1.x series until 4.2.0 is recommendable for an upload to Debian.
Unfortunately, the 4.1.90 tag on the upstream Git repo shadows release
on the 4.1.x series in my DDPO overview page [1].
Thanks+Greets,
Mike
[1] https://qa.debian.org/developer.php?email=sunweaver%40debian.org
On Mi 30 Jan 2019 15:33:38 CET, Tobias Junghans wrote:
> Hi Mike,
>
> Am Montag, 14. Januar 2019, 11:06:36 CET schrieb Mike Gabriel:
>> Veyon is now in Debian unstable.
>
> Perfect, thanks a lot for your work on this!
>> I have just uploaded 4.1.6.
>
> OK. If you want you can update to 4.1.7 which simply adds new
> translations and
> updates existing ones (no other changes for Linux in this release).
>
>> I will skip 4.1.90. When do you expect 4.2.0 do be out? Will you make
>> it before the Debian soft freeze (2019-02-12)?
>
> No, Veyon 4.2 will be finished not before the end of Q1/2019. Besides that I
> fear it initially won't be as stable as Veyon 4.1.x is now due to some major
> internal changes.
the 4.1.x series until 4.2.0 is recommendable for an upload to Debian.
Unfortunately, the 4.1.90 tag on the upstream Git repo shadows release
on the 4.1.x series in my DDPO overview page [1].
Thanks+Greets,
Mike
[1] https://qa.debian.org/developer.php?email=sunweaver%40debian.org
0 new messages