Bug#1077227: libcwiid1: Unintentionally libcwiid1t64 --> libcwiid1 changes ?
Hello Christian, you are right: at some point I missed something. The next step may be tougher for me: how can I withdraw the release 0.6.91-8 from the NEW queue? Thank you in advance for any help. I presume that changes done for the time_t transition in release 0.6.91-7.1 were not published in salsa, neither proposed as a pull request for my repository, because my last push went smoothly. I shall download sources of 0.6.91-7.1, and rebase my changes to comply with gcc-14 on them. Best regards, Georges. On Sat, 27 Jul 2024 07:38:59 +0200 Christian Marillat wrote: > Package: libcwiid1 > Version: 0.6.91-8 > Severity: serious > > Dear Maintainer, > > Would be nice why the libcwiid1t64 has been renamed to libcwiid1 > whithouht a soname change. > > Do you have forgot to include changes done for the time_t transition ? > > , > | cwiid (0.6.91-7.1) unstable; urgency=medium > | > | * Non-maintainer upload. > | * Rename libraries for 64-bit time_t transition. Closes: #1061995 > | > | -- Michael Hudson-Doyle Tue, 27 Feb 2024 23:25:09 > + > ` > > Christian > > -- System Information: > Debian Release: trixie/sid > APT prefers buildd-unstable > APT policy: (500, 'buildd-unstable'), (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.9.11-1-custom (SMP w/24 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libcwiid1 depends on: > ii libbluetooth3 5.73-1 > ii libc6 2.39-6 > > libcwiid1 recommends no packages. > > libcwiid1 suggests no packages. > > -- no debconf information > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1075364: partclone: ftbfs with GCC-14
Hello ntfs-3g maintainers, please excuse my probably misdesigned action. Matthias Klose filed this bug report primarily because package partclone, which is built correctly with gcc-13, FTBFS with gcc-14. I could build it with gcc-14, by applying this simple patch to file /usr/include/ntfs-3g/ntfstime.h: ---8<--- --- /usr/include/ntfs-3g/ntfstime.h.orig2024-07-06 16:58:02.341675225 +0200 +++ /usr/include/ntfs-3g/ntfstime.h 2024-07-06 16:58:46.110108507 +0200 @@ -35,6 +35,7 @@ #endif #include "types.h" +#include /* * assume "struct timespec" is not defined if st_mtime is not defined ---8<--- That means that the bug might be fixed in two ways: 1 - by defining HAVE_TIME_H somewhere outside the file ntfstime.h which would cause the inclusion of time.h, because of lines 27--29 in file ntfstime.h 2 - by enforcing the inclusion of the file time.h as I did Enforcing uncontionnally the inclusion of the file time.h as I did is probably bad. However why should a program like partclone define the macro HAVE_TIME_H just to be able to make use of ntfs-3g in addition to many other filesystems, which do not require such a definition? I suspect that this issue might be addressed, by enhancing the way dh_auto_configure works by default. Thank you in advance for your enlightenments, your suggestions. Best regards, Georges. signature.asc Description: PGP signature
Bug#1073510: *** SPAM *** Re: Bug#1073510 closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1073510: fixed in slm 0.10-2)
Hello, Camaleón a écrit : > Okay, let's then hope the maintainter of the packages notices the > mixing and correct it soon; nothing I can do on my side but warning > about it and reopen the involved bug report, which I already did. > > Thank you both! I have no idea how the mixing happened. I replaced the faulty file with https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1073510;filename=es.po;msg=15 and uploaded release 0.10-3 Best regards, Georges. signature.asc Description: PGP signature
Bug#1074773: qt5-qmake: unable to rebuild package xdrawchem, due to an error of qmake
Package: qt5-qmake Version: 5.15.13+dfsg-2 Severity: important Dear Maintainer, I cannot currently rebuild the package xdrawchem, which uses qmake and also the library libopenbabel-dev A build log can be found at https://salsa.debian.org/georgesk/xdrawchem/-/pipelines/691085 I could reproduce this bug with this minimal example: --8<--- $ sudo cowbuilder login ... root@georges:/# cd tmp root@georges:/tmp# cat > foo.pro < TEMPLATE = app > TARGET = foo > CONFIG += link_pkgconfig > PKGCONFIG += openbabel-3 > EOF root@georges:/tmp# apt install libopenbabel-dev qt5-qmake libqt5core5t64 ... root@georges:/tmp# qmake -makefile Info: creating stash file /tmp/.qmake.stash Project ERROR: openbabel-3 development package not found --8<--- The error message states that openbabel-3 is not there; however the file /usr/lib/x86_64-linux-gnu/pkgconfig/openbabel-3.pc is around. Thank you in advance if you can fix it. Best regards, Georges. -- System Information: Debian Release: trixie/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-25-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qt5-qmake depends on: ii qt5-qmake-bin 5.15.13+dfsg-2 ii qtchooser 66-2 qt5-qmake recommends no packages. qt5-qmake suggests no packages. -- no debconf information
Bug#1073510: *** SPAM *** Re: Spanish translation of slm debconf template (Re: Translation status robot not working?)
Camaleón a écrit : > _Thank you very much_, Holger. +1 :) -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1072864: crontab.5: some remarks and editorial changes for this man page
Hello Bjarni, thank you for the bug report. You noticed that the man page was "auto"generated by xslt, with DocBook XSL Stylesheets: this is right. I shall not apply the patch which you provide, because this patch would modify the "binary" file crontab.5, not the source file which it depends on (the source file is available at https://salsa.debian.org/debian/cron/-/blob/master/debian/crontab.5.xml?ref_type=heads) If I apply your patch now, you or I would need to create a new patch every time a modification is made in the source file. The script test-groff is not part of the Debian distribution, and I am not aware of any policy about its usage. Please help me if I make a mistake about it. Possible solutions to the issues you raised are: - check other manpages in Debian which were "auto"generated by xslt (it is the recommended method now) for similar issues, and file a bugreport to developers and maintainers of DocBook XSL Stylesheets - provide a program to enhance files generated by DocBook XSL Stylesheets, in order to pass "test-groff" -- If you can provide me a link about test-groff, and why this linter should be taken in account, you are welcome. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#956953: cron: add cron jobs to systemd scope cgroups
Hello Paul, I am still missing a feedback about cron 3.0pl1-190 If you are still interested in having the new feature some day in debian/testing (and later in debian/stable), I would appreciate to get a ping, even if you are currently too busy to make tests. Thank you in advance, Georges. On Thu, 23 May 2024 14:26:23 +0200 Georges Khaznadar wrote: > I uploaded a new cron release (3.0pl1-190) to experimental. > > Please can you test this release? > ... signature.asc Description: PGP signature
Bug#1071738: pysatellites: segfault on arm64 with scipy 1.12
Hello Drew, thank you for your report. I shall push a dirty workaround: the file debian/tests/test_gui.py will call scipy to compute the difference between two screenshots only when platform.machine() == 'x86_64'. The test is skipped on arm64, ppc64el and s390x and some other architectures. Should I propose a new test for maintainers of scipy? I suppose that computing the difference between two arrays should be portable. Best regards, Georges. On Tue, 04 Jun 2024 16:17:02 +0200 Drew Parsons wrote: > Source: pysatellites > Version: 2.7-2 > Followup-For: Bug #1071738 > Control: severity 1071738 serious > > The error is persistent after uploading scipy 1.12 to unstable, > so bumping severity to serious. > > ppc64el and s390x are also affected. > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1055749: RFA: freetype-py -- Freetype Python bindings for Python 3
Hello Bastian, I shall adopt this package, as it is a direct dependency for python3-reportlab which I maintain. Best regards, Georges. Bastian Germann a écrit : > Package: wnpp > > As I am no longer interested in the package, I request a new maintainer for > freetype-py. > > Description: Freetype Python bindings for Python 3 > Freetype Python provides bindings for the FreeType library. > Only the high-level API is bound. > > All the font access is done through the FreeType2 library, > which supports many formats. It can render images of characters with > high-quality hinting and antialiasing, extract metrics information, and > extract the outlines of characters in scalable formats like TrueType. > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1071738: pysatellites: segfault on arm64 with scipy 1.12
Hello Drew, I could not reproduce with my machine the issue which you are describing: - I installed python3-scipy 1.12.0-1exp3 over 1.11.4-10 - I launched the test suite : $ cd ~//pysatellites ~//pysatellites$ make pyuic5 pysat.ui -o UI_pysat.py pyuic5 graphe.ui -o UI_graphe.py ~//pysatellites$ debian/tests/runtests.sh = test session starts == platform linux -- Python 3.11.9, pytest-7.4.4, pluggy-1.5.0 PyQt5 5.15.10 -- Qt runtime 5.15.10 -- Qt compiled 5.15.10 rootdir: ~//pysatellites plugins: filter-subpackage-0.2.0, mock-3.12.0, arraydiff-0.6.1, doctestplus-1.2.1, anyio-4.3.0, astropy-header-0.2.2, hypothesis-6.102.1, typeguard-4.1.5, openfiles-0.5.0, remotedata-0.4.1, qt-4.3.1 collected 2 items debian/tests/test_gui.py . [ 50%] debian/tests/test_trajectoire.py . [100%] == 2 passed in 12.17s == ... with no error. Is there another trick to reproduce the bug? Best regards, Georges. Drew Parsons a écrit : > Source: pysatellites > Version: 2.7-2 > Severity: important > > pysatellites is failing tests with segfault against scipy 1.12 (from > experimental) and python3.11. > > 157s = test session starts > == > 157s platform linux -- Python 3.11.9, pytest-8.1.2, pluggy-1.5.0 > 157s PyQt5 5.15.10 -- Qt runtime 5.15.13 -- Qt compiled 5.15.13 > 157s rootdir: /tmp/autopkgtest-lxc.todkr5yw/downtmp/build.FIz/src > 157s plugins: qt-4.3.1 > 157s collected 2 items > 157s > 161s debian/tests/test_gui.py . > [ 50%] > 161s debian/tests/test_trajectoire.py . > [100%] > 161s > 161s == 2 passed in 5.18s > === > 161s Segmentation fault (core dumped) > > > scipy 1.12 will be uploaded to unstable in the near future, > which will make this bug serious. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#956953: cron: add cron jobs to systemd scope cgroups
Hello Paul, I uploaded a new cron release (3.0pl1-190) to experimental. Please can you test this release? If the modifications match your needs, would you be kind enough to propose two additional things? 1- a script to test that the new feature is working (when cron is installed in a clean chroot) 2- a short description of Debian's specific feature which is added by the new release, to be included at some point in cron's man page. Thank you in advance for your feedback. Best regards, Georges. Paul Wise a écrit : > On Mon, 2023-12-18 at 16:07 +0100, Georges Khaznadar wrote: > > > Can I assume that you are talking about the switch --description= ? > > I was talking about --unit but as long as the resulting unit name bears > some resemblance to the cron command it is from, that would be fine. > > > I would propose to use the command's name (without arguments), appended > > with an underscore and the pid of the forked grandchild process managed > > by cron as a description. So one can take a look at /proc/ to get > > more information. What do you think about it? > > Hmm, for the description I would just use the full command with args, > prepended with "cron job $USER $PID: " or something similiar. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1070709: ITP: primtux-multiples -- graphic representation of multiplications as grid patterns
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: primtux-multiples Version : 3.0 Upstream Contact: Arnaud Champollion <https://forge.aeif.fr/achampollion> * URL : https://forge.apps.education.fr/educajou/multiples/ * License : GPL2 Programming Lang: Python3 Description : graphic representation of multiplications as grid patterns This programm is part of the project Primtux (https://primtux.fr), which aims to provide simple and effective programs for teaching in primary schools. The packaging will be maintained in https://salsa.debian.org/debian/primtux- multiples
Bug#1070467: ITP: tuxblocs -- program to display tens, hundreds, thousands as 3D blocks
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: tuxblocs Version : 4.0 Upstream Contact: Arnaud Champollion * URL : https://educajou.forge.apps.education.fr/tuxblocs/ * License : GPL2 Programming Lang: Python Description : program to display tens, hundreds, thousands as 3D blocks Tuxblocs helps students in K-12 schools to understand the positional numeration system. . It is not an exerciser for students to use directly; it is rather a tool for presentations. Packaging this program is a mean to foster the creations of association Primtux (https://primtux.fr), by pushing their creations to Debian. The same author already authored fracatux, another educational program which is now in Debian. The package will be maintained in https://salsa.debian.org/debian/tuxblocs
Bug#1069922: bcron: stop using dh-sysuser
Hello Helmut, thank you for youe work. I uploaded the new revision of
bcron.
Best regards, Georges.
Helmut Grohne a écrit :
> Package: bcron
> Version: 0.11-21
> Severity: wishlist
> Tags: patch
>
> Hi,
>
> please stop using dh-sysuser. dh-sysuser is in operation since 7 years
> and has only gotten 9 reverse dependencies in that time. The vast
> majority of packages use the /usr/lib/sysusers.d mechanism supported by
> debhelper. dh-sysuser has a number of deficiencies such as using using
> useradd instead of policy-recommended adduser, removing users on purge
> when project consensus is that users should not be removed. With the
> availability of multiple implementations of the sysusers.d format even
> for non-linux systems, I think it is time to settle on that standard and
> call dh-sysuser failed. I'm attaching a patch for your convenience. Do
> you agree with the reasoning?
>
> Helmut
> diff --minimal -Nru bcron-0.11/debian/bcron.postinst
> bcron-0.11/debian/bcron.postinst
> --- bcron-0.11/debian/bcron.postinst 2023-06-27 14:57:38.0 +0200
> +++ bcron-0.11/debian/bcron.postinst 2024-04-27 09:10:46.0 +0200
> @@ -7,11 +7,10 @@
>
> CRONTABDIR=/var/spool/cron/crontabs
>
> +#DEBHELPER#
> +
> case "$1" in
> configure)
> - # create user cron now when it doe not exist
> - # this may bypass bcron.sysuser
> - getent passwd cron || adduser --system --group --home /var/spool/cron
> cron
> # add acls for user and group cron
> setfacl -m u:cron:rwx $CRONTABDIR
> setfacl -m g:cron:rwx $CRONTABDIR
> @@ -30,6 +29,4 @@
> ;;
> esac
>
> -#DEBHELPER#
> -
> exit 0
> diff --minimal -Nru bcron-0.11/debian/bcron.sysuser
> bcron-0.11/debian/bcron.sysuser
> --- bcron-0.11/debian/bcron.sysuser 2023-06-27 14:57:38.0 +0200
> +++ bcron-0.11/debian/bcron.sysuser 1970-01-01 01:00:00.0 +0100
> @@ -1 +0,0 @@
> -cron home=/var/spool/cron
> diff --minimal -Nru bcron-0.11/debian/bcron.sysusers
> bcron-0.11/debian/bcron.sysusers
> --- bcron-0.11/debian/bcron.sysusers 1970-01-01 01:00:00.0 +0100
> +++ bcron-0.11/debian/bcron.sysusers 2024-04-27 09:08:59.0 +0200
> @@ -0,0 +1 @@
> +ucron- "Cron daemon user" /var/spool/cron
> diff --minimal -Nru bcron-0.11/debian/changelog bcron-0.11/debian/changelog
> --- bcron-0.11/debian/changelog 2023-07-17 16:20:52.0 +0200
> +++ bcron-0.11/debian/changelog 2024-04-27 09:10:54.0 +0200
> @@ -1,3 +1,10 @@
> +bcron (0.11-21.1) UNRELEASED; urgency=medium
> +
> + * Non-maintainer upload.
> + * Move from dh-sysuser to standard dh_installsysuser. (Closes: #-1)
> +
> + -- Helmut Grohne Sat, 27 Apr 2024 09:10:54 +0200
> +
> bcron (0.11-21) unstable; urgency=medium
>
>* implemented as much as I could understand from Michael Biebl's and
> diff --minimal -Nru bcron-0.11/debian/control bcron-0.11/debian/control
> --- bcron-0.11/debian/control 2023-06-27 16:24:17.0 +0200
> +++ bcron-0.11/debian/control 2024-04-27 09:10:54.0 +0200
> @@ -3,10 +3,10 @@
> Priority: optional
> Maintainer: Georges Khaznadar
> Build-Depends:
> + debhelper (>= 13.3),
> debhelper-compat (= 13),
> dh-buildinfo (>= 0.11+nmu1),
> dh-runit (>= 2.8.1~),
> - dh-sysuser (>= 1.3),
> dpkg-dev (>= 1.18.11),
> groff,
> libbg-dev (>= 2),
> @@ -27,7 +27,6 @@
> ${misc:Depends},
> ${shlibs:Depends},
> daemon,
> - adduser
> Recommends:
> default-mta | mail-transport-agent,
> runit
> diff --minimal -Nru bcron-0.11/debian/rules bcron-0.11/debian/rules
> --- bcron-0.11/debian/rules 2023-06-27 16:42:02.0 +0200
> +++ bcron-0.11/debian/rules 2024-04-27 09:10:54.0 +0200
> @@ -12,7 +12,7 @@
> endef
>
> %:
> - dh $@ --with runit,buildinfo,sysuser
> + dh $@ --with runit,buildinfo
>
> override_dh_auto_build:
> rm -f bcron.info
> @@ -33,6 +33,10 @@
> $(call initscript,bcron-sched)
> $(call initscript,bcron-spool)
>
> +# Drop override when bumping to compat 14 or later.
> +execute_after_dh_installinit:
> + dh_installsysusers
> +
> override_dh_installchangelogs:
> dh_installchangelogs NEWS
>
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
Bug#1065356: Issues in man pages of cron
Hello Helge, I have completely rewritten the man pages for cron in Docbook XML format, which allows us to use Docbook's markup to declare the role of words more precisely. One casuality is that your bug report will no longer remain valid, and that there will be more to do for translators probably. However Docbook XML sources should be more stable in the future, and I checked thoroughly than the generated man pages contain the same paragraphs as previously, albeit with different indentations, and also different emphasis schemes. The next package upload will close the present bug report, please feel free to reopen it. Best regards, Georges. Helge Kreutzmann a écrit : > Hello Georges, > Am Mon, Mar 04, 2024 at 11:47:03AM +0100 schrieb Georges Khaznadar: > > Helge Kreutzmann a écrit : > > > > > > > Secondly we translators see the manpages in the neutral po format, > > > > > i.e. converted and harmonized, but not the original source (be it man, > > > > > groff, xml or other). So we cannot provide a true patch (where > > > > > possible), but only an approximation which you need to convert into > > > > > your source format. > > > > > > > > The original format for Debian's manpages regarding cron is groff. > > > > Would the translators' work become easier if the manpages were rewritten > > in some higher-level language than groff? I must admit that I am not at > > ease with groff sources, and that I use weird hacks when modifying such > > or such part of a manpage when some feature of cron or crontab is > > changed. > > Simple answer: No. > > In the end, man pages are transformed into groff and this is what we > get, and our toolchain po4a handles it quite nicely. Actually, > translators do not see groff at all, but some pseudo language they are > familiar with. (Thats why I had to double check my groff proposals, I > hardly see groff except when i discuss the issues in the man pages of > groff themselves …) > > > The source in groff format often contains very short lines, where more > > context would be necessary to grasp the sense. > > > > So, please tell me whether it would be useful to rewrite the three > > manpages in XML format? > > From my POV it is not necessary. As said earlier, I think the context > is sufficient, translators can always build the entire (translated) > file to check and shorter paragraphs are easier to handle and reuse. > > > This would mean writing sensible paragraphs, with lines of seventy or > > more characters, containing simple text and elements marked by tags like > > or , which > > convey more sense than the bare bold/italics directives available in > > groff. > > In the end, this is up to you and we translators follow suite. Please > note, howver, that not all translations are maintained. Currently we > have (partial) translations for ko, fr, pl, fi, ro, de and id. There > are no active translators for ko, fi and id, and I'm not sure how fast > the translators for fr and pl will pick it up. > > So from my POV I would suggest to keep them as is, unless the pain is > really large or you intend to add/update lots of content. > > > > That's usual, but po4a transforms this in a more friendly format for > > > us translators. > > > > Here is what I understood so far, from the first e-mail you sent me > > yesterday, and from the enlightenments provided by the second one: > > > > Each report chunk is divided in two parts, a list of issues and a > > context string, which I describe below in some wild meta-language > > using square brackets: > > > > - > > Man page: [source file] > > Issue #n: [incorrect format] → [fixed format] > > ... > > > > "[some context, extracted by po4a from the source file]" > > "..." > > -- > > - > > > > Please can you confirm or infirm that the interpretation above can be > > trusted? > > Yes, this is 100% correct. > > > > I think most of the report boils down that you update the patches by > > > using .B instead of .I or sometimes .BI > > > > This is a particular consequence of a more general guideline, to follow > > recommendations provided by `man man-pages`. I would feel more at ease > > if this compliance was ensured by an automated process fed by a source > > file with high-level syntactic markup. > > Yes, I see your point. And if you were to write t
Bug#1065358: cron: No documentation in crontab(5) for extentions @reboot, @yearly, etc.
Hello Marianne, `man 5 crontab` does provide the required information, when I use the last release available in trixie (3.0pl1-188): --8<-- $ man 5 crontab| grep -B2 -A7 @reboot string meaning -- --- @rebootRun once, at startup. @yearlyRun once a year, "0 0 1 1 *". @annually (same as @yearly) @monthly Run once a month, "0 0 1 * *". @weeklyRun once a week, "0 0 * * 0". @daily Run once a day, "0 0 * * *". @midnight (same as @daily) @hourlyRun once an hour, "0 * * * *". Please note that startup, as far as @reboot is concerned, is the time when the cron(8) daemon startup. In particular, it may be before some system daemons, or other facilities, were startup. This is due to the boot order sequence of the machine. EXAMPLE CRON FILE # use /usr/bin/sh to run commands, no matter what /etc/passwd says SHELL=/usr/bin/sh --8<-- So, this bug is currently fixed, I shall close the bug report, please feel free to reopen it when necessary. By the way: all modification made to Vixie's cron are living under the directory debian/patches; if you want to have a look at the current state of the sources, please apply the debian patches. Best regards, Georges. Marianne CHEVROT CHEVALLIER a écrit : > Package: cron > Version: 3.0pl1-162 > Severity: normal > > Dear Maintainer, > > * What led up to the situation? > > I wanted to check the documentation about the @reboot and remark it's > missing > from the manual page. > > * What exactly did you do (or not do) that was effective (or ineffective)? > > I checked on the debian repo https://salsa.debian.org/debian/cron master > branch and confirmed there was no documentation for that on crontab.5 file. > > * What was the outcome of this action? > > I couldn't check usage and available option for crontab. > > * What outcome did you expect instead? > > To have the documentation about these features. > > > -- Package-specific info: > --- EDITOR: > not set > > --- /usr/bin/editor: > /usr/bin/vim.gtk3 > > --- /usr/bin/crontab: > -rwxr-sr-x 1 root crontab 43648 Mar 2 2023 /usr/bin/crontab > > --- /var/spool/cron: > drwxr-xr-x 3 root root 4096 Dec 24 2017 /var/spool/cron > > --- /var/spool/cron/crontabs: > drwx-wx--T 2 root crontab 4096 Feb 12 2023 /var/spool/cron/crontabs > > --- /etc/cron.d: > drwxr-xr-x 2 root root 4096 Aug 26 2023 /etc/cron.d > > --- /etc/cron.daily: > drwxr-xr-x 2 root root 4096 Feb 4 11:40 /etc/cron.daily > > --- /etc/cron.hourly: > drwxr-xr-x 2 root root 4096 Jun 16 2023 /etc/cron.hourly > > --- /etc/cron.monthly: > drwxr-xr-x 2 root root 4096 Jun 16 2023 /etc/cron.monthly > > --- /etc/cron.weekly: > drwxr-xr-x 2 root root 4096 Jun 16 2023 /etc/cron.weekly > > > -- System Information: > Debian Release: 12.5 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages cron depends on: > ii cron-daemon-common 3.0pl1-162 > ii init-system-helpers 1.65.2 > ii libc6 2.36-9+deb12u4 > ii libpam-runtime 1.5.2-6+deb12u1 > ii libpam0g 1.5.2-6+deb12u1 > ii libselinux1 3.4-1+b6 > ii sensible-utils 0.0.17+nmu1 > > Versions of packages cron recommends: > pn default-mta | mail-transport-agent > > Versions of packages cron suggests: > ii anacron 2.3-36 > pn checksecurity > ii logrotate 3.21.0-1 > > Versions of packages cron is related to: > pn libnss-ldap > pn libnss-ldapd > pn libpam-ldap > pn libpam-mount > pn nis > pn nscd > > -- no debconf information > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1067682: ITP: fracatux -- small application to teach fractions, at primary level
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: fracatux Version : 1.5.2 Upstream Contact: Arnaud Champollion <https://forge.aeif.fr/achampollion> * URL : https://forge.aeif.fr/achampollion/fracatux * License : GPL-2+ Programming Lang: Python3 Description : small application to teach fractions, at primary level Fracatux is part of the project Primtux (https://primtux.fr), which aims to provide simple and effective programs for teaching in primary schools. . Fracatux is a free/libre program to display fractions as bars, and to perform various operations with them. It permits, among other things, to make evident equalities of fractions, addition of fractions with the same denominator, and correspondences between fractional, decimal and scientific representations. A scale line (decimal or fractional) allows one to compare those fractions from ordinal point of view. The package will be maintained on salsa.debian.org, under the debian subdirectory.
Bug#1067681: ITP: python-tktooltip -- simple yet fully customisable tooltip/pop-up implementation
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-tktooltip Version : 3.0.0 Upstream Contact: gnikit <https://github.com/gnikit> * URL : https://pypi.org/project/tkinter-tooltip/ * License : Expat Programming Lang: Python3 Description : simple yet fully customisable tooltip/pop-up implementation Tktooltip is a simple yet fully customisable tooltip/pop-up implementation for tkinter widgets. It is capable of fully integrating with custom tkinter themes both light and dark ones. . Features . - normal tooltips - show tooltip with s seconds delay - tooltip tracks mouse cursor - tooltip displays strings and string returning functions - fully customisable, tooltip inherits underlying theme style --- this package is a dependency for some education packages which I aim to publish shortly. Those are coming from project Primtux (https://primtux.fr/), which is a collection of educational small applications for primary education. I shall maintain the package in salsa.d.o, under the umbrella of python-team.
Bug#1067046: RM: pyhanko/experimental -- ROM; An ITP was raised for python-pyhanko, and python-pyhanko is in the NEW queue
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1051487: This not a double dependency
Hello Fabian, I tried once again to understand the sense of your bug report, "python3-reportlab: depends on T1 and TTF fallback fonts at the same time" The code you saw in file debian/patches/dejavu-font-default.diff is not meany something like: "if Vera.t1 does not exist, take Vera.ttf". It rather means: if some Foo.t1 font cannot be found, for any reason, take another surely existing font as a default. Would it be better to pick something like the font C059-Roman.t1, by default? Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1065636: kwartz-client: Please review debconf template
Hello Helge, I modified the debconf template, following your recommendations, thank you! As a side effet, it invalidates the translation you sent me previously; I am uploading the modified templates, which will close both bug reports. Best regards, Georges. Helge Kreutzmann a écrit : > Source: kwartz-client > Version: 2.1-2 > Severity: normal > > While translating your debconf messages we noticed quite a few issues > within the debconf template, ranging from spelling error over punctuation > problems up to difficult to understand sentences. > > Please ask on debian-l10n-english for a review to fix all issues, as > we are not native speakers. > > We found the following issues: > > Issue: The wording "is safe" is ambigous, maybe just state (as other tools do > as well): "If unsure, keep the default list." > > #. Type: string > #. Description > #: ../kwartz-client.templates:2001 > "Please enter the port number of the proxy service. The default value is " > "usually safe." > > > > Issue 1: Missing final full stop > Issue 2: The previous strings do not use "you" in the 2nd sentence, use > coherent wording, avoding "you" > > #. Type: boolean > #. Description > #: ../kwartz-client.templates:6001 > "When the recommended package unattended-upgrades is installed, APT will run " > "in the background to attempt some automatic upgrades. If unsure, you can " > "safely keep the \"false\" option" > > > > > Issue 1: What is "run some automatic update"? Do you mean "When APT updates > the package database"? > Issue 2: Sometimes, "apt" is used, sometimes "APT"? > Issue 3: unpriviledged → unprivileged > > #. Type: string > #. Description > #: ../kwartz-client.templates:7001 > "When APT will run some automatic update for the package database, a user " > "name is needed to use the proxy service. This user must be unpriviledged. If > " > "apt does not need to make automatic upgrades, you can keep the default empty > " > "value." > > > > Issue: The previous prompt uses an article, this is inconsistent > > #. Type: password > #. Description > #: ../kwartz-client.templates:8001 > "Password to access the web:" > > > Issue: some strong password → a strong password > > #. Type: password > #. Description > #: ../kwartz-client.templates:8001 > "The unpriviledged user which will be used by APT to access the web needs a " > "password. It must be some strong password. If apt does not need to make " > "automatic upgrades, you can keep the default empty value." > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de >Dipl.-Phys. http://www.helgefjell.de/debian.php > 64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/ -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1065550: ITP: regressi -- Software to manage experimental data
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: regressi Version : 4.8.1 Upstream Contact: Jean Michel Millet * URL : https://regressi.fr/ * License : GPL-3+ Programming Lang: (Pascal (fpc) Description : Software to manage experimental data Regressi can be used to manage experimental data, while teaching science in secondary schools and universities. It features fitting experimental data with classic or custom models, creating simulated data from models. It can also be used to interactively retreive data from recorded video files. This package will be maintained under the umbrella of science-team, there is a repository at https://salsa.debian.org/science-team/regressi
Bug#1065356: Issues in man pages of cron
Hello Helge, Helge Kreutzmann a écrit : > > > Secondly we translators see the manpages in the neutral po format, > > > i.e. converted and harmonized, but not the original source (be it man, > > > groff, xml or other). So we cannot provide a true patch (where > > > possible), but only an approximation which you need to convert into > > > your source format. > > > > The original format for Debian's manpages regarding cron is groff. Would the translators' work become easier if the manpages were rewritten in some higher-level language than groff? I must admit that I am not at ease with groff sources, and that I use weird hacks when modifying such or such part of a manpage when some feature of cron or crontab is changed. The source in groff format often contains very short lines, where more context would be necessary to grasp the sense. So, please tell me whether it would be useful to rewrite the three manpages in XML format? This would mean writing sensible paragraphs, with lines of seventy or more characters, containing simple text and elements marked by tags like or , which convey more sense than the bare bold/italics directives available in groff. > That's usual, but po4a transforms this in a more friendly format for > us translators. Here is what I understood so far, from the first e-mail you sent me yesterday, and from the enlightenments provided by the second one: Each report chunk is divided in two parts, a list of issues and a context string, which I describe below in some wild meta-language using square brackets: - Man page: [source file] Issue #n: [incorrect format] → [fixed format] ... "[some context, extracted by po4a from the source file]" "..." -- - Please can you confirm or infirm that the interpretation above can be trusted? > I think most of the report boils down that you update the patches by > using .B instead of .I or sometimes .BI This is a particular consequence of a more general guideline, to follow recommendations provided by `man man-pages`. I would feel more at ease if this compliance was ensured by an automated process fed by a source file with high-level syntactic markup. > P.S. And since there is probably little changes in cron nowadays, most > likely few if none further reports from my side… I began to maintain cron two years ago, and lowered the bug report count by approximately one half (regarding reports in bugs.debian.org). Some reports entailed creating new features, and modifying the manuals accordingly. I fear that the fifty remaining bug reports will slowly, but surely involve future changes in man pages, so rewriting them in a high-level language would probably make future changes more consistent. Please can you consider this proposition? I would rewrite an XML source for the manpage crontab.1, and send it; then you run your tools (probably po4a), and send me a feedback to tell me whether I introduced more inconsistencies than the count of fixes. Thank you in advance for your response. Best regards, Georges signature.asc Description: PGP signature
Bug#1065356: Issues in man pages of cron
Dear Helge, thank you for your detailed bug report. Helge Kreutzmann a écrit : > We use several distributions as sources and update regularly (at > least every 2 month). Most changes here are probably specific to Debian; however they will also apply to Debian derivatives. > Secondly we translators see the manpages in the neutral po format, > i.e. converted and harmonized, but not the original source (be it man, > groff, xml or other). So we cannot provide a true patch (where > possible), but only an approximation which you need to convert into > your source format. The original format for Debian's manpages regarding cron is groff. Unfortunately, it is not the easiest format for human translators, as it is probably split in small chunks written to PO files, with little meaning in each of them. > I'm now reporting the errors for your project. If future reports > should use another channel, please let me know. Debian bug reports are a valid channel for me. > (Btw., do you have a working e-mail address of upstream?) The upstream developer, Paul Vixie, had an e-mail address: p...@vix.com However, he does no longer maintain cron, and Debian's cron package comes from a fork, dated "Sun, 1 Dec 1996 16:21:52 -0600". So, for twenty eight years now, all of the development was made by various debian developers, and is structured as a heap of 84 patches (see the file https://salsa.debian.org/debian/cron/-/blob/master/debian/patches/series?ref_type=heads) Regarding the issues listed below, I do not fully understand the syntax. If I consider the very first issue: > > Man page: cron.8 > Issue:B<-L loglevel> → B<-L> I > > "B<-L loglevel>" > -- and take a look at the manpage, which is in groff format, I can find some matching line: 8<--- $ zgrep loglevel /usr/share/man/man8/cron.8.gz .IR loglevel ] .B \-L loglevel 8<--- The last line (in groff) means: write "-L loglevel" with a bold font. This probably has the same meaning as the line "B<-L loglevel>" in the snipped above. So how can I help? can I answer that the line "B<-L loglevel>" is the current valid source for localizations? Now let us consider the next issues: > Man page: crontab.1 > Issue 1: I<-h> → B<-h> > Issue 2: I → B > > "If the I<-h> option is given, I shows a help message and quits " > "immediately." > -- How can I help? Here is the match which I can find: 8<--- zgrep -- -h /usr/share/man/man1/crontab.1.gz crontab [ \-h] .I \-h 8<--- The last line (in groff format) would probably match Issue 1 above, however once again I do not guess how I can help. It would probably be a waste of energy to discuss now all and every issue you sent me. Maybe we can first agree about a method to make the task easier for both of us, and for the many contributors to translation teams. Please can you suggest me one or more techniques which might improve the feedback, regarding the simple examples cited above? The main question is "how can I help?", which can be rephrased as "what kind of answer would you expect?". Best regards, Georges. signature.asc Description: PGP signature
Bug#1061155: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1061155: fixed in cron 3.0pl1-186)
Jonathan H N Chin a écrit : > Since there is an existing "standard" for crontab error reporting > ( check_error() diagnostic + non-zero exit ), I am suggesting > not inventing a new one ( warning message + zero exit ). Looks fine; I shall use check_error() in the future release (3.0pl1-187) Best regards, Georges. signature.asc Description: PGP signature
Bug#1061155: closed by Debian FTP Masters (reply to Georges Khaznadar ) (Bug#1061155: fixed in cron 3.0pl1-186)
Dear Jonathan,
what is the right message to feed back to the user?
Warning ?
+-+
| Warning | ?
+-+
+-+
| +-+ |
| | POOR MISGUIDED, YOU MADE AN ERROR ! | | ?
| +-+ |
+-+
All in all, if the user does not want to read feedback messages, I
ignore how to tell them the proper way.
About the exit status with -n: if one runs `crontab -n`, one expects
somme feedback message, because nothing else is going to happen. The
exit status is just an integer, far less expressive than a warning which
points out some defect. Do you always check "$?" when you get an error
or a warning message?
Jonathan H N Chin a écrit :
> Hi, I just received the new package and tried it. Thanks.
>
> It detects unacceptable MAILTO/MAILFROM, but because unacceptable
> values will cause an error later, issuing only a warning feels
> inadequate to me.
>
> For usability, perhaps it would be better to use check_error().
> Currently, warnings could be missed since the exit status with
> `-n` is still 0.
>
> Something like:
>
> case TRUE:
> /* here MAILTO and MAILFROM are checked */
> if (
> strncmp(envstr, "MAILTO=", 7) == 0 ||
> strncmp(envstr, "MAILFROM=", 9) == 0
> ){
> if (! safe_p("", strstr(envstr,"=")+1)){
> check_error("unsafe mail");
> }
> }
> break;
>
>
>
> The current safe_p() implementation may cause a syslog entry to be
> generated with no associated username when called here, which feels
> slightly wrong to me. It could be confusing to someone auditing logs
> to see spurious "() UNSAFE MAIL" messages when `-n` is used.
>
>
>
> -jonathan
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
Bug#887035: cron: one "easy" way to get cron output
Hello Tomas, with the current version of cron in trixie, - the build was done with debugging active - man cron provides information about the `-x` flag. So, I close the bug report. Please feel free to reopen it when necessary, or send another bug report if something doe not fulfill your needs. Best regards, Georges. On Fri, 22 Jul 2022 15:59:17 +0200 Tomas Pospisek wrote: > @Georges Khaznadar : what do you think about: > > 1. enabling debugging by default? > 2. documenting `-x` ? > > If Debian would enable the "debbugging feature" of its cron by default, > then this would add this overhead in a few places: > > if ( (DebugFlags & (mask) ) ) printf message; > > Since DebugFlags is 0 by default, this will ad an overhead of about two > machine instructions I guess to a few places, which is a neglible > waste/slowdown IMHO. > > With the "debugging feature" enabled Debian's cron will gain the very > nice features: > > a) for the sysadmin to be able to debug what cron is doing and why and > b) use the sysadmin being able to use Debian's cron in docker and kubernetes. > > IMHO a huge gain that costs nothing. signature.asc Description: PGP signature
Bug#1064904: ITP: slm -- school library management
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: slm Version : 0.4 Upstream Contact: Georges Khaznadar * URL : https://salsa.debian.org/georgesk/slm0 * License : GPL-3+ Programming Lang: Python, Javascript Description : school library management SLM stands for "school library management". It provides a web service useful for teams who lend school books to students. Here are some features: . - defining constants for the school, like name, logo, manager's name - creating a catalogue of available books - managing the inventory of books, each one identified by a unique barcode - importing lists of students, with their optional curricula - lending quickly a few books to every student, with the help of a barcode reader - managing the book returns, with the help of a barcode reader - replying to some request, like "whom is this book?", list of students which still owe books, list of students who have no book lended, and so on. - every web page comes with a contextual help I am using SML in my school's cooperative association to lend school books to students, and already packaged extra dependencies which were not part of Debian previously: python3-pylabels, node-html5-qrcode, python3-trml2pdf. This package's source is maintained in Salsa: https://salsa.debian.org/debian/slm
Bug#1064903: ITP: slm -- school library management
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: slm Version : 0.4 Upstream Contact: Georges Khaznadar * URL : https://salsa.debian.org/georgesk/slm0 * License : GPL-3+ Programming Lang: Python, Javascript Description : school library management SLM stands for "school library management". It provides a web service useful for teams who lend school books to students. Here are some features: . - defining constants for the school, like name, logo, manager's name - creating a catalogue of available books - managing the inventory of books, each one identified by a unique barcode - importing lists of students, with their optional curricula - lending quickly a few books to every student, with the help of a barcode reader - managing the book returns, with the help of a barcode reader - replying to some request, like "whom is this book?", list of students which still owe books, list of students who have no book lended, and so on. - every web page comes with a contextual help I am using SML in my school's cooperative association to lend school books to students, and already packaged extra dependencies which were not part of Debian previously: python3-pylabels, node-html5-qrcode, python3-trml2pdf. This package's source is maintained in Salsa: https://salsa.debian.org/debian/slm
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Dirk Hünniger a écrit : > chromium-sandbox [!armel !mips64el !s390x], Done. Best regards, Georges. signature.asc Description: PGP signature
Bug#1064037: uploaded the fixed package to DELAYED+10
Hello, I uploaded xhtml2pdf_0.2.5-3.1_source.changes to delayed+10 today, and the modifications to Salsa's repository. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1064037: xhtml2pdf: the new version of python-reportlab breaks xhtml2pdf/context.py
Source: xhtml2pdf Version: 0.2.5-3 Severity: serious Tags: patch upstream Dear Maintainer, since python-reportlab 4.0.1-1, xhtml2pdf cannot pass automatic tests: see for example, https://ci.debian.net/packages/x/xhtml2pdf/testing/amd64/43022906/ at line 480, from reportlab.platypus.frames import Frame, ShowBoundaryValue E ImportError: cannot import name 'ShowBoundaryValue' from 'reportlab.platypus.frames' (/usr/lib/python3/dist- packages/reportlab/platypus/frames.py) I patched the file xhtml2pdf/context.py to fix this error. Best regards, Georges. -- System Information: Debian Release: trixie/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-25-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Beginning with python3-reporlab version 4.1.0, ShowBoundaryValue is no longer part of reportlab.platypus.frames, but part of reportlab.pdfgen.canvas Index: xhtml2pdf/xhtml2pdf/context.py === --- xhtml2pdf.orig/xhtml2pdf/context.py +++ xhtml2pdf/xhtml2pdf/context.py @@ -15,7 +15,8 @@ from reportlab.lib.pagesizes import A4 from reportlab.lib.styles import ParagraphStyle from reportlab.pdfbase import pdfmetrics from reportlab.pdfbase.ttfonts import TTFont -from reportlab.platypus.frames import Frame, ShowBoundaryValue +from reportlab.platypus.frames import Frame +from reportlab.pdfgen.canvas import ShowBoundaryValue from reportlab.platypus.paraparser import ParaFrag, ps2tt, tt2ps from xhtml2pdf.util import (copy_attrs, getColor, getCoords, getFile, getFrameDimensions, getSize, pisaFileObject,
Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x
Hello Paul, Dirk, Dirk Hünniger a écrit : > https://qa.debian.org/excuses.php?package=mediawiki2latex > says: > > Issues preventing migration: > > * mediawiki2latex/armel has unsatisfiable dependency > * mediawiki2latex/mips64el has unsatisfiable dependency > * mediawiki2latex/s390x has unsatisfiable dependency At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex says that the package could be installed, so its runtime dependencies are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64. I have no precise idea about this misbehavior, unfortunately. However the excuses page tells that the package is 5 days old (needing 5 days), maybe we should wait 24 hours longer ? If the migrations keeps failing, I can make some trivial change and make another source upload. Best regards, Georges. signature.asc Description: PGP signature
Bug#1063862: npm2deb fails when self.json['bin'] is not a list -- [patch provided]
Package: npm2deb
Version: 0.3.0-12
Severity: normal
Tags: patch
Dear Maintainer,
When I try to run:
npm2deb create @babel/parser
the command fails:
...
File "/usr/lib/python3/dist-packages/npm2deb/__init__.py", line 260, in
create_links
orig = _os.path.normpath(self.json['bin'][script])
TypeError: string indices must be integers, not 'str'
The reason of this error is that:
self.json['bin'] == './bin/babel-parser.js'
in this particular case.
Here is a patch which restores the expected behavior:
-8<-
diff --git a/npm2deb/__init__.py b/npm2deb/__init__.py
index ee3f29a..e2974da 100644
--- a/npm2deb/__init__.py
+++ b/npm2deb/__init__.py
@@ -255,9 +255,16 @@ and may not include tests.\n""")
links = []
dest = self.debian_dest
if 'bin' in self.json:
-for script in self.json['bin']:
-orig = _os.path.normpath(self.json['bin'][script])
-links.append("%s/%s usr/bin/%s" % (dest, orig, script))
+if isinstance(self.json['bin'], list):
+for script in self.json['bin']:
+orig = _os.path.normpath(self.json['bin'][script])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
+else:
+script = self.json['bin']
+orig = _os.path.normpath(self.json['bin'])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
if len(links) > 0:
content = '\n'.join(links)
utils.create_debian_file('links', content)
-8<-
Best regards, Georges.
-- System Information:
Debian Release: trixie/sid
APT prefers stable
APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'),
(500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-25-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages npm2deb depends on:
ii devscripts2.23.7
ii node-github-url-from-git 1.5.0+~1.5.1-1
ii npm 9.2.0~ds1-2
ii python3 3.11.6-1
ii python3-apt 2.7.5
ii python3-dateutil 2.8.2-3
npm2deb recommends no packages.
npm2deb suggests no packages.
-- no debconf information
diff --git a/debian/changelog b/debian/changelog
index 75564f7..da54cd4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+npm2deb (0.3.0-12.1) unstable; urgency=medium
+
+ * NMU: fix an issue when self.json['bin'] is not a list.
+
+ -- Georges Khaznadar Tue, 13 Feb 2024 18:57:29 +0100
+
npm2deb (0.3.0-12) unstable; urgency=medium
* Update standards version to 4.6.1, no changes needed.
diff --git a/npm2deb/__init__.py b/npm2deb/__init__.py
index ee3f29a..e2974da 100644
--- a/npm2deb/__init__.py
+++ b/npm2deb/__init__.py
@@ -255,9 +255,16 @@ and may not include tests.\n""")
links = []
dest = self.debian_dest
if 'bin' in self.json:
-for script in self.json['bin']:
-orig = _os.path.normpath(self.json['bin'][script])
-links.append("%s/%s usr/bin/%s" % (dest, orig, script))
+if isinstance(self.json['bin'], list):
+for script in self.json['bin']:
+orig = _os.path.normpath(self.json['bin'][script])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
+else:
+script = self.json['bin']
+orig = _os.path.normpath(self.json['bin'])
+links.append("%s/%s /usr/bin/%s" %
+ (self.name, orig, script))
if len(links) > 0:
content = '\n'.join(links)
utils.create_debian_file('links', content)
Bug#1063855: RM: jsdoc-toolkit -- ROM; jsdoc-toolkit is obsolete, superseded by node-jsdoc2
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: jsdoc-tool...@packages.debian.org Control: affects -1 + src:jsdoc-toolkit Please remove jsdoc-toolkit from unstable and testing. I used to maintain jsdoc-toolkit, as a build-dependency of the package jsxgraph, which I will keep maintaining. jsdoc-toolkit was a javascript source interpreted by a java-based engine. Now, it is superseded by the package node- jsdoc2 which I uploaded to Debian, which is quite the same javascript source, interpreted by nodeJs. So, jsdoc-toolkit is no longer useful for current developers. Best regards, Georges.
Bug#1063853: RM: wims-moodle -- ROM; this package works only wil moodle version 2
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: wims-moo...@packages.debian.org Control: affects -1 + src:wims-moodle Hello, please remove the package wims-moodle, which works only with Moodle version 2. So, it may have some interest for people using oldstable or oldoldstable, but it is definetely useless for people using stable, testing or unstable. Moodle 2.9 was released in year 2015, and does not support PHP7.0 Moodle 3.1 (LTS) was released in year 2016. Now, the features of wims-moodle can be provided by the current package wims- lti which I maintain. Best regards, Georges.
Bug#1062214: ITP: node-jsdoc2 -- automatic documentation generation tool for JavaScrip
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-CC: debian-de...@lists.debian.org * Package name: node-jsdoc2 Version : 2.4.0 Upstream Author : Michael Mathews * URL : http://wronex.github.com/node-jsdoc2 * License : Expat Programming Lang: JavaScript Description : FIX_ME write the Debian package description node-jsdoc2 is a port of JSDoc2 Toolkit that runs on Node.js. . Node.js is an event-based server-side JavaScript engine. . Using this tool you can automatically turn JavaDoc-like comments in your JavaScript source code into published output files, such as HTML or XML. node-jsdoc2 is a dependency for package jsxgraph which I maintain. So far, I twisted the build of jsxgraph to use the deprecated package jsdoc-toolkit, but this does no longer work. node-jsdoc2 is described as the current evolution of jsdoc-toolkit. This package will be co-maintained as I am member of the Debian JavaScript maintainers. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1059828: colourised crontab -l output is unreadable
Hello Stéphane, I installed the package bat (debian testing). - the command bat had been renamed to batcat to prevent a name clash with another package - crontab is not among the supported languages : $ batcat --list-languages| grep -i cron ==> Is there some mean to restore the feature of bat, regarding crontabs? Can users easily customize their color preferences with batcat? Best regards, Georges. Stéphane Blondon a écrit : > Hello everyone, > > I understand the goal and the global strategy. It could be done with > the `bat` package too. > Based on the previous proposal, I show it below the Georges's steps. > > Le jeu. 18 janv. 2024 à 09:29, Georges Khaznadar > a écrit : > > [...] - modify the manpage crontab.1 to explain how to colourise the output > > of > > `crontab -l`; typically by issuing `crontab -l | spc -t crontab`, > > and explain shortly how one can customize at will the file which defines > > the coulourisation. > > - let the package cron install one file for supercat, > > /etc/supercat/spcrc-crontab; I attach such a file to this e-mail, so > > Stéphane can copy it as ".spcrc-crontab", in order to see how the > > output of `crontab -l | spc -t crontab` looks like. > > - add a recommendation from package cron to package supercat. > > The `bat` package highlights several languages, including crontab. So > it would be simpler because there is no need to add a specific file: > $ crontab -l | bat --language Crontab > > `-l` is usable instead of `--language`. > > For my usage, I will set an alias: > alias crontabl='crontab -l | bat --language Crontab' > > > I'm not sure if adding a `recommends: supercat` is a good idea. > Perhaps adding the ways to highlight crontab in manpage is enough ? > > -- > Stéphane -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost
Hello, Thank you for your bug report. I shall lower the severity of your bug report, since it "causes non-serious data loss" a...@example.org would be parsed as a valid e-mail address if one uses regexp matching. What improvement would you suggest? Should "crontab -e" send an e-mail to recipients stated by MAILTO and wait for a reply? Best regards, Georges. On Fri, 19 Jan 2024 18:06:52 + Jonathan H N Chin wrote: > Package: cron > Version: 3.0pl1-182 > Severity: grave > Justification: causes non-serious data loss > > Dear Maintainer, > > >* What led up to the situation? > > 1. A user ran "crontab -e" > > 2. He added the line (note the space): > > MAILTO=a...@example.org, b...@example.com > > > 3. He saved and exited > > 4. No errors were reported to the user. > > >* What was the outcome of this action? > > Subsequently, jobs ran but output was discarded. > > /var/log/syslog contains "UNSAFE MAIL" messages which the user cannot see. > > >* What outcome did you expect instead? > > At step 4, crontab should have reported an error to the user > and not applied the update. > > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-91-generic (SMP w/1 CPU thread) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages cron depends on: > ii cron-daemon-common 3.0pl1-182 > ii init-system-helpers 1.66 > ii libc62.37-13 > ii libpam-runtime 1.5.2-9.1 > ii libpam0g 1.5.2-9.1+b1 > ii libselinux1 3.5-1+b2 > ii sensible-utils 0.0.20 > > Versions of packages cron recommends: > ii exim4-daemon-heavy [mail-transport-agent] 4.97-4+b1 > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1060897: Bug #1060897: furo: documentation generated with Debian's furo package doesn't work standalone
Hi, I patched the file src/furo/__init__.py, to enforce the attribute type="module" when the script furo.js is embedded in a web page. Then the syntax import * as Gumshoe from "./gumshoe-patched.js" is accepted. I hope that the release 2023.09.10+dfsg-4 can fix the bug definitely. Best regards, Georges. On Fri, 19 Jan 2024 14:16:31 +0100 Raphael Hertzog wrote: > Control: reopen -1 > > On Fri, 19 Jan 2024, Debian Bug Tracking System wrote: > > furo (2023.09.10+dfsg-3) unstable; urgency=medium > > . > >* included the code from normalize.css into furo.css instead of > > the include directive. Closes: #1060897 > > Thanks for this fix! Unfortunately, this only solves one of the two > problems that I reported in #1060897 (I know that I should have opened two > bugs...). > > The other one was about the javascript in furo.js failing to execute (at > least in Firefox in unstable) with this error message: > > Uncaught SyntaxError: import declarations may only appear at top level of a > module > > As I said in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060897#10 > that import statement is not present in a regular furo.js as built > by the upstream build system because the file is post-processed and > minified. Ex here: > https://pradyunsg.me/furo/_static/scripts/furo.js > > So I assume we need to post-process the file in some similar way to get it > to work or tweak the way we import the code to allow the import statement > to work but I'm not a big fan of diverting too much from upstream and we > are doing this a lot here (but it's often unavoidable with all packages > relying on the node ecosystem in some way). :-( > > Cheers, > -- > ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ > ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1060897: standalone is permitted, when the local web server is in use
Hello, I deleted the first line in the file furo.css, which contained « @import url(/javascript/normalize.css/normalize.css); » and replaced it by the contents of the file normalize.css The release 2023.09.10+dfsg-3 might fix the bug, please feel free to reopen it, if it doesn't. Best regards, Georges. On Fri, 19 Jan 2024 09:46:57 +0100 Raphael Hertzog wrote: > Hi, > > On Thu, 18 Jan 2024, Georges Khaznadar wrote: > > On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog > > wrote: > > > [...] reported here and that you can see here: > > > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html > > > > when I browse this URL with the debugger's console active, I see that: > > > > The resource from > > “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” > > was blocked due to MIME type (“text/html”) mismatch > > (X-Content-Type-Options: nosniff). > > > > Probably, it the webserver is configured to serve normalize.css as MIME > > type "text/css", the issue might be fixed. > > No, this is unrelated. The URL you list is just not valid. This domain > is managed by GitLab Pages and anything generated by the CI must > be self-contained in > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/ > > The fact that you have hardcoded an absolute link to > "/javascript/normalize.css/normalize.css" (which might work on a default > installation of a Debian server) means the resource is now looked up > outside of its artifact directory, and there's just nothing there > that can understand the purpose of its URL. You could have received > an error 404 just as well but you got something else presumably because > GitLab Pages has a number of hardening features to avoid malicious > behaviour. > > Cheers, > -- > ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ > ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1060897: standalone is permitted, when the local web server is in use
On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog wrote: > [...] reported here and that you can see here: > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html when I browse this URL with the debugger's console active, I see that: The resource from “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff). Probably, it the webserver is configured to serve normalize.css as MIME type "text/css", the issue might be fixed. Best regards, Georges. signature.asc Description: PGP signature
Bug#903553: secure-delete: srm -r: fails to rename dir before truncating it.
Hello Manolo, I am the new maintainer of the package secure-delete for a few months, and this bu report is more than 3 years old. Please can you tell me what srm prints when called with the -v switch? (verbose mode). By the way, can you also provide me a tarball of a minimal filesystem which would trigger the bug you reported? Thank you in advance. Best regards, Georges. On Wed, 11 Jul 2018 12:00:18 +0200 =?utf-8?q?Manolo_D=C3=ADaz?= wrote: > Package: secure-delete > Version: 3.1-6 > Severity: normal > > > Dear Maintainer, > > After running 'srm -r directory' the following warning is shown: > Warning: Couldn't find a free filename for directory! > > Tested with ext4 and tmpfs filesystems only. > > Best Regards, > Manolo Díaz > > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.17.5 (SMP w/2 CPU cores) > Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), > LANGUAGE=es_ES.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages secure-delete depends on: > ii libc6 2.27-3 > > secure-delete recommends no packages. > > secure-delete suggests no packages. > > -- no debconf information -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#550236: Patch ineffective
Hello, I am the new maintainer for secure-delete, and this bug report is 8 years old. Please, can you tell me what is the output of srm with the -v switch enabled (so in verbose mode), when it fails with 'Too many open files'? And by the way, can you send me a tarball with some minimal example able to trigger this bug? Thank you in advance, Georges. On Wed, 25 Jun 2014 11:40:37 +0200 Martin Erik Werner wrote: > The patch does not appear to solve this issue, which is still present in > version > 3.1-5. > > -- > Martin Erik Werner > > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#849837: /usr/bin/sfill: malloc assertion failure
Dear Rob, I am the new maintainer of the package secure-delete for a few months. Your bugreport is now eight years old. Unfortunately, it misses some information: please can you tell me which are the filesystems on which sfill repeatably fails? or send me a minimal example, like a tarball to show how sfill's failure could be triggered? By the way: have you got similar failures with filesystems which you are using today? Thank you in advance for your response. Best regards, Georges. Rob Leslie a écrit : > Package: secure-delete > Version: 3.1-5 > Severity: important > File: /usr/bin/sfill > > Dear Maintainer, > > I have some filesystems on which sfill repeatably fails with: > > % sfill -fllz $dir > sfill: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr) (((char > *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, > fd && old_size == 0) || ((unsigned long) (old_size) >= (unsigned > long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2 * > (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) && ((old_top)->size > & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed. > > After this failure, the root directory of the filesystem is littered with > numerous empty files. > > > -- System Information: > Debian Release: 7.11 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'oldstable') > Architecture: i386 (x86_64) > > Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages secure-delete depends on: > ii libc6 2.13-38+deb7u11 > > secure-delete recommends no packages. > > secure-delete suggests no packages. > > -- no debconf information > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1060897: standalone is permitted, when the local web server is in use
Hello Raphaël, "normalize.css" can be found at the URL "/javascript/normalize.css/normalize.css" when one accesses the html files through a webserver, rather from the raw file system. For example, when I install the package python-sympy-doc, which depends on furo(1), the URL file:///usr/share/doc/python-sympy-doc/html/index.html misses furo's dark/light theme switcher, but the URL http://localhost/doc/python-sympy-doc/html/index.html does not miss it, as my local webserver (apache2) serves by default /usr/share/doc under http://localhost/doc and /usr/share/javascript under http://localhost/javascript. /usr/share/doc/* and /usr/share/javascript/* are usually not served worldwide, but one can write a configuration to allow some exceptions. Would you like to enable documents generated with furo to be usable even when accessed under a file:// scheme? Best regards, Georges. Notes: (1) I made an ITP for furo and packaged it for Debian, primarily because I am maintaining the package sympy, and that once upon a time, it began build-depending on furo. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1059828: colourised crontab -l output is unreadable
Dear Craig, dear Stéphane,
accessibility is an important topic.
bug reports #813614 and #1059828 (the present one) can be fixed either
by adding yet another feature to crontab, or by following the Unix way:
make small excellent commands, each one in charge of a complementary
action, and let them interact.
In my opinion, Craig's proposition to use supercat is the right method
to fix both bug reports; so, I propose to:
- remove the file
debian/patches/features/Coloring_the_ouput_of_crontab_l.patch, which
will restore the previous (non colourised) output of `crontab -l`
- modify the manpage crontab.1 to explain how to colourise the output of
`crontab -l`; typically by issuing `crontab -l | spc -t crontab`,
and explain shortly how one can customize at will the file which defines
the coulourisation.
- let the package cron install one file for supercat,
/etc/supercat/spcrc-crontab; I attach such a file to this e-mail, so
Stéphane can copy it as ".spcrc-crontab", in order to see how the
output of `crontab -l | spc -t crontab` looks like.
- add a recommendation from package cron to package supercat.
Thank you in advance for your opinions about it.
@Craig: if you are keen to provide an accessible version of the file
spcrc-crontab, for example made only with high contrast, colourless,
direct/reverse video, normal/bold variants, I would welcome your
contribution and intergrate it, for example as file spcrc-crontabHC, so
one can issue `crontab -l | spc -t crontabHC` to view a crontab with
highly contrasted highlighted elements.
Best regards, Georges.
Craig Sanders a écrit :
> Package: cron
> Version: 3.0pl1-182
>
> Please don't force colourised tty output by default. It makes the output
> unreadable.
>
> Forcing one person's colour preferences on everyone is a vision impairment /
> accessibility problem for everyone who doesn't have the same visual capability
> as that one individual. Some of us have to very carefully adjust the colors
> (and fonts and sizes etc) used by our terminals so we can read the text -
> and it is very frustrating to have some program over-ride our settings just
> because one person happens to like blue on yellow text, or prefers that
> commented lines be highlighted.
>
> It's not even necessary for crontab to have special-case code just to
> colourise comments - there are several tools for colourising program output
> and other text, including colorize, highlight, supercat and others already
> packaged for Debian. If some people want garish bling in their terminals,
> they can use the tools that provide that. That's what they're for.
>
> At the very least, there should be a way to disable it.
>
> Or better yet, an option to *enable* colorised output (say, -c or
> --colour/--color) for those who want it. Or an environment variable
> e.g. 'CRONTAB_COLOR=Y' or (borrowing from GREP_COLOR and LS_COLORS etc)
> CRONTAB_COLOR='43;34' to both enable and configure the colourisation.
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
# this file is to colorize crontabs ==
#1 2 3 4 5
#2345678901234567890123456789012345678901234567890123456789
# HTML COLOR COL A N T STRING or REGULAR EXPRESSION
### # # #
#Where:
# HTML COLOR - Standard HTML Color name for HTML output
# COL- Console color name from the list
# red, yel, cya, grn, mag, blk, whi, blu
# A - Attribute from the list
# ' ' : normal
# 'b' : bold
# 'u' : underline
# 'r' : reverse video
# 'k' : blink
# N - number of matches
# ' ' : all
# '0' : all
# '1' - '9' : number of matches
# T - type of matching to perform
# 'c' : characters
# 's' : string
# 'r' : regex - case sensitive
# 'R' : regex - case insensitive
# 't' : regex with Unix time conversion
# ' ' : default ('r' regex)
#1 2 3 4 5
#2345678901234567890123456789012345678901234567890123456789
# HTML COLOR COL A N T STRING or REGULAR EXPRESSION
### # # #
# default is black
Blackblk (.*)
#dom is blue + bold
Blue blu b 5 \s+(\S+)
# month is green + bold
Greengrn b 4 \s+(\S+)
# dow is green + reverse video
Greengrn r 3 \s+(\S+)
#hour is red +
Bug#742337: t1lib is no longer part of Debian
... and packages expeyes, grace no longer depends on t1lib, so I close this bug report. Feel free to reopen it if necessary. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1059829: Thank you
Hello, Javascript/Npm are not my cup of tea; so, please receive many thanks about the help you provided to my poor packaging efforts. If node-html5-qrcode happens to be dfsg-free, which should be the right umbrella to host it on salsa.d.o? https://salsa.debian.org/js-team or https://salsa.debian.org/georgesk ? I saw that you managed to let salsa's automaton pass 53 of the upstream tests, and I would like to learn such magics. Please have you some useful links about them? Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1060919: RM: gtkextra -- ROM; libgtkextra-3.0 is used by no Debian package now, upstream no longer maintained
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: gtkex...@packages.debian.org Control: affects -1 + src:gtkextra Hello, about bug #967851, I can add that now the current release of gpsim, which was among the least packages to depend on libgtkextra-3.0, depends no longer on it. So, the package gtkextra can be safely removed from unstable, in addition to the AUTORM which is scheduled shortly. Best regards,Georges.
Bug#1060458: uploaded release 804.036+dfsg1-2
Hi, I just uploaded a new release, with your changes included. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#946382: This bug report seems useless in my opinion
Hello Dan,
I patched crontab.5 to take your advice in count.
Just hoping that no other purist would notify me that lining up columns
can be done with spaces rather that with zeroes.
I uploaded release 3.0pl1-182 right now.
Best regards, Georges.
Dan Jacobson a écrit :
> >>>>> "GK" == Georges Khaznadar writes:
> GK> Hello Dan,
>
> GK> I would like to get more information about your intent, for this bug
> GK> report.
>
> Looking at the crontab(5) man page,
> everything lines up very pretty:
>
>
>17 * * * * root cd / && run-parts --report /etc/cron.hourly
>25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.daily )
>47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.weekly )
>52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.monthly )
>
> But that is because the author picked 6 hours for each.
>
> Let's see what would happen otherwise:
>17 * * * * root cd / && run-parts --report /etc/cron.hourly
>25 16 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.daily )
>47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.weekly )
>52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.monthly )
> Oh darn, that looks ugly.
>
> The question that crosses users minds is: "Can I rewrite it
>17 * * * * root cd / && run-parts --report /etc/cron.hourly
>25 16 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.daily )
>47 06 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.weekly )
>52 06 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.monthly )
> or will that be taken as octal (even if octal 6 is just 6), or illegal?
> Please don't force me to test to find the answer."
>
> I'm just saying the man page needs to state clearly what will happen.
>
> Sure, one could just add spaces instead of zeros to make the columns
> line up. But that would just be avoiding the issue.
>
> GK> Should leading zeroes be supported for the sake of making columns line
> GK> up, or should leading zeroes be used to introduce octal constants, in
> GK> your opinion?
>
> Nobody wants octal. I'm just trying to make columns line up.
>
> GK> As far as I understand the code of the file entry.c, numbers are parsed
> GK> by the function atoi:
> GK> -8<- file entry.c's excerpt --
> GK> if (all_digits) {
> GK> *numptr = atoi(temp);
> GK> return ch;
> GK> }
> GK> -8<---
>
> GK> ... which means that numbers prefixed by zeroes are considered as
> GK> decimal.
>
> OK that's great. Please mention so on crontab(5). Thanks.
>
> In fact perhaps add an example saying one can use spaces and zeros to make the
> columns line up:
>
>25 16 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.daily )
>47 06 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.weekly )
>52 4 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts
> --report /etc/cron.monthly )
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
Bug#1059336: ITP: node-html5-qrcode -- qr-code and bar-code scanning library for the web
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: node-html5-qrcode Version : 2.3.8 Upstream Contact: https://github.com/mebjas/html5-qrcode/issues * URL : https://github.com/mebjas/html5-qrcode * License : Apache-2.0, GPL2 Programming Lang: nodejs, typescript Description : qr-code and bar-code scanning library for the web Use this lightweight library to easily / quickly integrate QR code, bar code, and other common code scanning capabilities to your web application. So far, debian is missing a package to scan qrcodes and barcodes from a web page. I intend to maintain this package as a dependency for a future package SLM, school library management, which I am developping actively. This latter package allows students to find and recognize books inside a library by scanning a few qr-codes. The package node-html5-qrcode is uploaded to https://salsa.debian.org/georgesk/node-html5-qrcode.git
Bug#1059328: ITP: trml2pdf -- implementation of RML (Report Markup Language) from ReportLab
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: trml2pdf Version : 0.6 Upstream Contact: Roman Lyashov * URL : https://github.com/romanlv/trml2pdf * License : LGPL2+ Programming Lang: Python3 Description : translation of RML (Report Markup Language) from ReportLab, to PDF trml2pdf is a translator which converts high level XML markup into PDF documents. RML (Report Markup Language) describes the precise layout of a printed document, and trml2pdf converts this to a finished document in one step. . This package installs the library for Python 3. trml2pdf enhances the package python3-reportlab, which I maintain. It is uploaded at https://salsa.debian.org/georgesk/trml2pdf.git
Bug#1059321: ITP: pylabels -- python library for creating PDFs to print sheets of labels
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: pylabels Version : 1.2.1 Upstream Contact: Blair Bonnett <https://github.com/bcbnz> * URL : https://pypi.org/project/pylabels/ * License : GPL-3+ Programming Lang: Python3 Description : python library for creating PDFs to print sheets of labels pylabels uses the ReportLab PDF toolkit to produce the PDF. . Basically, the user creates a set of specifications of the label sizes etc, writes a callback function which does the actual drawing, and gives these two items to a Sheet object. Items are then added to the sheet using the add_label() method (or add_labels() to add all items from an iterable). Pylabel enhances python3-reportlab since it makes easier for an author to design label sheets. I already maintain the package python-reportlab, and I use often features from pylabels. This package is uploaded to https://salsa.debian.org/georgesk/pylabels.git
Bug#956953: cron: add cron jobs to systemd scope cgroups
Hello Paul, Paul Wise a écrit : > On Sun, 2023-12-17 at 16:28 +0100, Georges Khaznadar wrote: > > > So maybe prepending "systemd-run --scope --user" would do the trick, > > wouldn't it? > > I think that would work yes. Please set an appropriate name too though. Can I assume that you are talking about the switch --description= ? As stated in the man page, "If not specified, the command itself will be used as a description." By the way, if I run `systemd-run --scope --user --description='some weird s|ri\ng' some\ command`, is systemd-run self-protected, does it sanitize such an input? If not, we should first ask systemd-run's authors to improve it, don't we? I would propose to use the command's name (without arguments), appended with an underscore and the pid of the forked grandchild process managed by cron as a description. So one can take a look at /proc/ to get more information. What do you think about it? Best regards, Georges. signature.asc Description: PGP signature
Bug#956953: cron: add cron jobs to systemd scope cgroups
Hello Paul, Paul Wise a écrit : > > I presume that one way to implement your wished feature might be to > > modify beforehand the string e->cmd, in order to insert something as > > "systemd-run --scope" at the begin... > > I note that this requires user authentication even when run as a user > so presumably it would not work in cron itself. So maybe prepending "systemd-run --scope --user" would do the trick, wouldn't it? Best regards, Georges. signature.asc Description: PGP signature
Bug#956953: cron: add cron jobs to systemd scope cgroups
Hello Paul, as I am not experienced with cgroups, I would appreciate some help if you have got time to offer it. Here is the code authored by Vixie to launch a cron job, as a grandchild of cron's main process: -8<--- execle(shell, shell, "-c", e->cmd, (char *)0, e->envp); -8<--- I presume that one way to implement your wished feature might be to modify beforehand the string e->cmd, in order to insert something as "systemd-run --scope" at the begin... What do you think about it ? Thank you in advance for any hint. Best regards, Georges. Paul Wise a écrit : > Package: cron > Severity: wishlist > > It would be nice to have cron add the jobs it creates to systemd scope > cgroups. The groups could be named according to the source of the job > and the content of the cron job with unsafe characters replaced. > > crontab-root-17-*-*-*-*-cd-run-parts-report-etc-cron-hourly.scope > user-root-0-0-*-*-*-mysqlbackup.scope > user-pabs-0-7-*-*-*-sm-go-to-work.scope > > This would make it easier to see at a glance which processes belong to > which cron job, right now the only way to do this is to set environment > variables distinguishing the cron jobs and then grep the environment > variables of process in the cron.service group. > > $ < /sys/fs/cgroup/systemd/system.slice/cron.service/cgroup.procs xargs > -d'\n' -n1 -I^ grep -lz PABS_CRON_JOB= /proc/^/environ 2> /dev/null | grep -o > '[0-9]\+' > 20586 > 20587 > 20589 > 20594 > 20600 > $ systemctl status cron.service > ● cron.service - Regular background program processing daemon > Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor > preset: enabled) > Active: active (running) since Fri 2020-04-17 10:40:25 AWST; 4h 53min ago >Docs: man:cron(8) >Main PID: 907 (cron) > Tasks: 11 (limit: 14310) > Memory: 84.1M > CGroup: /system.slice/cron.service > ├─ 907 /usr/sbin/cron -f > ├─20586 dbus-launch --autolaunch > 6b1b8c9f8021eeb6f685a77d48917a8a --binary-syntax --close-stderr > ├─20587 /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 > --print-address 7 --session > ├─20589 /usr/libexec/at-spi-bus-launcher > ├─20594 /usr/bin/dbus-daemon > --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork > --print-address 3 > └─20600 /usr/libexec/at-spi2-registryd --use-gnome-session > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#946382: This bug report seems useless in my opinion
Hello Dan,
I would like to get more information about your intent, for this bug
report.
Should leading zeroes be supported for the sake of making columns line
up, or should leading zeroes be used to introduce octal constants, in
your opinion?
As far as I understand the code of the file entry.c, numbers are parsed
by the function atoi:
-8<- file entry.c's excerpt --
if (all_digits) {
*numptr = atoi(temp);
return ch;
}
-8<---
... which means that numbers prefixed by zeroes are considered as
decimal.
My opinion is that such an issue would not bother many people: numeric
entries stand for minutes, hours, days, day of month, mont, day of week.
So nobody need to write three digits to express such numbers.
In octal, 00 to 07 would mean the same as in decimal, and 08, 09 would
make no sense; so if one is in a doubt, one can give a try with 08 or 09
and see whether cron complains ;)
I am hereby closing this bug report. Feel free to reopen it if you want
to add something more about it.
Best regards, Georges.
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
Bug#1054142: cron-daemon-common: Cron now depends on systemd.
Hello again, Jerry, one month has passed since the moreinfo query, so I close the bug report as announced. Please reopen this bug report if you have given a try with bullseye's or bookworm's releases of the package. Best regards, Georges. Georges Khaznadar a écrit : > Hello again, Jerry, > > > Jerry Kaisler a écrit : > >* What led up to the situation? cron should NOT depend on systemd. > >* What exactly did you do (or not do) that was effective (or > > ineffective)? tried to install a base system without systemd. > >* What was the outcome of this action? It failed because systemd was not > > installed. > >* What outcome did you expect instead? the ability to install cron after > > stripping out the hot steaming pile that is systemd. > > Your four lines of information give exactly the same information than > your bug report's title. > > Please can you elaborate further? > I tried to undestand why there was a dependency on systemd. > > cron depends on package init-system-helpers; when I run > `apt-cache showpkg init-system-helpers`, I can see that an old version > of init-system-helpers (version 1.56+nmu1) is depending on systemd. > Other versions do no depend on it. > > Did you try to install a base system based on buster? This one is > currently old-old-stable. Please give a try with bullseye or bookworm. > > As the dependency on systemd does not exist in distributions oldstable > and stable, I shall close this bug report shortly. > > Best regards, Georges. > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1057201: ITP: rl-renderpm -- contains the ReportLab accelerator module
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rl-renderpm Version : 4.0.3 Upstream Contact: the ReportLab team * URL : https://www.reportlab.org/ * License : LGPL,MIT/X Programming Lang: C, Python3 Description : contains the ReportLab accelerator module rl_renderPM is a package containing the ReportLab accelerator module _renderPM which can be used to speedup the reportlab.graphics.renderPM functions. . The python bitmap render module reportlab.graphics.renderPM can either use rlPyCairo, pycairo and freetype-py or rl_renderPM + built in freetype libraries. . The choice is made by overriding the reportlab.rl_settings module value _renderPMBackend using one of the settings files reportlab/local_reportlab_settings.py, reportlab_settings.py or ~/.reportlab_settings, which are searched for in that order. . The default value of _renderPMBackend is 'rlPyCairo', but it can be set to '_renderPM' to use this extension which is based on an older library libart_lgpl. . Deprecation notice: --- . As from version 4.0, the package python-reportlab removes the renderPM extension which lets one create bitmap versions of complex graphics. It now uses other python libraries which wrap up freetype, the font rendering engine, so that one doesn't need to worry about linking to it. Under the hood it uses PyCairo as a renderer by default (rather than the no-longer-supported libart), and freetype-py to render text glyphs. See more at: https://docs.reportlab.com/releases/notes/whats-new-40/ This package makes it easier for people who were using python-reportlab << 4.0 to let their programs upgrade to python-reportlab >= 4.0 without modifying the configuration. It is maitained at https://salsa.debian.org/python- team/packages/rl-renderpm and I intend to keep it up to date (I am already uploader for the package python-reportlab)
Bug#1057193: ITP: rl-accel -- accelerator module for the ReportLab Toolkit
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rl-accel Version : 0.9.0 Upstream Contact: the ReportLab team N * URL : https://www.reporlab.org/ * License : MIT/X Programming Lang: C, Python3 Description : accelerator module for the ReportLab Toolkit This is an accelerator module for the ReportLab Toolkit Open Source Python library for generating PDFs and graphics. . Since python-reportlab 4.0, the rl_accel C module which accelerates some functions is generally not necessary any more; Python is a lot faster than it was 20 years ago. You can still use it if you wish. As from version 4.0, the ReportLab Toolkit considers C modules as deprecated, this package can be used optionally to ensure a smooth transition for packages which depended on python3-reporlab << 4.0 The package is maintained at https://salsa.debian.org/debian/rl-accel and I intend to keep it up to date.
Bug#1055355: RFA: cbor2 -- Concise Binary Object Representation for Python
Hello Bastian, thank you for the fine work! I would like to adopt your package. Best regards, Georges Bastian Germann a écrit : > Package: wnpp > > I do not use cbor2 anymore. > Please consider adopting it if you have the time and skills to maintain it. > It is a low-maintenance package with seldomly release upstream versions. > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1054142: cron-daemon-common: Cron now depends on systemd.
Hello again, Jerry, Jerry Kaisler a écrit : >* What led up to the situation? cron should NOT depend on systemd. >* What exactly did you do (or not do) that was effective (or > ineffective)? tried to install a base system without systemd. >* What was the outcome of this action? It failed because systemd was not > installed. >* What outcome did you expect instead? the ability to install cron after > stripping out the hot steaming pile that is systemd. Your four lines of information give exactly the same information than your bug report's title. Please can you elaborate further? I tried to undestand why there was a dependency on systemd. cron depends on package init-system-helpers; when I run `apt-cache showpkg init-system-helpers`, I can see that an old version of init-system-helpers (version 1.56+nmu1) is depending on systemd. Other versions do no depend on it. Did you try to install a base system based on buster? This one is currently old-old-stable. Please give a try with bullseye or bookworm. As the dependency on systemd does not exist in distributions oldstable and stable, I shall close this bug report shortly. Best regards, Georges. signature.asc Description: PGP signature
Bug#1054142: cron-daemon-common: Cron now depends on systemd.
Control: tags 1054142 + moreinfo Dear Jerry, please can you elaborate a little more about bug #1054142? So far the only useful information is the title of the bug report. Please can you check whether the file /etc/init.d/cron does exist in your computer? It should contain the line 8<--- # Default-Start: 2 3 4 5 8<--- So, if your system is ruled by SYSV Init, I suppose that the file /etc/init.d/cron is symlinked to the directories /etc/rc2.d, /etc/rc3.d, /etc/rc3.d and /etc/rc5.d; do you find those symlinks? Thank you for that additional information about your system. Best regards, Georges. Jerry Kaisler a écrit : > Package: cron-daemon-common > Severity: important > X-Debbugs-Cc: bugrep...@ntlhelp.net > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? cron should NOT depend on systemd. >* What exactly did you do (or not do) that was effective (or > ineffective)? tried to install a base system without systemd. >* What was the outcome of this action? It failed because systemd was not > installed. >* What outcome did you expect instead? the ability to install cron after > stripping out the hot steaming pile that is systemd. > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: bookworm/sid > APT prefers jammy-updates > APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, > 'jammy'), (100, 'jammy-backports') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.5.4-76060504-generic (SMP w/20 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1053911: I close this bug report
Hello, X-Cron-Env headers can be useful, don't they? It those headers are annoying you, please consider using procmail. I suppose that something like the following, in procmail's rc file, sould do the job accordingly to your taste: part of the file .procmailrc - :0: *^From: Cron Daemon.* | sed 's/X-Cron-Env.*//' --- You can also tune your e-mail client to hide "X-Cron-Env" headers by default. For example I'm using mutt, which does not show those headers by default. Indeed, mutt provides a keyboard shortcut to toggle all headers' visibility, so I can look at those headers at will. I close this bug report now, please free to reopen it if you consider writing the documentation for cron manual's page, to explain cron's new feature to everybody. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1053810: RM: please remove cron 4.0.1-1 from experimental /experimental -- ROM; cron 4.0.1 was made from cron 3.0pl1 (used in debian stable..unstable) by applying all debian patches, changing any
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove This strategy was not the best, one can easier use 'gbp pq import/export' to work with git commits equivalent to debian patches. So the package cron 3.0pl1-175 can still be maintained with its big patch heap, while taking benefit of git's commit mechanism with a fine granularity. Thanks to Gioele Barabucci, who highligted this possibility (https://lists.debian.org/debian-devel/2023/10/msg00051.html) So, please remove cron 4.0.1 from experimental Thank you in advance.
Bug#1036437: please provide a simple example to reproduce the bug
Hello Alexis, Alexis Murzeau a écrit : > [...] > That error can be fixed by changing the first line of furo.js > from this: > `import Gumshoe from "./gumshoe-patched.js";` > > to this: > `import * as Gumshoe from "./gumshoe-patched.js";` "import * as Gumshoe" looks out like a weird fix. It assumes that gumshoe-patched.js has only one importable item doesn't it? > As a side note (as you are the uploader of python-sumpy-doc, you might be > interested), I found that the version of python-sumpy-doc in testing and > unstable is missing many files in the html directory: [...] Thank you for pointing this mess! It was due to the use of intersphinx inventories, which cannot be downloaded from Internet during an official Debian build (accessing the Internet is not possible when a package is built in Debian's build farm). I could inject the inventory files, so they are now local to the file tree during the build, and python-sympy-doc provides HTML contents again. I added a short script to add `type="module"` when necessary in HTML files. Best regards, Georges. signature.asc Description: PGP signature
Bug#1036437: please provide a simple example to reproduce the bug
Dear Alexis, the bug about "import Gumshoe from "./gumshoe-patched.js";" is not due to furo: it is due to the package python-sympy-doc. When I modify the file /usr/share/doc/python-sympy-doc/html/index.html, and replace by then, Firefox accepts to import Gumshoe seamlessly. By the way, the file python-sympy-doc also misses a file version.json; this file should be accessed properly only when one opens the file via a http: service, like in: firefox http://localhost/doc/python-sympy-doc/html/index.html Please can you check whether the bug you reported still exists when furo.js is invoked with the type "module"? Please be kind enough to send me another way to reproduce the bug you saw, taking in account that is the right way to use furo.js. Best regards. Georges Alexis Murzeau a écrit : > On 31/05/2023 16:43, georgesk wrote: > > Dear Alexis, > > > > I packaged furo for debian in order to be able to keep maintaining the > > package sympy, which depends on it. > > > > However sympy's documentation is rather big. Creating a minimal sphinx > > tree with sphinx-quickstart is not enough to trigger the bug which you > > are reporting. > > > > Please can you share a minimal example which would trigger this bug, so > > I can include it in furo package's test scripts, and prevent future > > regressions after this bug's fix? > > > > Thank you in advance. Georges. > > > > > Hi, > > You can reproduce it by: > - Installing python3-sympy-doc package > - Open firefox and browse to > file:///usr/share/doc/python-sympy-doc/html/index.html > - Check the Firefox' console, it will show "Uncaught SyntaxError: import > declarations may only appear at top level of a module" > for furo.js > - furo.js contains "import Gumshoe from "./gumshoe-patched.js";" line which > means it was not minified (which is what upstream does). > > The impact is just that dark/light theme and search bar won't work. > > I've checked if this would be possible to do the minification, but that seems > to require many node packages and not all of them > are available or up to date in Debian. > > So maybe that's too much work to just get dark/light theme and search bar... > (most of the theme, mostly css, is still working fine anyway) > > -- > Alexis Murzeau > PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F| > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#262224: syslog-ng: set PATH in startscript
Hello, I adopted the cron package a few months ago, and want to fix as many bug reports as possible. The current bug report is now quite twenty years old, which means, in terms of computer science, about ten eternities ;) As no consensus has been achieved for twenty years to decide whether this a bu or a non-bug, and as sane workarounds do exist (make important scripts independent of environment variants), I shall close this bug now: I believe that it cannot be fixed by a single change in cron package. Of course, you can reopen it if necessary, but please be kind enough to propose new arguments (I mean newer than the already discussed stuff) Best regards, Georges. Loïc Minier a écrit : > Steve Greenland - Thu, Sep 23, 2004: > > > It was discussed a few years ago, when init (or the kernel) changed > > behaviour, and at the time, the consensus was that scripts like this are > > responsible for having their PATH. It's been a while, though, and that > > might have changed, but you might search the archives (sorry I don't > > have a reference, it's been a while). > > Don't waste your time searching for this, you really have a lot of > better things to do! :) > > I think I've already found the discussions[1]. Because they weren't > finished and did not result in inclusion in the Policy, I really ought > to move my behind and bring this up again in debian-policy, and this is > in preparation. > > > /* ... (save me from /etc/cron.conf!) ... (vix, jan90) */ > > Erf! > > > The problem with making it configurable is that the admin might change > > it, which means that package scripts can still not rely on it. > > Good point, but it is still useful when you're running scripts that are > making the assumption of a sane environment (as was the case of the > OP). Some examples for such scripts are those written to be launched > from within "su" or from "dpkg". > > > > What would you think of a cron.cf, or something similar, serving as a > > > placeholder for configuration of the default PATH and the default PATH > > > for root? > > Ech. If the policy crew decides that crond should set the path > > differently for root, then the Right Thing To Do is pick it up from > > login.defs, not create yet another place for things to be inconsistent. > > Ooch, I misunderstood the meaning of ENV_SUPATH to something related to > "su" since I found that in the su(1) manpage. Of course, the values of > login.defs should be used, you're right. > > Thanks for your time. > > [1] If you meant: > <http://lists.debian.org/debian-policy/1999/04/threads.html#00143> > which started in dd: > <http://lists.debian.org/debian-devel/1999/04/thrd2.html#00812> > -- > Loïc Minier > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#460070: - cron: Using day-of-month and day-of-week together doesn't work as expected
p;
> bit_test(e->month, month) &&
> - ( ((e->flags & DOM_STAR) || (e->flags & DOW_STAR))
> + ( ((e->flags & DOM_STAR) || (e->flags & (DOW_STAR |
> DOW_AND)))
> ? (bit_test(e->dow,dow) && bit_test(e->dom,dom))
> : (bit_test(e->dow,dow) ||
> bit_test(e->dom,dom {
> if ((doNonWild && !(e->flags &
> (MIN_STAR|HR_STAR)))
> Index: cron/cron.h
> ===
> --- cron.orig/cron.h
> +++ cron/cron.h
> @@ -190,6 +190,7 @@ typedef struct _entry {
> #define WHEN_REBOOT 0x04
> #define MIN_STAR0x08
> #define HR_STAR 0x10
> +#define DOW_AND 0x20
> } entry;
>
> /* the crontab database will be a list of the
> Index: cron/crontab.5
> ===
> --- cron.orig/crontab.5
> +++ cron/crontab.5
> @@ -216,8 +216,13 @@ field matches the current time. For exa
> .br
> ``30 4 1,15 * 5''
> would cause a command to be run at 4:30 am on the 1st and 15th of each
> -month, plus every Friday. One can, however, achieve the desired result
> -by adding a test to the command (see the last example in EXAMPLE CRON FILE
> +month, plus every Friday. To allow running it the 1st and 15th of each
> +month
> +.I only when they are Friday
> +this cron allows prepending a ``&&'' token before the day of week to get
> +that behavior (for symmetry, it is also possible to prepend a ``||'',
> +with the above default behavior). Alternatively, one can add a test for
> +the date into the command (see the last example in EXAMPLE CRON FILE
> below).
> .PP
> Instead of the first five fields, one of eight special strings may appear:
> @@ -273,7 +278,8 @@ MAILTO=paul
> 0 */4 1 * mon echo "run every 4th hour on the 1st and on every Monday"
> 0 0 */2 * sun echo "run at midn on every Sunday that's an uneven date"
> # Run on every second Saturday of the month
> -0 4 8\-14 * *test $(date +\e%u) \-eq 6 && echo "2nd Saturday"
> +0 4 8\-14 * && satecho "2nd Saturday"
> +0 4 8\-14 * * test $(date +\e%u) \-eq 6 && echo "2nd Saturday"
> .fi
>
> .PP
> Index: cron/entry.c
> ===
> --- cron.orig/entry.c
> +++ cron/entry.c
> @@ -85,6 +85,8 @@ load_entry(file, error_func, pw, envp)
>* minutes hours doms months dows cmd\n
>* system crontab (/etc/crontab):
>* minutes hours doms months dows USERNAME cmd\n
> + *
> + * optionally: '&&' or '||' (surrounded by whitespace) before dows
>*/
>
> ecode_e ecode = e_none;
> @@ -218,6 +220,46 @@ load_entry(file, error_func, pw, envp)
>
> if (ch == '*')
> e->flags |= DOW_STAR;
> +
> + if (ch == '&') {
> + e->flags |= DOW_AND;
> + ch = get_char(file);
> + if (ch != '&') {
> + ecode = e_dow;
> + goto eof;
> + }
> +
> + ch = get_char(file);
> + if (ch != '\t' && ch != ' ') {
> + ecode = e_dow;
> + goto eof;
> + }
> + Skip_Blanks(ch, file);
> +
> + if (ch == EOF) {
> + ecode = e_dow;
> + goto eof;
> + }
> + } else if (ch == '|') {
> + ch = get_char(file);
> + if (ch != '|') {
> + ecode = e_dow;
> + goto eof;
> + }
> +
> + ch = get_char(file);
> + if (ch != '\t' && ch != ' ') {
> + ecode = e_dow;
> + goto eof;
> + }
> + Skip_Blanks(ch, file);
> +
> + if (ch == EOF) {
> + ecode = e_dow;
> + goto eof;
> + }
> + }
> +
> ch = get_list(e->dow, FIRST_DOW, LAST_DOW,
> DowNames, ch, file);
> if (ch == EOF) {
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
Bug#647884: cron wrong time in logs
Hi, this bug report is now twelve years old. Christian Kastner asked for a snippet of a log file, which was not sent, and explained that this kind of bug is now fixed in recent versions of cron. So, I clode this bug report. Best regards, Georges. Christian Kastner a écrit : > severity 647884 normal > thanks > > Hi, > > On 2011-11-07 10:34, Serguei wrote: > > Package: cron > > Version: 3.0pl1-116 > > Severity: critical > ^^^ > Bug severities have a very specific meaning in Debian, see > > http://www.debian.org/Bugs/Developer#severities > > I'm downgrading this to "normal" according to said policy. > > > i have timezone /etc/timezone which is equal to Europe/Moscow. After 29 > > october When all world moved clock to winter time our timezone left on > > summer time. > > > > first problem: cron runs task as scheduled but puts time into syslog > > with timeshift minus 1 hour > > cron does not specify any time at all -- the timestamp in syslog comes > from the syslog daemon. So whatever the problem is, it can only be > resolved there. > > Could you post a short snippet of your log file with a valid entry > shortly before the DST change and the first invalid entry? > > > second problem: each time crontab file changes cron daemon must be > > restarted to reread crontab > > This issue (previously reported as #625495 and #627859) has been > resolved in package version 3.0pl1-117. > > > Christian > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#617898: cron.d snippets have different default PATH from crontab/cron.{daily,...}
Hello, this bug report is now twelve years old. As root users are supposed to read manpages of important commands, they are aware of the possibility to define environment variables like PATH in crontab files. So, I consider this bug as fixed, per the manpages. Best regards, Georges. Josip Rodin a écrit : > severity 617898 normal > thanks > > Hi, > > Recently I added a logrotate setup that was very similar to apache2's, but > I ran it from a cron.d file, and it obviously failed because the normal > logrotate runs from /etc/crontab, which has a different PATH set. > > I think this is not a wishlist item to change this, rather it is a genuine > bug, because I don't see the actual rationale for the behavior of > /etc/crontab and cron(8) to differ in such a fundamental way, and it's > clearly causing a number of users to have to amend their cron.d files > in a way that is redundant and error-prone (having to redefine PATH > everywhere reminds me of the dark days of 1990s Unix systems, and it is > NOT something we want to replicate ever again). > > I certainly don't see a downside with adding the sbin variants, because > on Debian systems they're expected to be as reliable as bin variants, > and there should be no confusing overlaps. > > For local, an argument could be made that it exposes a possibility of > problems with random local binaries getting in the way, but it would > still probably be better to do this kind of a transition to get everything > consistent. Random complexity just leads to more trouble. > > Please fix this. TIA. > > -- > Josip Rodin > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#647193: /usr/sbin/cron: (*system*) NUMBER OF HARD LINKS > 1 (/etc/crontab)
Hello, this bug report is now twelve years old. As Christian Kastner proposed a reasonable workaround for xavier renaut's use case, and as xavier renaut sent no reply for many years, I close this bug report. Best regards, Georges. Christian Kastner a écrit : > Hi, > > On 2011-10-31 15:32, xavier renaut wrote: > > I hard link /etc/crontab to track it under svn, but > > to have the checkout somewhere else than /etc/ > > > > So /etc/crontab has 2 hardlinks, > > and cron is now complaining about it : > > Oct 3 09:35:01 natch /usr/sbin/cron[3878]: (*system*) NUMBER OF HARD LINKS > > > 1 (/etc/crontab) > > > > Is there something to do ? or the security gain is too high for this to be > > fixed ? > > I'm afraid it's the latter; we can't allow that for security reasons. > > What you could do is make /etc/crontab a symlink to the file in svn. The > symlink owner must be root, see cron(8). > > Christian > > PS: Personally, I can highly recommend the use a configuration > management system such as puppet or cfengine. etckeeper might also be of > interest to you. > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#702712: Use crond -L 5 to get the "(failed)" subject back
Hello, as this bug report has been concluded by Sam Morris' enlightenment, which details how to activate the desired feature, I close it. Best regards, Georges. Sam Morris a écrit : > This was caused by: > > * do_command.c, cron.h, cron.8: > - Change the behaviour when logging the information of the child > processes. > A new loglevel (8) is introduced and documented in cron.8. The > previous > log format is kept unless the sysadmin choses to select this > new option. > (Closes: #637295) > > The exit status of jobs is ignored unless log_level & > CRON_LOG_JOBFAILED. Put EXTRA_OPTS='-L 5' into /etc/default/cron and > restart cron and the mails will be fixed. > > Regards, > > -- > Sam Morris > https://robots.org.uk/ > > PGP key id 1024D/5EA01078 > 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#691275: cron: symlink races in crontab
Hello, this bug report has received no additional information for eleven years now. As Javier Fernández-Sanguino Peña considered that the security issue was not confirmed and asked Jann Horn to describe a proof of concept, without being replied ... I close this bug report. Best regards, Georges. Javier Fernández-Sanguino Peña a écrit : > tags 691275 moreinfo > thanks > > On Tue, Oct 23, 2012 at 09:28:05PM +0200, Jann Horn wrote: > > Debian's crontab contains multiple symlink races. If > > crontab was setuid root (which I think it normally is), this could be used > > to e.g. wipe directories (vulnerable code is in cleanup_tmp_crontab) or for > > other attacks. However, as it is only setgid crontab on debian, the only > > attack this can be used for is to block cron access for a user named > > "crontab" by invoking "crontab -e" and replacing the > > folder in /tmp with a symlink before crontab creates the file "crontab" > > inside the folder. The code vulnerable to this attack is in > > create_tmp_crontab. > > Could you please detail where do you see the symlink races or show, at least, > a > proof of concept of the symlink race in action and how can I reproduce this > bug? > > Reviewing the code: the directory used in cleanup_tmp_crontab is actually > defined in > create_tmp_crontab using mkdtemp(). Mkdtemp ensures that the directory > created is both unique as well as restricted to the user running it. > > This means that, as far as I know, any files created within that directory > (and removed > afterwards) should be "safe". This includes the unlink() codes in > cleanup_tmp_crontab, as well as the rmdir() call there. > > Best regards > > Javier > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1050482: cron: Multiple issues with the cron_now feature
Dear Guillem, thank you for your detailed bug report. You are right, with the suggestion to create a new switch for cron, instead of creating a separate command. I hesitated to choose this method, but you convinced me. I shall upload shortly a new release, with the possibility to launch `cron -N` instead of `cron_now`. Best regards, Georges. Guillem Jover a écrit : > Source: cron > Source-Version: 3.0pl1-173 > Severity: normal > > Hi! > > While reading the changelog [C] during an upgrade I noticed a suspicious > entry, and when I went checking to confirm it noticed multiple issues > with the cron_now feature: > > * There's a hardcoded libselinux1 dependency in the binary stanza > in debian/control, which is wrong, as that should be generated > automatically by dpkg-shlibdeps when needed (would make part of > the gratuitous non-linux restriction unnecessary). > > * The implementation and scaffolding for this cron_new features seems > overly complicated and not ideal: > > - It uses a python script to "patch" the original cron.c to create > a new command. A better, simpler and more future-proof way would > have been to simply patch cron.c directly. > > - Builds this new command ignoring all system dpkg-buildflags, and > hard-codes optional features already handled as such in > debian/rules and the upstream build system. Making the package > gratuitously non-portable (unconditional use of pam, selinux and > audit). > > - The current hardcoding includes maintainer specific system paths > such as «/home/georgesk/developpement/cron/collab/cron». > > - Nit: could use execute_after_ to avoid calling the > overridden command. Or simply use stuff like debian/clean > instead of any dh_auto_clean override at all. But this is all > completely unnecessary if there is no cron_new, or if its build > is handled by the upstream build system. > > * There is a new interface (the cron_new program), instead of say > adding a new option flag, which complicates the build system and > duplicates the functionality in two programs. Is this public new > interface in the form of a new program really justified (instead > of simply adding a flag)? > > (If you'd insist with this new cron_now interface, then this could > be done in a better way by patching the original code in cron.c > within «#ifdef» blocks or similar, and then modifying the upstream > build system for this new target, taking into account build flags > and variable features). > > > [C] BTW, please describe what the actual changes do, writing something > like “applied one change proposed by Helge Kreutzmann (thanks!).” > is not very helpful and requires going to the bug report. > > Thanks, > Guillem > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#777584: wrap long lines
Hello Frank, thank you for your response. cron is a key command for UNIX systems, and it is supposed to remain lightweight and efficient. This is why it does not implement the mailing features, and relies on other UNIX commands to do this job (`mail` or `sendmail`) You can browse the file do_command.c in cron's source package, and read, near line 360, how cron does its job to collect data coming from children commands, and compose an e-mail. So far, the output of the child command is just appended to a text stream, which begins with From:, To:, Subject:, Date: lines. However you are searching to address the case when the output of the command is too big to be just appended to such a text file. In the case of a big output, the solution would be to encode it (QP or base64 are possible encodings), but in such a case, they should not be appended to the same stream which contains From:, To:, Subject:, Date: lines, but included in a separate stream, and handed to `send` or `sendmail` command as an attachment. --- Would you please be kind enough to propose a patch for the file do_command.c, which implements encoding and attaching big outputs? If you can do it, I would be very pleased to read your code and include your patch to the series of patches which are part of the debian source package, in order to create this new feature. By the way, if you modify the way cron sends e-mails, please can you propose a simple test to check whether your modification is running as expected? This test will be appended to the series used in autopkgtest, in order to prevent eventual future regressions. Thank you in advance for your response. Best regards, Georges. Frank Heckenbach a écrit : > Hello, > > > I am the new maintainer for cron package, since a few months. Please can > > one elaborate a little longer about use cases where too long lines are a > > problem? > > Thanks for picking up this issue again. I'm not the original > reporter, but also effected, as I wrote in my comment last year. > > SMTP standards (RFC 2822) specify a maximum line length of 998 > characters. > > It can be avoided by encoding the mail. QP (quoted-printable) and > base64 are common encdings. QP can break source lines (by inserting > "=\n" anywhere), and base64 output doesn't care about line breaks at > all. > > > Would it be sufficient to truncate such lines to 998 characters, hoping > > that such a length would be sufficient to diagnose a problem? > > This would lose information. I don't think I'd like this unless the > original content was stored somewhere and the mail contains a link > where to find it. But that seems more work than the alternatives. > > > It would > > be more secure than splitting them and making it possible to overflow > > the file system (for example with too big messages, repeated every > > minute during one day). > > Overflowing the file system is a separate issue which can just as > well happen with many short lines. Sure, you might want to handle > this too, but for that you'd might want to set a maximum size (say, > in MB and perferably configurable) independent of line lengths. > > Regards, > Frank -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#811126: cron: MIME-Version header not set thus Content-Type and other MIME headers may be ignored
Hello,
considering that the bug was considered as fixed, and tagged moreinfo,
without new information received for seven years, I shall close it now.
Please feel free to reopen it.
Best regards, Georges.
Christian Kastner a écrit :
> Control: tag -1 moreinfo
>
> Hi,
>
> On 2016-01-15 22:18, Vincent Caron wrote:
> > Package: cron
> > Version: 3.0pl1-127+deb8u1
>^^^
>
> This version already contains this fix; it first included in
> 3.0pl1-125.
>
> Is it possible that you got your versions mixed up?
>
> > when sending command outputs via email, cron will use at least one MIME
> > header(Content-Type, wether the user configured CONTENT_TYPE or not),
> > but will not set the "MIME-Version" header as required by the MIME RFC.
>
> > The patch is pretty trivial: always add a "MIME-Version: 1.0" header.
> >
> > --- do_command.c.orig 2016-01-15 13:24:09.486709632 +0100
> > +++ do_command.c2016-01-15 13:07:26.594685734 +0100
> > @@ -567,6 +567,7 @@
> > fprintf(mail, "Date: %s\n",
> > arpadate());
> > # endif /* MAIL_DATE */
> > + fprintf(mail, "MIME-Version: 1.0\n");
> > if ( content_type == 0L ) {
> > fprintf(mail, "Content-Type: text/plain; charset=%s\n",
> > cron_default_mail_charset
>
> Regards,
> Christian
>
>
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
Bug#777584: wrap long lines
Hello, I am the new maintainer for cron package, since a few months. Please can one elaborate a little longer about use cases where too long lines are a problem? Would it be sufficient to truncate such lines to 998 characters, hoping that such a length would be sufficient to diagnose a problem? It would be more secure than splitting them and making it possible to overflow the file system (for example with too big messages, repeated every minute during one day). As this bug report is now eight years old, I shall wait for a response during a few weeks; if nobody replies, I shall close it. But please feel free to reopen it if you have more information to share about it! Best regards, Georges. Tags: +moreinfo Frank Heckenbach a écrit : > The limit according to RFC 2822 is 998 characters. > Current versions of exim4, e.g., enforce this limit. > > So if you do wrapping, you might as well use the correct limit. > > Of course, wrapping slightly alters the content. > > If this is deemed inacceptable, you might need to MIME encode the > message (QP or base64). > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#857904: cron.daily/logrotate generates email every day
Hello, considering that this bug report was commented as quite fixed in this e-mail and the pervious ones, and that no other information was added for it during a few tears, I shall close it. Best regards, Georges. Daniel Pocock a écrit : > Control: tags -1 - moreinfo > > On 20/03/17 21:27, Andreas Henriksson wrote: > > Control: severity -1 normal > > Control: tags -1 + moreinfo > > > > Hello Daniel Pocock, > > > > Thanks for your bug report. > > > > On Thu, Mar 16, 2017 at 09:21:20AM +, Daniel Pocock wrote: > >> Package: logrotate > >> Version: 3.11.0-0.1 > >> Severity: serious > >> > >> Since updating one of my systems from jessie to stretch in January, the > >> cron.daily/logrotate cron job has been generating a large email every > >> day which appears to contain rather verbose output about everything it > >> does. > >> > >> I notice several lines in the output like this: > >> > >> Got result done/Resource temporarily unavailable for job > >> apache2.service > > [...] > > > > Judging from the output you sent it seems like you're running your > > system with systemd.log_level=debug or similar > > > > I'm thus tempted to claim the result is that things are working as > > expected. > > > > (I certainly don't see your behaviour here any way, so downgrading > > severity atleast. Feel free to close if you can confirm my suspicion > > above is the cause or find something else.) > > > > Yes, I can confirm systemd.log_level=debug is in /etc/default/grub - I > had been troubleshooting another issue at the same time I upgraded the > host to stretch. It never occurred to me that it was related to these > messages, in fact, the other issue had been fixed on a Friday and I > didn't even look at these emails until the following week. Thanks for > pointing this out. > > Is there some way the log output in cron emails could include a line > indicating that systemd debug logging is enabled so it is obvious how to > stop it again? > > Regards, > > Daniel > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#895024: Error: bad hour; while reading /etc/crontab makes the cron do nothing
Hello, as the bug was tagged unreproducible moreinfo, and considered that no new information was provided for a few years, I shall close this bug report. Best regards, Georges. Christian Kastner a écrit : > Tags: + unreproducible moreinfo > > Hi Salvo, > > On 2018-06-04 12:57:37 Salvo Tomaselli wrote: > > I had made a mistake while writing crontab, and had reversed hours and > > minutes. > > > > This happened: > > Error: bad hour; while reading /etc/crontab > > > > Hoewver, cron then doesn't run any job at all. In this case it should just > > terminate with error, so I would see that the service is not running at all. > > The service should be running. The cron daemon just skips the broken > crontab. > > I just tested this by first creating a valid crontab > > * * * * * root date >> /tmp/datestamp > > and later by adding an invalid one > > * 25 * * * root date >> /tmp/foostamp > > and the following is logged to the cron facility: > > Mar 3 18:58:01 devel CRON[22663]: (root) CMD (date >> /tmp/datestamp) > Mar 3 18:59:01 devel CRON[22721]: (root) CMD (date >> /tmp/datestamp) > Mar 3 19:00:01 devel cron[3870]: Error: bad hour; while reading > /etc/cron.d/bar > Mar 3 19:00:01 devel cron[3870]: (*system*bar) ERROR (Syntax error, this > crontab file will be ignored) > Mar 3 19:00:01 devel CRON[22751]: (root) CMD (date >> /tmp/datestamp) > Mar 3 19:01:01 devel CRON[22755]: (root) CMD (date >> /tmp/datestamp) > > As you can see, the crontab /etc/cron.d/bar is skipped because of a > syntax error, but cron continues executing the other crontab. > > Could you please re-check if cron is indeed not processing any other > tabs (for example, with the above examples). > > Note that I have enabled logging for every priority of the cron > facility to /var/log/cron.log (/etc/rsyslog.conf has a commented- > out example for this). > > Regards, > Christian > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#978635: cron: buggy/confusing dlopen(pam_unix.so) error message
Hello Vincent,
I grepped in cron's code and in the debian patches:
$ grep -rl lib/security *
=> [nothing]
$ grep -rl pam_unix *
=> [nothing]
$ grep -r unable *
debian/patches/fixes/Allow-editors-with-tmpfiles.patch: perror("unable
to stat temp file");
My opinion is that cron is not responsible for the wording of the error
message, so it makes no sense to try to fix this wording inside cron's
package.
So, I close this bug report. Please feel free to reopen it, with some
more information if available, or reassign it to some other package.
Best regards, Georges.
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
signature.asc
Description: PGP signature
Bug#1049353: [Re: cron-daemon-common: please ship tmpfiles.d and sysusers.d snippets]
Dear Alexandre, thank you for your proposition, which makes sense. Would you be kind enough to attach a patch? Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#630538: Vixie cron PID confusion
Hi Christian, Teal, I adopted the package cron a few months ago and will keep ironing out outstanding bug reports, when I can do it. Dear Teal, please can you propose a patch to fix this issue as you suggested it three months ago? Best regards, Georges. On Sat, 15 Apr 2023 14:14:59 +0200 Christian Kastner wrote: > Hi Teal, > > I'm no longer a maintainer of cron, but I was the one last replying to > the original report (can't believe it's been 12 years...) > > On 2023-04-08 12:30, Teal Bauer wrote: > > The same Selective logging patch added a version of the logging in the > > default branch of the fork() switch, so if the -L log levels for "log > > job start" and "log job pid" are set, the starting PID is not logged by > > the child but the parent process instead. > > > > So basically there is now what seems to me to be a "do things right" > > flag - if log level includes 8 (log PIDs) then both CMD and END messages > > are sent by the same process and contain the same correct PIDs: > > > > Apr 8 10:17:56 e02fc37faf65 CRON[27]: (root) CMD ([28] > > /tmp/runner.sh >>/tmp/runner.log) > > Apr 8 10:19:12 e02fc37faf65 CRON[27]: (root) END ([28] > > /tmp/runner.sh >>/tmp/runner.log) > > > > (PID 27 is the cron parent, PID 28 is the command child, PID 29 is the > > PID of the actual command). > > If the log level includes only e.g. "log start" and "log end", then the > > PIDs will differ: > > > > Apr 8 10:14:06 2d9c73749325 CRON[28]: (root) CMD (/tmp/runner.sh > >>>/tmp/runner.log) > > Apr 8 10:15:27 2d9c73749325 CRON[27]: (root) END (/tmp/runner.sh > >>>/tmp/runner.log) > > > > (PID 28 is the command child which sends the CMD message, PID 27 is the > > cron parent which sends the END message, the actual command is PID 29) > > > > I would like to propose (and intend on submitting a patch soon) to > > always log in the same place. > > Ideally, that would be the child process, so that the PID that openlog() > > uses and the PID that cron would log are the same, but I'm not sure > > that's possible in a reliable way. Doing it in the parent is just as > > well for me, though - my original intent was trying to match CMDs to > > ENDs in the logs of a wildly active system. > > > > Curious to hear your thoughts! > > Sounds good to me! > > Best, > Christian > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1038836: /etc/localtime does not yield the same contents than /etc/timezone
Hello, I shall close this bug report. So far, cron is happy with /etc/timezone, and using /etc/localtime instead would initialize TZ to a wrong value. For example, on my machine: --8<--- ~$ cat /etc/timezone Europe/Paris ~$ cat /etc/localtime | strings TZif2 WEST CEST WEMT TZif2 WEST CEST WEMT CET-1CEST,M3.5.0,M10.5.0/3 --8<--- Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1039935: ITP: python-rlpycairo -- plugin for the ReportLab PDF Toolkit
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-rlpycairo Version : 0.3.0 Upstream Contact: ReportLab Inc. * URL : https://pypi.org/project/rlPyCairo/ * License : BSD Programming Lang: Python3 Description : plugin for the ReportLab PDF Toolkit This plugin is intended to replace most of the usage of the libart based C extension _renderPM which has been shown to have issues when rendering complex documents. - without this package, one cannot use package python-biopython together with python-reportlab version 4, since python-reportlab version 4 provides no longer the extension _renderPM cited above. - I shall keep maintaining it, shared with python-team/packages in https://salsa.debian.org/python-team/packages/python-pycairo
Bug#1039594: RM: python-reportlab -- NBS; python-reportlab source package does no longer build python3-reportlab-accel, neither python3-renderpm
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: removepython-reportlab X-Debbugs-Cc: python-report...@packages.debian.org Control: affects -1 + src:python-reportlab Dear FTP masters, the package python-reportlab, version 4.0.4, cannot migrate to testing since I uploaded version 4.0.4-1 The reason reported in https://qa.debian.org/excuses.php?package=python- reportlab is that Arch-builds are missing. As a matter of fact, upstream developers are no longer dealing with C/C++ source files, and provide python-reportlab as a pure Python package. Currently the list of binary packages is shorter in debian/control than it was for previous releases.However the source package had been accepted silently when I ran dput. Please tell me what can I do, or what can be done elsewhere in order to normalize this situation? I recently adopted this package, and followed the recommendation written in the orphaning bug report, to upgrade it to its new upstream version. Thank you in advance. Georges.
Bug#1035510: unblock: waylandpp/1.0.0-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: waylan...@packages.debian.org Control: affects -1 + src:waylandpp Please unblock package waylandpp [ Reason ] The new release is a fix for the RC bug #1035462 [ Impact ] waylandpp rdepends ... kodi: "Kodi, formerly known as XBMC is an award winning free and open source software media-player and entertainment hub" [ Tests ] non-superficial tests are run during the build: see https://salsa.debian.org/debian/waylandpp/-/pipelines/524875 [ Risks ] The change is trivial: adding a seldom used library to the package libwayland-client++0, which is libwayland-client-unstable++.so [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock waylandpp/1.0.0-4 diff -Nru waylandpp-1.0.0/debian/changelog waylandpp-1.0.0/debian/changelog --- waylandpp-1.0.0/debian/changelog2022-05-17 09:32:49.0 +0200 +++ waylandpp-1.0.0/debian/changelog2023-05-03 17:39:41.0 +0200 @@ -1,3 +1,13 @@ +waylandpp (1.0.0-4) unstable; urgency=medium + + * added usr/lib/*/libwayland-client-unstable++.so.* in the file +d/libwayland-client++1.install, removed it from d/not-installed. +Closes: #1035462 + * fixed Standards-Version: 4.6.0.2 -> 4.6.2 + * declared libwayland-client-unstable++.so in d/libwayland-client++1.shlib + + -- Georges Khaznadar Wed, 03 May 2023 17:39:41 +0200 + waylandpp (1.0.0-3) unstable; urgency=medium * Closes: #1011107, thanks to Thadeu Lima de Souza Cascardo; diff -Nru waylandpp-1.0.0/debian/control waylandpp-1.0.0/debian/control --- waylandpp-1.0.0/debian/control 2022-05-17 09:32:49.0 +0200 +++ waylandpp-1.0.0/debian/control 2023-05-03 17:39:41.0 +0200 @@ -12,7 +12,7 @@ libegl1-mesa-dev, wayland-scanner++:any , doxygen, -Standards-Version: 4.6.0.2 +Standards-Version: 4.6.2 Vcs-Browser: https://salsa.debian.org/debian/waylandpp Vcs-Git: https://salsa.debian.org/debian/waylandpp.git Homepage: https://github.com/NilsBrause/waylandpp diff -Nru waylandpp-1.0.0/debian/libwayland-client++1.install waylandpp-1.0.0/debian/libwayland-client++1.install --- waylandpp-1.0.0/debian/libwayland-client++1.install 2022-05-14 17:21:55.0 +0200 +++ waylandpp-1.0.0/debian/libwayland-client++1.install 2023-05-03 17:37:14.0 +0200 @@ -1 +1,2 @@ usr/lib/*/libwayland-client++.so.* +usr/lib/*/libwayland-client-unstable++.so.* \ Pas de fin de ligne à la fin du fichier diff -Nru waylandpp-1.0.0/debian/libwayland-client++1.shlibs waylandpp-1.0.0/debian/libwayland-client++1.shlibs --- waylandpp-1.0.0/debian/libwayland-client++1.shlibs 2022-05-14 17:21:55.0 +0200 +++ waylandpp-1.0.0/debian/libwayland-client++1.shlibs 2023-05-03 17:39:41.0 +0200 @@ -1 +1,2 @@ -libwayland-client++ 1 libwayland-client++1 (>= 1.0.0) +libwayland-client++ 1 libwayland-client++1 (>= 1.0.0) +libwayland-client-unstable++ 1 libwayland-client-unstable++1 (>= 1.0.0) \ Pas de fin de ligne à la fin du fichier diff -Nru waylandpp-1.0.0/debian/not-installed waylandpp-1.0.0/debian/not-installed --- waylandpp-1.0.0/debian/not-installed2022-05-06 18:38:30.0 +0200 +++ waylandpp-1.0.0/debian/not-installed2023-05-03 17:38:04.0 +0200 @@ -1,3 +1,2 @@ -usr/lib/*/libwayland-client-unstable++.so.* usr/lib/*/cmake/* usr/share/doc/waylandpp/latex
Bug#1034715: new debdiff
Hi, as the previous upload triggered a new bug, I fixed it.
Please find attached the new source debdiff.
Best regards, Georges.
--
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70
diff -Nru python-xmlschema-1.10.0/debian/changelog
python-xmlschema-1.10.0/debian/changelog
--- python-xmlschema-1.10.0/debian/changelog2022-12-18 20:47:28.0
+0100
+++ python-xmlschema-1.10.0/debian/changelog2023-04-25 17:29:03.0
+0200
@@ -1,3 +1,35 @@
+python-xmlschema (1.10.0-6) unstable; urgency=medium
+
+ * disabled some tests, rather than executing them conditionnally after
+the success of "wget http://example.com;. Closes: #1034751
+
+ -- Georges Khaznadar Tue, 25 Apr 2023 17:29:03 +0200
+
+python-xmlschema (1.10.0-5) unstable; urgency=medium
+
+ * created a target "override_dh_auto_clean" in d/rules to copy the
+file mypy.ini to the build directory of pybuild, so tests based
+on mypy get a chance of success.
+ * patched the file tests/test_package.py in order to enforce
+encoding="utf-8" for calls of fileinput.input, which may be
+necessary with git-build-package in a chroot.
+ * patched xmlschema/testing/_builders.py and tests/test_xpath.py
+to check whether there is Internet access prior to check structures
+requiring to retreive schemas from http://example.com; added a
+build-dependency on wget.
+ * those three changes should be sufficient, so it Closes: #1027439
+
+ -- Georges Khaznadar Sat, 22 Apr 2023 16:24:29 +0200
+
+python-xmlschema (1.10.0-4) unstable; urgency=medium
+
+ * created the debian patch d/Fix-tests.patch, which modifies two tests:
+xmlschema/testing/_builders.py with a true fix, and
+tests/test_typing.py which is just disabled (not a true fix).
+ Closes: #1027439
+
+ -- Georges Khaznadar Sat, 22 Apr 2023 10:58:29 +0200
+
python-xmlschema (1.10.0-3) unstable; urgency=medium
* Fix patch description
diff -Nru python-xmlschema-1.10.0/debian/control
python-xmlschema-1.10.0/debian/control
--- python-xmlschema-1.10.0/debian/control 2022-12-18 20:47:28.0
+0100
+++ python-xmlschema-1.10.0/debian/control 2023-04-22 17:24:07.0
+0200
@@ -13,6 +13,7 @@
python3-setuptools,
python3-sphinx ,
python3-sphinx-rtd-theme ,
+ wget,
Rules-Requires-Root: no
Standards-Version: 4.6.2
Homepage: https://github.com/sissaschool/xmlschema
diff -Nru python-xmlschema-1.10.0/debian/patches/Fix-encoding.patch
python-xmlschema-1.10.0/debian/patches/Fix-encoding.patch
--- python-xmlschema-1.10.0/debian/patches/Fix-encoding.patch 1970-01-01
01:00:00.0 +0100
+++ python-xmlschema-1.10.0/debian/patches/Fix-encoding.patch 2023-04-25
17:29:03.0 +0200
@@ -0,0 +1,40 @@
+enforced encoding="utf-8" for calls of fileinput.input, since it
+may be necessary during the package build in some environments
+Index: python-xmlschema/tests/test_package.py
+===
+--- python-xmlschema.orig/tests/test_package.py
python-xmlschema/tests/test_package.py
+@@ -42,7 +42,7 @@ class TestPackaging(unittest.TestCase):
+ file_excluded = []
+ files = glob.glob(os.path.join(self.source_dir, '*.py')) + \
+ glob.glob(os.path.join(self.source_dir, 'validators/*.py'))
+-for line in fileinput.input(files):
++for line in fileinput.input(files, encoding="utf-8"):
+ if fileinput.isfirstline():
+ filename = fileinput.filename()
+ file_excluded = exclude.get(os.path.basename(filename), [])
+@@ -66,7 +66,7 @@ class TestPackaging(unittest.TestCase):
+ os.path.join(self.package_dir, 'doc/conf.py'),
+ ])
+ version = filename = None
+-for line in fileinput.input(files):
++for line in fileinput.input(files, encoding="utf-8"):
+ if fileinput.isfirstline():
+ filename = fileinput.filename()
+ lineno = fileinput.filelineno()
+@@ -84,13 +84,13 @@ class TestPackaging(unittest.TestCase):
+ def test_elementpath_requirement(self):
+ package_dir = pathlib.Path(__file__).parent.parent
+ ep_requirement = None
+-for line in
fileinput.input(str(package_dir.joinpath('requirements-dev.txt'))):
++for line in
fileinput.input(str(package_dir.joinpath('requirements-dev.txt')),
encoding="utf-8"):
+ if 'elementpath' in line:
+ ep_requirement = line.strip()
+
+ self.assertIsNotNone(ep_requirement, msg="Missing elementpath in
requirements-dev.txt")
+
+-for line in fileinput.input(str(package_dir.joinpath('setup.py'))):
++for line in fileinput.input(str(package_dir.joinpath('setup.py')),
encoding="
Bug#1034751: python-xmlschema: accesses internet during build
Hi, thank you for the bug report. Instead of executing some python tests conditionnally, I shall patch them to prevent their execution, independently from the network's availability. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1034715: unblock: python-xmlschema/1.10.0
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: python-xmlsch...@packages.debian.org
Control: affects -1 + src:python-xmlschema
Please unblock package python-xmlschema
This package had a RC bug, due to changes in the dependency python3-elementpath
I uploaded an new release, 1.10.0-4, which a small patch which fixes bug
#1027439,
so the 72 failed tests are now succeeding.
[ Impact ]
other packages which depend directly on python3-xmlschema are
- python3-xarray-sentinel
- python3-pysaml2
- libervia-backend
[ Tests ]
dh_auto_test runs 1207 tests successfully, 11 tests are skipped.
[ Risks ]
python3-xmlschema is rather complex, but the changes made to the test suite
provided by upstream developers in version 1.10.0 are trivial.
the popcon score of python-xmlschema is approximately 60; it is not a leaf
package.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
Best regards, Georges.
unblock python-xmlschema/1.10.0
diff -Nru python-xmlschema-1.10.0/debian/changelog
python-xmlschema-1.10.0/debian/changelog
--- python-xmlschema-1.10.0/debian/changelog2022-12-18 20:47:28.0
+0100
+++ python-xmlschema-1.10.0/debian/changelog2023-04-22 10:58:29.0
+0200
@@ -1,3 +1,12 @@
+python-xmlschema (1.10.0-4) unstable; urgency=medium
+
+ * created the debian patch d/Fix-tests.patch, which modifies two tests:
+xmlschema/testing/_builders.py with a true fix, and
+tests/test_typing.py which is just disabled (not a true fix).
+Closes: #1027439
+
+ -- Georges Khaznadar Sat, 22 Apr 2023 10:58:29 +0200
+
python-xmlschema (1.10.0-3) unstable; urgency=medium
* Fix patch description
diff -Nru python-xmlschema-1.10.0/debian/patches/Fix-tests.patch
python-xmlschema-1.10.0/debian/patches/Fix-tests.patch
--- python-xmlschema-1.10.0/debian/patches/Fix-tests.patch 1970-01-01
01:00:00.0 +0100
+++ python-xmlschema-1.10.0/debian/patches/Fix-tests.patch 2023-04-22
10:58:29.0 +0200
@@ -0,0 +1,26 @@
+Index: python-xmlschema/xmlschema/testing/_builders.py
+===
+--- python-xmlschema.orig/xmlschema/testing/_builders.py
python-xmlschema/xmlschema/testing/_builders.py
+@@ -125,7 +125,7 @@ def make_schema_test_class(test_file, te
+ if not inspect and not self.errors:
+ context = XMLSchemaContext(schema)
+ elements = [x for x in schema.iter()] # Contains schema
elements only
+-xpath_context_elements = [x for x in context.iter() if
isinstance(x, XsdValidator)]
++xpath_context_elements = [x for x in context.root.iter() if
isinstance(x, XsdValidator)]
+ descendants = [x for x in
context.iter_descendants('descendant-or-self')]
+ self.assertTrue(x in descendants for x in
xpath_context_elements)
+ for e in elements:
+Index: python-xmlschema/tests/test_typing.py
+===
+--- python-xmlschema.orig/tests/test_typing.py
python-xmlschema/tests/test_typing.py
+@@ -20,6 +20,8 @@ try:
+ except ImportError:
+ mypy = None
+
++# this test is disabled in Debian
++mypy = None
+
+ @unittest.skipIf(mypy is None, "mypy is not installed")
+ class TestTyping(unittest.TestCase):
diff -Nru python-xmlschema-1.10.0/debian/patches/series
python-xmlschema-1.10.0/debian/patches/series
--- python-xmlschema-1.10.0/debian/patches/series 2022-12-18
20:47:28.0 +0100
+++ python-xmlschema-1.10.0/debian/patches/series 2023-04-22
10:58:29.0 +0200
@@ -1 +1,2 @@
Skip-failing-packaging-test.patch
+Fix-tests.patch
Bug#623231: twelve years old bug report
Hi Hanno, I am closing the bug report #623231; please feel free to reopen it if it deserves attention. If you reopen it, please reply also the previous e-mail, sent ten days ago, which is cited below. Best regards, Georges. Georges Khaznadar a écrit : > Hi, > > I am the new maintainer for cron, willing to hunt bugs. Here is a > reminder about bug #623231, which was left without a response for twelve > years. > > Here is what I understand : you submitted a patch, which extends the > command crontab, adding a switch to allow root to display information > about users who are using crontabs, or missing users in the same > situation. > > My opinion is that such a utility can be provided without touching > Vixie's crontab command, since this utility is quite general, and can be > interesting for people who prefer to run bcron or cronie instead of > cron. > > Please would you be kind enough to rewrite your algorithm into a command > which might be a C program, or a simple script in sh/perl/python/etc. ? > > It would be my pleasure to insert it as a command named "cron-util" or > something similar, into the package cron-daemon-common, which is a > pre-dependency for every cron-like package in Debian nowadays. > > Best regards, Georges. > > -- > Georges KHAZNADAR et Jocelyne FOURNIER > 22 rue des mouettes, 59240 Dunkerque France. > Téléphone +33 (0)3 28 29 17 70 > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#175470: a 20 years old bug report
Hi Sebastian, I am closing the bug report #175470; please feel free to reopen it if it deserves attention. If you reopen it, please reply also the previous e-mail, sent ten days ago, which is cited below. Best regards, Georges. Georges Khaznadar a écrit : > tags 175470 + moreinfo > > Hi Sebastian, > > I am the new maintainer for cron package, willing to hunt bugs: > > You wrote a patch against cron in year 2003, which extends the syntax of > crontab lines, allowing one to insert l, m, and p switches to control > respectively logging to syslog, mailing to the user and using PAM. > > This patch seems shiny, from my point of view. However 20 years passed, > without a response from the maintainer, and earth is still spinning, > without this patch. > > So, please answer a few questions if you do not mind: > > - are you currently still using such a patched crontab format? Or are > you using some other workaround/solution? > > - I wish to implement tests to prevent regressions, when some important > feature is added to cron/crontab. Please have you suggestions to build > a comprehensive test for your enhancements? > > Best regards, Georges. > > -- > Georges KHAZNADAR et Jocelyne FOURNIER > 22 rue des mouettes, 59240 Dunkerque France. > Téléphone +33 (0)3 28 29 17 70 > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1031735: oggvideotools: autopkgtest relies on an obsolet location for file Effet_force_magnetique.ogv
Package: oggvideotools Version: 0.9.1-6 Severity: normal Dear Maintainer, I am the author and maintainer of package pymecavideo, which yields the binary package python3-mecavideo. The new version (>> 8.0~rc4) will have the file "Effet_force_magnetique.ogv" in a new location: /usr/share/pymecavideo/data/video/Effet_force_magnetique.ogv As this file is not accessible from the path /usr/share/python3-mecavideo/video/Effet_force_magnetique.ogv which is used for autopkgtests, the test fails, so the version 8.0~rc4 of package pymecavideo introduces a regression. To fix it, I shall upload a version 8.0~rc5 which creates a symlink from /usr/share/python3-mecavideo/video to ../pymecavideo/data/video But this is "quick and dirty" as a job. Please can you modify your test script, to use instead, the definitive location, /usr/share/pymecavideo/data/video/Effet_force_magnetique.ogv ? Best regards, Georges. -- System Information: Debian Release: bookworm/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages oggvideotools depends on: ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libgd3 2.3.3-7+b1 ii libstdc++6 12.2.0-14 ii libtheora0 1.1.1+dfsg.1-16.1 ii libvorbis0a1.3.7-1 ii libvorbisenc2 1.3.7-1 oggvideotools recommends no packages. oggvideotools suggests no packages. -- no debconf information
Bug#924510: as uninstalling anacron fixes the bug, close #924510
Hi, when cron jobs are under /etc/cron.daily, they are launched by anacron, if this package is installed, because anacron takes control of the file /etc/crontab If you are eager to have some jobs done at a precise time everyday, you should not put them in /etc/cron.daily, but rather edit root's own crontab file. Anacron runs jobs in a pretty asynchronous mode ;) I am closing this bugreport. PLease feel free to reopen it if you want. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#623231: twelve years old bug report
Hi, I am the new maintainer for cron, willing to hunt bugs. Here is a reminder about bug #623231, which was left without a response for twelve years. Here is what I understand : you submitted a patch, which extends the command crontab, adding a switch to allow root to display information about users who are using crontabs, or missing users in the same situation. My opinion is that such a utility can be provided without touching Vixie's crontab command, since this utility is quite general, and can be interesting for people who prefer to run bcron or cronie instead of cron. Please would you be kind enough to rewrite your algorithm into a command which might be a C program, or a simple script in sh/perl/python/etc. ? It would be my pleasure to insert it as a command named "cron-util" or something similar, into the package cron-daemon-common, which is a pre-dependency for every cron-like package in Debian nowadays. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#175470: a 20 years old bug report
tags 175470 + moreinfo Hi Sebastian, I am the new maintainer for cron package, willing to hunt bugs: You wrote a patch against cron in year 2003, which extends the syntax of crontab lines, allowing one to insert l, m, and p switches to control respectively logging to syslog, mailing to the user and using PAM. This patch seems shiny, from my point of view. However 20 years passed, without a response from the maintainer, and earth is still spinning, without this patch. So, please answer a few questions if you do not mind: - are you currently still using such a patched crontab format? Or are you using some other workaround/solution? - I wish to implement tests to prevent regressions, when some important feature is added to cron/crontab. Please have you suggestions to build a comprehensive test for your enhancements? Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1001207: cron runs sendmail with HOME=/
tags 1001207 + moreinfo Hello, I am the new maintainer for package cron. I read that you are wishing a value for the HOME environment variable, in order to let cron be aware of some `~/.esmtprc` file. However, I cannot know which value can be assigned to HOME. I suppose that sendmail is called by some cron job. Please can you tell me which is this job? You can probably find it by calling `grep -rl sendmail /etc/cron*`. Best regards, Georges. -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#1020415: bcron-start terminated 111 status
Hello, in order to reproduce the bug, I can compare two commands: 1st command sudo /usr/bin/daemon --noconfig --name bcron-start /usr/sbin/bcron-start this one lauches bcron-start as a daemon, and syslog reports that bcron-start exited with 111 status. This one is actually launched, considering that it is part of the file debian/contrib/syslog/bcron-sched, which matters, as it is considered by the file debian/rules, during the build of the package. 2nd command sudo /usr/sbin/bcron-start that one launches bcron-start as a foreground process, and it works. I found a clue! When one launches sudo /usr/bin/daemon --noconfig /usr/sbin/bcron-start omitting the parameter "--name bcron-start", the process bcron-start is launched as a daemon, and no exception with code 111 is emitted. However, as the daemon is not named and has no pidfile, one cannot stop it easily: one must find its pid and then stop it with kill -KILL. Does this weird behavior remind you anything, Tomas ? Best regards, Georges. signature.asc Description: PGP signature
