Bug#987327: autopkgtests for debian-edu-doc binary packages
[ Holger Levsen, 2021-04-21 ] > we should add autopkgtests to debian-edu-doc to ensure each document > has been built for the three formats pdf, epub and html. > > another condition is that every debian-edu-doc-* package should > contain at least one document, unless the package has 'transitional' > in it's description. sounds good. > On Wed, Apr 21, 2021 at 09:20:38PM +0200, Petter Reinholdtsen wrote: > > [Holger Levsen] > > > I'll guess I'll invent something myself then... > > What about looking for selected keywords like 'Debian Edu', 'Skolelinux, > > "$(lsb_release -c -s)" or similar by grepping the documentation files, > > thanks, grepping for known strings is indeed a good idea, though > we should choose those few untranslated english ones... > > > to ensure the content is somewhat relevant? And perhaps linting the > > HTML (weblint-perl?) and epub (epubcheck?) files to verify the format is > > correct? > > I was thinking of just using /usr/bin/file... IIRC, we had all sorts of problems in the past, some of them unnoticed for some time: - missing files of some format due to wrong XML syntax in PO files - missing PDF files for a specific language - problems with non-ascii language PDF files - HTML files with somehow broken markup - invalid EPUB files In some cases, verifying the format would have revealed the cause for missing files/internal issues, i.e would have allowed one to locate the broken XML syntax (most cases) more easily. src:desktop-base has an autopkgtest to validate XML files, xmllint from libxml2-utils is used. Maybe xmllint could also be used to check HTML files. Besides checking EPUB files, epubcheck has also been useful in the past to detect HTML markup errors caused by XML tag mismatch (which xmllint failed to detect). And 'qpdf --check ' could be used to validate PDF files. Wolfgang signature.asc Description: PGP signature
Bug#987327: autopkgtests for debian-edu-doc binary packages
package: src:debian-edu-doc severity: wishlist x-debbugs-cc: Petter Reinholdtsen , Paul Gevers , 986...@bugs.debian.org, debian-edu@lists.debian.org Hi, we should add autopkgtests to debian-edu-doc to ensure each document has been built for the three formats pdf, epub and html. another condition is that every debian-edu-doc-* package should contain at least one document, unless the package has 'transitional' in it's description. On Wed, Apr 21, 2021 at 09:20:38PM +0200, Petter Reinholdtsen wrote: > [Holger Levsen] > > I'll guess I'll invent something myself then... > What about looking for selected keywords like 'Debian Edu', 'Skolelinux, > "$(lsb_release -c -s)" or similar by grepping the documentation files, thanks, grepping for known strings is indeed a good idea, though we should choose those few untranslated english ones... > to ensure the content is somewhat relevant? And perhaps linting the > HTML (weblint-perl?) and epub (epubcheck?) files to verify the format is > correct? I was thinking of just using /usr/bin/file... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Climate change" is an euphenism. "Global warming" as well. signature.asc Description: PGP signature
Re: Bug#986984: unblock: debian-edu-doc/2.11.22
[Holger Levsen] > I'll guess I'll invent something myself then... What about looking for selected keywords like 'Debian Edu', 'Skolelinux, "$(lsb_release -c -s)" or similar by grepping the documentation files, to ensure the content is somewhat relevant? And perhaps linting the HTML (weblint-perl?) and epub (epubcheck?) files to verify the format is correct? -- Happy hacking Petter Reinholdtsen
Re: Bug#986984: unblock: debian-edu-doc/2.11.22
Hi Paul, On Mon, Apr 19, 2021 at 09:56:01PM +0200, Paul Gevers wrote: > I guess that's about the best we can do for such -doc packages. I > realize it's slightly "unfair" because of the different treatment we > have in the current freeze, but I wonder if adding autopkgtest (to test > as-installed packages) is really worth it for such packages. > Documentation changes and translations have always been on the exception > list, even very explicitly this time around [1], so I think we're happy > to just unblock manually. Having said that, I'll not stop you from > adding the test. :) thanks for your comments! TBH I was hoping for some prior art in some other doc package, not primarily to ease testing migration but rather to make sure the contents are as we would like them to be. we've had failures to build pdf|epub|html versions of some languages in the past and it would be nice to catch those automatically. I'll guess I'll invent something myself then... -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ There are no jobs on a dead planet. (Also many other things but people mostly seem to care about jobs.) signature.asc Description: PGP signature
Re: Client time/date synchronisation
[ roman.me...@gismap.ch, 2021-04-21 ] > I have added the suggested line to LDAP. It looks like this now: > > 121 cn=ltspConfigDefault,ou=ltsp,dc=skole,dc=skolelinux,dc=no > objectClass: ltspClientConfig > cn: ltspConfigDefault > ltspConfig: KEEP_SYSTEM_SERVICES=lightdm > ltspConfig: LTSP_FATCLIENT="False" > ltspConfig: TIMESERVER=ntp > > After this, my client still boots as "diskless workstation" and the > content of /run/ltsp/ltsp_config_env shows LTSP_FATCLIENT="True" > instead of "False". That's weird, but I expected something like this because ntp.conf was left unchanged according to your report. There should be LTSP_FATCLIENT="True" in ltsp_config_env before the three mentioned settings, but LTSP_FATCLIENT="False" at the end (overriding the first occurence). > Are changes to LDAP validated on-the-fly upon save or do I need to add > another step like commit, rebuilding the image, etc.? No additional step needed. During LTSP client boot, some scripts are executed to configure the client (overlay filesystem). The scripts are located in the /usr/share/ltsp/init-ltsp.d/ directory inside the SquashFS image resp. in /opt/ltsp/i386/usr/share/ltsp/init-ltsp.d/ Please check those places. Wolfgang signature.asc Description: PGP signature
Re: Client time/date synchronisation
Hi Wolfgang, Sorry, still no good news. I have added the suggested line to LDAP. It looks like this now: 121 cn=ltspConfigDefault,ou=ltsp,dc=skole,dc=skolelinux,dc=no objectClass: ltspClientConfig cn: ltspConfigDefault ltspConfig: KEEP_SYSTEM_SERVICES=lightdm ltspConfig: LTSP_FATCLIENT="False" ltspConfig: TIMESERVER=ntp After this, my client still boots as "diskless workstation" and the content of /run/ltsp/ltsp_config_env shows LTSP_FATCLIENT="True" instead of "False". Are changes to LDAP validated on-the-fly upon save or do I need to add another step like commit, rebuilding the image, etc.? Kind regards, Roman > On 04/21/2021 1:31 PM Wolfgang Schweer wrote: > > > Hi Roman, > > [ roman.me...@gismap.ch, 2021-04-21 ] > > I also played around with LDAP unsuccessfully trying to increasing the > > threshold for my clients to boot as thin client. > > Maybe it doesn't take effect anymore for some reason… > But you should be able to do this by setting the client type in LDAP > > ltspConfig: LTSP_FATCLIENT="False" > > You should be able to see the environment variables actually used: > cat /run/ltsp/ltsp_config_env (diskless workstation) > > If running a thin client, log in graphically as first user. Then switch > to a terminal (Ctrl-Alt-F1), log in as first user, run 'sudo su -' to > become root and run 'cat /run/ltsp/ltsp_config_env' and maybe check > other things, too. > > > That's all I can remember. Is the log file I sent not helpful? > > I can't find anything suspicious… > > Wolfgang
Re: Client time/date synchronisation
Hi Roman, [ roman.me...@gismap.ch, 2021-04-21 ] > I also played around with LDAP unsuccessfully trying to increasing the > threshold for my clients to boot as thin client. Maybe it doesn't take effect anymore for some reason… But you should be able to do this by setting the client type in LDAP ltspConfig: LTSP_FATCLIENT="False" You should be able to see the environment variables actually used: cat /run/ltsp/ltsp_config_env (diskless workstation) If running a thin client, log in graphically as first user. Then switch to a terminal (Ctrl-Alt-F1), log in as first user, run 'sudo su -' to become root and run 'cat /run/ltsp/ltsp_config_env' and maybe check other things, too. > That's all I can remember. Is the log file I sent not helpful? I can't find anything suspicious… Wolfgang signature.asc Description: PGP signature
Re: Client time/date synchronisation
Hi Wolfgang, Well, I had to create the i386 image myself because it is not created by default any longer. I also played around with LDAP unsuccessfully trying to increasing the threshold for my clients to boot as thin client. That's all I can remember. Is the log file I sent not helpful? Kind regards, Roman > On 04/21/2021 11:40 AM Wolfgang Schweer wrote: > > > Hi Roman, > > [ roman.me...@gismap.ch, 2021-04-21 ] > > > I just checked the content of /etc/ntp.conf of my "diskless > > workstation" client. No line "server ntp" has been appended. > > > > Guess that explains the problem I'm having, right? > > Yes; any LDAP or LTSP chroot changes on your side? > > Wolfgang
Re: Client time/date synchronisation
Hi Roman, [ roman.me...@gismap.ch, 2021-04-21 ] > I just checked the content of /etc/ntp.conf of my "diskless > workstation" client. No line "server ntp" has been appended. > > Guess that explains the problem I'm having, right? Yes; any LDAP or LTSP chroot changes on your side? Wolfgang signature.asc Description: PGP signature
Fwd: Re: Client time/date synchronisation
Hi Wolfgang, Let me also add the syslog. It may probably help: Apr 21 08:51:18 tjener dhcpd[1627]: reuse_lease: lease age 93385 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.20 Apr 21 08:51:18 tjener dhcpd[1627]: DHCPDISCOVER from 00:d0:59:22:05:43 via eth1 Apr 21 08:51:18 tjener dhcpd[1627]: DHCPOFFER on 192.168.0.20 to 00:d0:59:22:05:43 via eth1 Apr 21 08:51:18 tjener dhcpd[1627]: reuse_lease: lease age 93385 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.20 Apr 21 08:51:18 tjener dhcpd[1627]: DHCPREQUEST for 192.168.0.20 (192.168.0.254) from 00:d0:59:22:05:43 via eth1 Apr 21 08:51:18 tjener dhcpd[1627]: DHCPACK on 192.168.0.20 to 00:d0:59:22:05:43 via eth1 Apr 21 08:51:18 tjener nbd_server[1121]: Spawned a child process Apr 21 08:51:18 tjener nbd_server[14337]: virtstyle ipliteral Apr 21 08:51:18 tjener nbd_server[14337]: connect from 192.168.0.20, assigned file is /opt/ltsp/images/i386.img Apr 21 08:51:18 tjener nbd_server[14337]: Can't open authorization file /etc/ltsp/nbd-server.allow (No such file or directory). Apr 21 08:51:18 tjener nbd_server[14337]: Size of exported file/device is 3733676032 Apr 21 08:51:18 tjener nbd_server[14337]: Starting to serve Apr 21 08:51:23 tjener named[1016]: resolver priming query complete Apr 21 08:51:23 tjener ntpd[1029]: error resolving pool 2.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:51:33 tjener named[1016]: resolver priming query complete Apr 21 08:51:33 tjener ntpd[1029]: error resolving pool 0.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:51:43 tjener named[1016]: resolver priming query complete Apr 21 08:51:43 tjener ntpd[1029]: error resolving pool 3.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:51:53 tjener named[1016]: resolver priming query complete Apr 21 08:51:53 tjener ntpd[1029]: error resolving pool 1.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:52:27 tjener nbd_server[1121]: Spawned a child process Apr 21 08:52:27 tjener nbd_server[14491]: virtstyle ipliteral Apr 21 08:52:27 tjener nbd_server[14491]: connect from 192.168.0.20, assigned file is /var/opt/ltsp/swapfiles/192.168.0.20 Apr 21 08:52:27 tjener nbd_server[14491]: Can't open authorization file (No such file or directory). Apr 21 08:52:27 tjener nbd_server[14491]: Client '192.168.0.20' not allowed access by prerun script Apr 21 08:52:27 tjener nbd_server[14491]: Negotiation failed: Connection reset by peer Apr 21 08:52:27 tjener nbd_server[14491]: Exiting. Apr 21 08:52:27 tjener nbd_server[1121]: Child exited with 1 Apr 21 08:52:30 tjener named[1016]: resolver priming query complete Apr 21 08:52:30 tjener ntpd[1029]: error resolving pool 2.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:52:40 tjener named[1016]: resolver priming query complete Apr 21 08:52:40 tjener ntpd[1029]: error resolving pool 0.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:52:50 tjener ntpd[1029]: error resolving pool 3.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:52:50 tjener named[1016]: resolver priming query complete Apr 21 08:53:00 tjener named[1016]: resolver priming query complete Apr 21 08:53:00 tjener ntpd[1029]: error resolving pool 1.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:53:19 tjener slapd[1247]: get_filter: conn 1151 unknown attribute type=wWWHomePage (17) Apr 21 08:53:19 tjener slapd[1247]: get_filter: conn 1152 unknown attribute type=wWWHomePage (17) Apr 21 08:53:20 tjener named[1016]: resolver priming query complete Apr 21 08:53:30 tjener named[1016]: resolver priming query complete Apr 21 08:53:35 tjener ntpd[1029]: error resolving pool 2.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:53:45 tjener named[1016]: resolver priming query complete Apr 21 08:53:45 tjener ntpd[1029]: error resolving pool 3.debian.pool.ntp.org: Name or service not known (-2) Apr 21 08:53:55 tjener named[1016]: resolver priming query complete Apr 21 08:53:55 tjener ntpd[1029]: error resolving pool 0.debian.pool.ntp.org: Name or service not known (-2) Kind regards, Roman > -- Original Message -- > From: roman.me...@gismap.ch > To: Wolfgang Schweer , "debian-edu@lists.debian.org" > > Date: 04/21/2021 10:33 AM > Subject: Re: Client time/date synchronisation > > > Hi Wolfgang, > > I just checked the content of /etc/ntp.conf of my "diskless workstation" > client. No line "server ntp" has been appended. > > Guess that explains the problem I'm having, right? > > Kind regards, > Roman > > > On 04/20/2021 5:28 PM Wolfgang Schweer wrote: > > > > > > Hi Roman, > > > > [ roman.me...@gismap.ch, 2021-04-20 ] > > > Fact is that my LTSP clients don't have the correct time if the server > > > has no internet connection, which may be perfectly normal, right? > > > > No, it should work. > > > > > There's none on the client in /opt/ltsp/i386/etc/ntp.conf though. > > > >
Fwd: i386 clients not booting as thin client
Hi folks, I'm still stuck here not being able to boot my clients as "thin client". Any ideas what is causing this? Kind regards, Roman > -- Original Message -- > From: roman.me...@gismap.ch > To: "debian-edu@lists.debian.org" > Date: 04/20/2021 9:24 AM > Subject: i386 clients not booting as thin client > > > Hi folks, > > I'm getting my feet wet with the latest version of Debian Edu 10.9.0. > > I was able to prepare the server and additionally create the image for our > i386 clients. > > All our clients are booting nicely using primary and secondary subnet. > However they only boot as "diskless workstation". In older versions of Debian > Edu I was able to edit file /var/lib/tftpboot/ltsp/i386/lts.conf and add > FAT_RAM_THRESHOLD=1000 for all clients having less than 1GB RAM to boot as > thin client instead of diskless workstation. This is not working for me > anymore. > > I also tried to edit LDAP settings using ldapvi. I added the following entry: > ltspConfig: FAT_RAM_THRESHOLD=1000 > This also doesn't work for me. > > Any ideas how to fix this? > > Kind regards, > Roman
Re: Client time/date synchronisation
Hi Wolfgang, I just checked the content of /etc/ntp.conf of my "diskless workstation" client. No line "server ntp" has been appended. Guess that explains the problem I'm having, right? Kind regards, Roman > On 04/20/2021 5:28 PM Wolfgang Schweer wrote: > > > Hi Roman, > > [ roman.me...@gismap.ch, 2021-04-20 ] > > Fact is that my LTSP clients don't have the correct time if the server > > has no internet connection, which may be perfectly normal, right? > > No, it should work. > > > There's none on the client in /opt/ltsp/i386/etc/ntp.conf though. > > LTSP modifies the setting at client startup. A line 'server ntp' should > be appended at the end of ntp.conf. The value 'ntp' is fetched from LDAP > (ltspConfig: TIMESERVER=ntp). > > Replace ntp with auto and check if it makes a difference (less flexible, > but no name resolution needed in this case). > > Wolfgang
