Bug#1073483: Intent to NMU apt-src to fix its trivial FTBFS bug
Hello László, Am Sun, Sep 01, 2024 at 08:10:22PM +0200 schrieb László Böszörményi (GCS): > On Sun, Sep 1, 2024 at 6:33 PM Helge Kreutzmann wrote: > > If anything is unclear, I'm happy to resolve this. > I started the update back then. Soon I got stuck, the current state > is online [1]. The pod can't be processed and in the next few days I > don't have time to look at it. Yes, this build failure is expected: "/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/apt-src make[1]: *** No rule to make target 'man/apt-src.es.pod', needed by 'manifypods'. Stop. make[1]: Leaving directory '/tmp/astest/apt-src-0.25.4' (This is after I faked more strings in de.po). The build system "as is" does not deal with incomplete translations, see the Makefile line 421: manifypods : pure_all config \ man/apt-src.de.pod \ man/apt-src.es.pod \ man/apt-src.fr.pod \ man/apt-src.nl.pod \ man/apt-src.pod \ man/apt-src.pt.pod $(NOECHO) $(POD2MAN) --section=$(MAN1EXT) --perm_rw=$(PERM_RW) -u \ man/apt-src.de.pod man/apt-src.de.1 \ man/apt-src.es.pod man/apt-src.es.1 \ man/apt-src.fr.pod man/apt-src.fr.1 \ man/apt-src.nl.pod man/apt-src.nl.1 \ man/apt-src.pod man/apt-src.1 \ man/apt-src.pt.pod man/apt-src.pt.1 Once I get your go, I will request all translations to be updated again, and given that apt-src.1 is rather static, this problem should not occur in practice. It only happens now, as I updated apt-src.1 but not the translations. So my proposal is to ignore this problem. For testing, you can fake entries in the de.po, es.po, fr.po and nl.po. As said earlier, once you approve the patch, the translations will return to 100%. If some new translations should arrive, it will be 100% and you will need to update this piece of the Makefile. Of course, this can be done dynamic. But given the static nature of this package, I don't think it is worth the effort, but if you are interested, its documented in po4a(1). So my proposal is to first get this package back in shape and testing. Making the Makefile dynamic would be the next step, which you can work on after I "left" taking care and with properly i18n in testing. Would that be fine for your? Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1073483: Intent to NMU apt-src to fix its trivial FTBFS bug
Hello László, Am Sun, Sep 01, 2024 at 09:19:32PM +0200 schrieb László Böszörményi (GCS): > On Sun, Sep 1, 2024 at 8:46 PM Helge Kreutzmann wrote: > > apt-src_0.25.4.dsc: > > dscverify: apt-src_0.25.4.dsc failed signature check: > > gpg: no valid OpenPGP data found. > Yup, I don't sign half or even less ready packages. > > > Do you maybe have git repository I could clone? Or can you > > tar up the the current state and make it available somewhere? > That's also there [1]. > > Regards, > Laszlo/GCS > [1] https://people.debian.org/~gcs/apt-src_0.25.4.tar.xz Thanks. I'll try to have a look, but this might not be before the weekend. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1073483: Intent to NMU apt-src to fix its trivial FTBFS bug
Hello László, Am Sun, Sep 01, 2024 at 08:10:22PM +0200 schrieb László Böszörményi (GCS): > On Sun, Sep 1, 2024 at 6:33 PM Helge Kreutzmann wrote: > > If anything is unclear, I'm happy to resolve this. > I started the update back then. Soon I got stuck, the current state You can contact me. We can also go step by step, i.e. first resolve the release critical bug. At which step did you run into problems? > is online [1]. The pod can't be processed and in the next few days I > don't have time to look at it. > [1] dget -x https://people.debian.org/~gcs/apt-src_0.25.4.dsc Unfortunately, this does not work (for me): apt-src_0.25.4.dsc: dscverify: apt-src_0.25.4.dsc failed signature check: gpg: no valid OpenPGP data found. gpg: the signature could not be verified. Please remember that the signature file (.sig or .asc) should be the first file given on the command line. Validation FAILED!! Do you maybe have git repository I could clone? Or can you tar up the the current state and make it available somewhere? Thanks for working on it. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1073483: Intent to NMU apt-src to fix its trivial FTBFS bug
Hello László, Am Mon, Jul 29, 2024 at 03:20:55PM +0200 schrieb László Böszörményi (GCS): > On Mon, Jul 29, 2024 at 3:18 PM Helge Kreutzmann wrote: > > I intent to NMU apt-src to fix its trivial FTFBS bug (essentially a > > recode latin1..utf8 is the fix). > Please just provide all the patches and I can review those. Then I > will upload the package, giving you all the credits of course. Ping? If anything is unclear, I'm happy to resolve this. Please note this is a two step process: 1) You review the changes and apply them, possibly with an uplaod. 2) I then unfuzzy all translations and request updates, once they arrived, a (2nd) upload needs to happen. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1073483: Intent to NMU apt-src to fix its trivial FTBFS bug
Hello László,
Am Mon, Jul 29, 2024 at 03:20:55PM +0200 schrieb László Böszörményi (GCS):
> Nice to see you again at DebConf.
Sorry, I'm not there.
> On Mon, Jul 29, 2024 at 3:18 PM Helge Kreutzmann wrote:
> > I intent to NMU apt-src to fix its trivial FTFBS bug (essentially a
> > recode latin1..utf8 is the fix).
> Please just provide all the patches and I can review those. Then I
> will upload the package, giving you all the credits of course.
Sure.
Here is it step by step:
* Recode French addendum into UTF-8 (closes: 1073483).
Simply execute
recode latin1..utf8 ./man/apt-src.add.fr
* Add German man page translation (closes: 1026782).
Drop the file provided in bug 1026782 into ./man/po/
You will need to update both Makefile.PL as well man/po4a.cfg, the
complete patch is below (for all languages).
* And also add German addendum.
This I wrote from scratch because I realized that it sensible to have,
I attached this file.
* Add Dutch man page translation (closes: 1070916).
Drop the file provided in bug 1070916 into ./man/po/ and gunzip it.
You will need to update both Makefile.PL as well man/po4a.cfg, the
complete patch is below (for all languages).
* Add Portuguese man page translation (closes: 980162).
Drop the file provided in bug 980162 into ./man/po/ and gunzip it.
You will need to update both Makefile.PL as well man/po4a.cfg, the
complete patch is below (for all languages).
The build system of apt-src is not very flexible regarding po4a.
Instead of replacing it with a flexible version I simply updated the
current build code as follows:
--- apt-src-0.25.3/Makefile.PL 2021-01-10 13:41:24.0 +0100
+++ apt-src-0.25.3.1/Makefile.PL2024-07-29 13:47:47.904304104 +0200
@@ -5,7 +5,10 @@
'EXE_FILES' => ['apt-src'],
'MAN1PODS' =>
{ 'man/apt-src.pod' => 'man/apt-src.1',
+ 'man/apt-src.de.pod' => 'man/apt-src.de.1',
'man/apt-src.es.pod' => 'man/apt-src.es.1',
+ 'man/apt-src.nl.pod' => 'man/apt-src.nl.1',
+ 'man/apt-src.pt.pod' => 'man/apt-src.pt.1',
'man/apt-src.fr.pod' => 'man/apt-src.fr.1', },
'clean' =>
{ FILES => "man/apt-src*.1 man/apt-src.*.pod"},
--- apt-src-0.25.3/man/po4a.cfg 2021-01-10 13:41:24.0 +0100
+++ apt-src-0.25.3.1/man/po4a.cfg 2024-07-29 13:48:37.548494119 +0200
@@ -1,3 +1,7 @@
-[po4a_paths] man/po/apt-src.pot fr:man/po/fr.po es:man/po/es.po
+[po4a_paths] man/po/apt-src.pot de:man/po/de.po es:man/po/es.po
fr:man/po/fr.po nl:man/po/nl.po pt:man/po/pt.po
[type: pod] man/apt-src.pod fr:man/apt-src.fr.pod add_fr:man/apt-src.add.fr \
- es:man/apt-src.es.pod add_es:man/apt-src.add.es
+ es:man/apt-src.es.pod add_es:man/apt-src.add.es \
+ de:man/apt-src.de.pod add_de:man/apt-src.add.de \
+ nl:man/apt-src.nl.pod \
+ pt:man/apt-src.pt.pod
* Resolve issues in apt-src man page (closes: 1026896).
I basically implemented the patch described in 1026896, however, with
some further tweaks.
I attached the patch.
Mostly editorial, but the pine → mutt change and my (small) change
regarding make-kpkg might draw your attention.
If you are fine with this patch (or a derived version of it) then
I will provide you with two more changes:
* Unfuzzy all translations
Currently, you build fails because all translations are outdated. Most
changes proposed, however, can be easily updated for all langauges. It
is just a bit of routine work, and you will get patches for all po
files.
* Requeste updates from translators
Very few updated strings (maybe only one or two) require attention
from a real translator. I would ask them to send in the updates. I
would give them ~ 2 weeks to make these small updates, and then could
can upload.
There is one more change I would like to do. debian/copyright is not
in the modern format, but instead of researching all contributors I
would like to propose the following patch (which needs updates, once
the translators responded):
--- apt-src-0.25.3/debian/copyright 2003-10-15 04:24:26.0 +0200
+++ apt-src-0.25.3.1/debian/copyright 2024-07-29 13:31:03.523369786 +0200
@@ -7,3 +7,12 @@
On Debian systems, the complete text of the GPL is in the file
/usr/share/common-licenses/GPL
+
+The man page of apt-src was translated into the following languages:
+Dutch Frans Spiesschaert 2024
+French Valery Perrin 2003
+ Julien Louis 2007
+German Helge Kreutzmann 2022,2024
+Portuguese Américo Monteiro 2021
+SpanishRuben Porras 2003,2004
That's it.
If you have any questions please let me know.
Greetings
Helge
--
Dr. Helge Kreutzmann
Bug#1073483: Intent to NMU apt-src to fix its trivial FTBFS bug
Hello Laszlo, I intent to NMU apt-src to fix its trivial FTFBS bug (essentially a recode latin1..utf8 is the fix). I will include the missing translations and update the man page, i.e. the changelog will look similiar to: * Recode French addendum into UTF-8 (closes: 1073483). * Add German man page translation (closes: 1026782). * And also add German addendum. * Add Dutch man page translation (closes: 1070916). * Add Portuguese man page translation (closes: 980162). * Resolve issues in apt-src man page (closes: 1026896). * Unfuzzy all translations where possible If you feel this NMU should not happen, please let me know ASAP. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1072643: Po4a needs to announce stricter parsing of config files
reopen 1072643
severity 1072643 important
found 1072643 0.72
thanks
Hello Martin,
Am Thu, Jun 13, 2024 at 12:26:53AM +0200 schrieb Martin Quinson:
> I think that the fix applied to #1072594 (recoding the input file from latin-1
> to UTF-8) was not necessary. Changing the config of po4a to correctly specify
> the used encoding would have worked.
>
> I tried to improve the error messages upstream to help future users to debug
> such issues, but in any case, this does not justify a RC bug against po4a,
> thus
> closing.
I'm not arguing the severity (I left it intentionally to you after
closing), but there still is a bug. I leave this to you and Santiago,
but making several pages suddenly FTBFS is IMHO at least serious.
For several years (probably something like 10 years) this worked
without problem, now it fails (and with a very strange message). If
the previous po4a was buggy, i.e. allowed broken config files, then a
warning or NOTE during updates would be mandated, but switching this
(inadverently, probably) to a strange or even fatal error message is
not sufficient.
Here is the statement from Santiago:
From: Santiago Vila
To: 1072...@bugs.debian.org, Helge Kreutzmann
Subject: Regression: po4a fails on valid non-utf8 file
Date: Wed, 5 Jun 2024 19:03:48 +0200
(Adding this note to the cloned bug)
Note: If you take a look at the FTBFS bugs I reported yesterday:
https://people.debian.org/~sanvila/build-logs/202406/?C=M;O=A
you can see that several of them are also a consequence of this change in po4a.
So, I fully support that this kind of behaviour change deserves
at least an entry in NEWS.Debian.
Thanks.
So no, this bug is not closed.
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#1072594: goobox: FTBFS: UTF-8 "xFC" does not map to Unicode at /usr/share/perl5/Locale/Po4a/Po.pm line 353, <$fh> line 114.
clone 1072594 -1 reassign -1 po4a retitle -1 Regression: po4a fails on valid non-utf8 file tags 1072594 + pending thanks Sorry, forgot to actually use the real bug number … -- 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/ signature.asc Description: PGP signature
Bug#1072594: goobox: FTBFS: UTF-8 "xFC" does not map to Unicode at /usr/share/perl5/Locale/Po4a/Po.pm line 353, <$fh> line 114.
clone 12345 -1
reassign -1 po4a
retitle -1 Regression: po4a fails on valid non-utf8 file
tags 12345 + pending
thanks
Hello Santiago,
hello Po4a maintainers,
excuse the TOFU. The build of goobox currently fails on a po file
encoded in ISO-8859-15. The package builds with this file since at
least 2015, with previous version since 2007. Reading the changelog
(NEWS.gz) I cannot detect any depreciation of ISO-8859-15 files. So
this is a regression introduced with po4a 0.72 (or earlier, not all
previous version were shipped for Debian).
The relevant file (attached) does not show any error, i18nspector
reads it fine and recode latin1..utf8 on the file neither prints an
error.
The fix (workaround) for goobox is simple, recode the file to UTF-8.
I'll prepare an upload probably this weekend.
I thus cloned this bug, for goobox to get building again and for po4a
to fix the regression (or clearly depreciating non utf8 locales, with
appropriate NEWS entry etc.). This might affect lots of users of "old"
translations.
Am Wed, Jun 05, 2024 at 02:16:47AM +0200 schrieb Santiago Vila:
> Package: src:goobox
> Version: 3.6.0-11
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> [...]
> debian/rules build
> dh build
>dh_update_autotools_config
>dh_autoreconf
>dh_auto_configure
> cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8
> meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr
> --sysconfdir=/etc --localstatedir=/var --libdir=lib/x86_64-linux-gnu
> -Dpython.bytecompile=-1
> The Meson build system
> Version: 1.4.1
> Source dir: /<>
> Build dir: /<>/obj-x86_64-linux-gnu
> Build type: native build
> Project name: goobox
> Project version: 3.6.0
> C compiler for the host machine: cc (gcc 13.2.0 "cc (Debian 13.2.0-25)
> 13.2.0")
> C linker for the host machine: cc ld.bfd 2.42
> Host machine cpu family: x86_64
> Host machine cpu: x86_64
> Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
> Run-time dependency libcoverart found: YES 1.0.0
> Configuring config.h using configuration
> Build-time dependency gio-2.0 found: YES 2.80.2
> Program /usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas found: YES
> (/usr/lib/x86_64-linux-gnu/glib-2.0/glib-compile-schemas)
> Configuring org.gnome.Goobox.desktop.in using configuration
> Program msgfmt found: YES (/usr/bin/msgfmt)
> Program itstool found: YES (/usr/bin/itstool)
> Program msgmerge found: YES (/usr/bin/msgmerge)
> Program msgfmt found: YES (/usr/bin/msgfmt)
> Program msginit found: YES (/usr/bin/msginit)
> Program msgmerge found: YES (/usr/bin/msgmerge)
> Program xgettext found: YES (/usr/bin/xgettext)
> Library m found: YES
> Run-time dependency threads found: YES
> Run-time dependency glib-2.0 found: YES 2.80.2
> Run-time dependency gthread-2.0 found: YES 2.80.2
> Run-time dependency gtk+-3.0 found: YES 3.24.42
> Run-time dependency gstreamer-1.0 found: YES 1.24.4
> Run-time dependency libbrasero-media3 found: YES 3.12.3
> Run-time dependency libmusicbrainz5 found: YES 5.1.0
> Run-time dependency libdiscid found: YES 0.6.4
> Compiler for C supports arguments -Wall: YES
> Dependency gio-2.0 found: YES 2.80.2 (cached)
> Program /usr/bin/glib-compile-resources found: YES
> (/usr/bin/glib-compile-resources)
> Dependency glib-2.0 found: YES 2.80.2 (cached)
> Program /usr/bin/glib-genmarshal found: YES (/usr/bin/glib-genmarshal)
> Message: configuration summary:
>
>project: goobox 3.6.0
> prefix: /usr
>libcoverart: true
>
> Build targets in project: 95
> NOTICE: Future-deprecated features used:
> * 0.56.0: {'meson.source_root'}
>
> goobox 3.6.0
>
> User defined options
> buildtype : plain
> libdir: lib/x86_64-linux-gnu
> localstatedir : /var
> prefix: /usr
> sysconfdir: /etc
> wrap_mode : nodownload
> python.bytecompile: -1
>
> Found ninja-1.12.1 at /usr/bin/ninja
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> dh_auto_build
> cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j2 -v
> [1/104] /usr/bin/glib-compile-resources ../src/goobox.gresource.xml
> --sourcedir ../src --c-name goo --internal --generate --target
> src/goo-resources.c --dependency-file src/goo-resources.c.d
> [2/104] /usr/bin/glib-compile-resources ../src/goobox.gresource.xml
> --sourcedir ../src --c-name goo --internal --generate --target
> src/goo-resources.h
> [3/104] /usr/bin/msgfmt ../help/ca/ca.po -o help/ca/goobox-ca.gmo
> [4/104] /usr/bin/msgfmt ../help/cs/cs.po -o help/cs/goobox-cs.gmo
> [5/104] /usr/bin/msgfmt ../help/de/de.po -o help/de/goobox-de.gmo
> [6/104] /usr/bin/msgfmt ../help/el/el.po -o help/el/goobox-el.gmo
> [7/104] /usr/bin/msgfmt ../help/es/es.po -o help/es/goobox-es.gmo
> [8/104] /usr/bin/g
Bug#1072594: goobox: FTBFS: UTF-8 "xFC" does not map to Unicode at /usr/share/perl5/Locale/Po4a/Po.pm line 353, <$fh> line 114.
Hello Santiago, Am Wed, Jun 05, 2024 at 02:16:47AM +0200 schrieb Santiago Vila: > During a rebuild of all packages in unstable, your package failed to build: Thanks for notifying me. … > po4a::sgml: Warning: onsgmls produced some errors. This is usually caused by > po4a, which modifies the input and restores it afterwards, causing the input > of onsgmls to be invalid. This is usually safe, but you may wish to verify > the generated document with onsgmls -wno-valid. > po4a::sgml: To see the error message, rerun po4a with this additional > argument: >-o debug=onsgmls > UTF-8 "\xFC" does not map to Unicode at /usr/share/perl5/Locale/Po4a/Po.pm > line 353, <$fh> line 114. > (108 entries) Looks like the updated po4a causes this. I'll investigate in the next days. > If this is really a bug in one of the build-depends, please use > reassign and affects, so that this is still visible in the BTS web > page for this package. At first sight I'll assume this, after investigation I'll take care of this. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1042484: also affects manpages-de
Hello all, On Sat, Jul 29, 2023 at 10:20:40AM +, Holger Levsen wrote: > this also affects manpages-de: … and others. I'm already fixing it, no need to file further bugs atm (i.e. before -6 is uploaded). Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1042484: util-linux-locales: /usr/share/man/fr/man1/lastb.1.gz is also in package manpages-fr 4.19.0-5
Hello Vincent, On Sat, Jul 29, 2023 at 12:40:41PM +0200, Vincent Lefevre wrote: > On 2023-07-29 12:06:01 +0200, Helge Kreutzmann wrote: > > Hello Vincent, > > On Sat, Jul 29, 2023 at 11:48:57AM +0200, Vincent Lefevre wrote: > > > So I would say that this is rather a bug in src:manpages-l10n > > > 4.19.0-5 (the new version meant to be compatible with > > > util-linux-locales 2.39.1-3). Or am I missing something? > > > > It is supposed to be deleted, but retained as broken symlink. I have a > > vague idea what might have happened, but I need to investigate. > > The links are added by dh_link, with the .gz extension: Yes, I'm already in the process of updating my build rules. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1042484: util-linux-locales: /usr/share/man/fr/man1/lastb.1.gz is also in package manpages-fr 4.19.0-5
Hello Vincent, On Sat, Jul 29, 2023 at 11:48:57AM +0200, Vincent Lefevre wrote: > CC'ed Helge Kreutzmann (maintainer of manpages-l10n). > > On 2023-07-29 07:30:30 +0200, Jean-Marc wrote: > > Package: util-linux-locales > > Version: 2.39.1-3 > > Severity: serious > > Justification: 6 > > X-Debbugs-Cc: jean-m...@6jf.be > > > > Dear Maintainer, > > > > Upgrading util-linux-locales from 2.38.1-6 to 2.39.1-3 failed and returned > > this error message: > > > > Preparing to unpack .../util-linux-locales_2.39.1-3_all.deb ... > > Unpacking util-linux-locales (2.39.1-3) over (2.38.1-6) ... > > dpkg: error processing archive > > /var/cache/apt/archives/util-linux-locales_2.39.1-3_all.deb (--unpack): > > trying to overwrite '/usr/share/man/fr/man1/lastb.1.gz', which is also in > > package manpages-fr 4.19.0-5 > > Errors were encountered while processing: > > /var/cache/apt/archives/util-linux-locales_2.39.1-3_all.deb > > If I understand correctly, lastb was expected to move from > manpages-l10n to util-linux-locales: Yes. > So I would say that this is rather a bug in src:manpages-l10n > 4.19.0-5 (the new version meant to be compatible with > util-linux-locales 2.39.1-3). Or am I missing something? It is supposed to be deleted, but retained as broken symlink. I have a vague idea what might have happened, but I need to investigate. I'll try to find out and if possible upload -6 to fix this today. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#973850: lilo: Should not be included in bullseye
Hello Joachim, hello Simon, On Mon, Sep 13, 2021 at 09:35:08PM +0200, Joachim Wiedorn wrote: > Simon McVittie wrote on 2021-09-12 22:43: > > > Now that bullseye has been released, should lilo be removed from unstable > > so that it will not be in any future Debian release either? > > I think the package should stay for a time in unstable, say 12 months? > There a some people managing many server and still use lilo as boot > manager. They should find it for a longer time. More than 12 months have passed, bookworm (bullsye+1) has been released. > > If so, the way to do that is to report a RM bug against the ftp.debian.org > > pseudo-package. I can help with this if you would like. > > I think I will do it in the autumn of 2022. And summer 2023 (at least in Germany) is now in force. So maybe the time has come? At least I will disable the translation for the lilo man pages, so Trixie will no longer ship those … Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1034958: Consequence of #951598
tags 1034958 + patch thanks On Sat, Apr 29, 2023 at 06:42:44PM +0200, Marco d'Itri wrote: > On Apr 29, Helge Kreutzmann wrote: > > > Reverse, I believe manpages-dev should declare: > > Breaks: inn2-dev (<< 2.7.0-1) > > Replaces: inn2-dev (<< 2.7.0-1) > > > > Is this fine for you? > Yes. -- 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/ signature.asc Description: PGP signature
Bug#1034958: Consequence of #951598
Hello Marco, thanks for your speedy reply. On Sat, Apr 29, 2023 at 06:26:21PM +0200, Marco d'Itri wrote: > Would this work for you? Please let me know ASAP since the hard freeze > is very close. > > Package: inn2-dev > Breaks: manpages-dev (<< 6.03-2) I'm not the maintainer of manpages, but this would be logically the correct solution and I'm quite sure that this is the correct one. Reverse, I believe manpages-dev should declare: Breaks: inn2-dev (<< 2.7.0-1) Replaces: inn2-dev (<< 2.7.0-1) Is this fine for you? Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1034958: Consequence of #951598
Hello *, I had a look at this RC bug. The problem was detected in #1004888 on the inn2 side and properly resolved within the package, however, as the fix was not coordinated with manpages, no package relationships were set (see below). On the manpages side this was dealt (partially) with in #951598. See https://bugs.debian.org/cgi-bin/bugreport.cgi?att=0;bug=951598;msg=16 and the final changelog entry: * Reinstall file.3 as it is no longer conflicts with newer release of inn2-dev. However, this neither introduced the correct package relationships as documented here: https://wiki.debian.org/PackageTransition This sitaution is #9 in the above wiki page, requiering both packages to act on. Thus manpages needs another upload containing (only) the fixed package relationship. Similarly, inn2 needs the correct pacakge relastionships as well (in a coordinated fashion). If you need help preparing this trivial fix please let me know[1]. Greetings Helge [1] Tobias, guess who would be sponsoring it so maybe a MU is much quicker :-)) -- 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/ signature.asc Description: PGP signature
Bug#1031379: Works on my machine
Hello, I'm also using it on amd64 and it works without any noticable problems. I would first check if the TV card works at all. I initially had some problems, but these are not related to kaffeine. So I suggest to downgrade this bug and tag it +moreinfo. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1031786: logcheck: Filtering not working with entries from journald
Package: logcheck Version: 1.4.1 Severity: grave Justification: renders package unusable The change for #1025719 broke logcheck massively. I've extensivly tuned logcheck files which nicely filter out lots of messages (see statistics at the end). Now I see them all again (only those comming from the journal). I don't see any information what I should do for migration. Let's use a trivial example. The following harmless message is emitted by courier to the journal: Feb 22 16:37:40 meinfjell courierd[401638]: Installing uucp In syslog this is: syslog:2023-02-22T14:37:40.491690+00:00 meinfjell courierd: Installing uucp I have the following in /etc/logcheck/ignore.d.server: meinfjell courierd: Initializing uucp As you can see, the message from the journal is slightly different than from syslog, breaking tons of rules. If such a feature is introduced, it should definitely have a switch so that admins can decide when to change (requires adapting many rules). Filtering both looks very impractical. For statistics: On my local system, I have 11396 lines of rules, on my server system currently 2721 (I'm in the processing of setting this up, so this will grow). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.9 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages logcheck depends on: ii adduser3.131 ii cron [cron-daemon] 3.0pl1-156 ii exim4-daemon-light [mail-transport-agent] 4.96-14 ii lockfile-progs 0.1.19 ii logtail1.4.1 ii mime-construct 1.12+really1.11-1 Versions of packages logcheck recommends: ii logcheck-database 1.4.1 Versions of packages logcheck suggests: ii rsyslog [system-log-daemon] 8.2212.0-1 -- Configuration Files: /etc/logcheck/header.txt [Errno 13] Keine Berechtigung: '/etc/logcheck/header.txt' /etc/logcheck/logcheck.conf [Errno 13] Keine Berechtigung: '/etc/logcheck/logcheck.conf' /etc/logcheck/logcheck.logfiles [Errno 13] Keine Berechtigung: '/etc/logcheck/logcheck.logfiles' /etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Keine Berechtigung: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles' /etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Keine Berechtigung: '/etc/logcheck/logcheck.logfiles.d/syslog.logfiles' -- no debconf information -- 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/ signature.asc Description: PGP signature
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
Hello Paul, On Thu, Feb 16, 2023 at 11:20:18AM +0100, Paul Gevers wrote: > On Thu, 12 Jan 2023 07:36:33 +0100 Helge Kreutzmann > wrote: > > I expect upstream to release "this weekend" - but this might be > > actually next monday/tuesday. > > > > Then I might take a day or two to package this for unstable. > > I think this happened in version 4.17.0-1 and 2. The latter migrated to > testing on 25 January, right? Can we close this bug? From my side (i.e., manpages-l10n) everything has happend (this was tracked in a cloned bug), especially in backports. There is one small issue left, so I probably will issue another backport upload this weekend, but otherwise - this is (hopefully) completely resolved. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
Hello Sebastian,
On Fri, Feb 10, 2023 at 09:25:08PM +, Thorsten Glaser wrote:
> Sebastian Andrzej Siewior dixit:
>
> >How is this getting to work without manpages-fr contributing to it?
>
> By adding a conflict (can’t remember if it has to be Conflicts or Breaks
> will also work) plus Replaces on manpages-fr (<< 4.17.0-2~bpo11+1) on
> xz-utils in bookworm. (And the others similarily.)
And please remember to make the same for manpages-de (sorry, if that
was obvious).
Thanks!
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
Hello Sebastian, On Fri, Feb 10, 2023 at 08:06:38PM +0100, Sebastian Andrzej Siewior wrote: > On 2023-02-01 17:59:57 [+], Thorsten Glaser wrote: > > > xz-utils (5.4.1-0.1) unstable; urgency=medium > > > . > > > * Non-maintainer upload. > > > * Update pt_BR translations. > > > * Add lintian overrides and an override for blhc. > > > > This is missing the updated Breaks+Replaces for manpages-l10n though. > > That is correct, I wanted to wait until the bpo packages gets accepted > as discussed with Helge. > Now with the bpo package accepted I did a test from bullseye -> sid and > from the log: > > | $ grep -E 'manpages-fr|xz-utils' screenlog.0 > | dpkg -l manpages-fr xz-utils > | ii manpages-fr4.17.0-2~bpo11+1 all French man pages > | ii xz-utils 5.2.5-2.1~deb11u1 amd64XZ-format compression > utilities > | logrotate logsave lsb-base lsb-release lsof mailcap man-db manpages > manpages-fr manpages-fr-dev mawk media-types mount nano ncurses-base > ncurses-bin ncurses-term netbase > | util-linux-locales vim-common vim-tiny wamerican wget whiptail xauth > xdg-user-dirs xkb-data xxd xz-utils zlib1g > | Get:277 http://httpredir.debian.org/debian sid/main amd64 manpages-fr all > 4.17.0-2 [1,926 kB] > | Get:278 http://httpredir.debian.org/debian sid/main amd64 xz-utils amd64 > 5.4.1-0.1 [468 kB] > | Get:279 http://httpredir.debian.org/debian sid/main amd64 manpages-fr-dev > all 4.17.0-2 [2,489 kB] > | dpkg: considering removing manpages-fr in favour of xz-utils ... > | dpkg: yes, will remove manpages-fr in favour of xz-utils > | Preparing to unpack .../066-xz-utils_5.4.1-0.1_amd64.deb ... > | Unpacking xz-utils (5.4.1-0.1) over (5.2.5-2.1~deb11u1) ... > | Removing manpages-fr (4.17.0-2~bpo11+1), to allow configuration of xz-utils > (5.4.1-0.1) ... > | Selecting previously unselected package manpages-fr. > | Preparing to unpack .../067-manpages-fr_4.17.0-2_all.deb ... > | Unpacking manpages-fr (4.17.0-2) ... > | Preparing to unpack .../068-manpages-fr-dev_4.17.0-2_all.deb ... > | Unpacking manpages-fr-dev (4.17.0-2) over (4.17.0-2~bpo11+1) ... > | Setting up manpages-fr-dev (4.17.0-2) ... > | Setting up xz-utils (5.4.1-0.1) ... > | Setting up manpages-fr (4.17.0-2) ... > > So it works as intended. Therefore I would close this bug report. > Any disagreement? From the manpages-l10n side everything is in place, I would then also properly close #1028233. (Uploads to bpo do not manipulate the BTS). Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Thorsten,
On Wed, Feb 01, 2023 at 04:03:12PM +, Thorsten Glaser wrote:
> Helge Kreutzmann dixit:
>
> >> >odler than stable. It also shipped them in every backport until
> >> >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1.
> >> >
> >> >But I wonder if I should remove them there.
> >>
> >> Yes, please. Otherwise it’s impossible to do the package
>
> >Done in the upcoming 4.17.0-2~bpo11+1.
> >
> >For the three languages where we have a conflict, namely, de, fr and
> >uk.
>
> Okay. So, assuming no newer version of manpages-{de,fr,uk} will
> bring them in, in either bpo or bookworm/sid, xz-utils now needs
> Replaces+Breaks on manpages-{de,fr,uk} (<< 4.17.0-2~bpo11+1) in sid.
> (Also assuming 4.17.0-2 does not have them.)
>
> That is, from the xz-utils PoV 4.17.0-2~bpo11+1 and 4.17.0-2
> are the first “fixed” (as in, don’t ship conflicting files)
> versions and all later ones will not “regress”.
The removal is intended to stay in the package.
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Thorsten, On Wed, Feb 01, 2023 at 03:11:19PM +, Thorsten Glaser wrote: > Helge Kreutzmann dixit: > > >odler than stable. It also shipped them in every backport until > >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1. > > > >But I wonder if I should remove them there. > > Yes, please. Otherwise it’s impossible to do the package > relationships right. This will leave users of xz-utils from > stable with manpages-fr from backports without french xz > manpages, but it’s the only way to do this that doesn’t > cause worse trouble elsewhere. Done in the upcoming 4.17.0-2~bpo11+1. For the three languages where we have a conflict, namely, de, fr and uk. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Sebastian, lets clarify the facts: Xz-utils ships the localized manpages since 5.2.7. I do not see any backport yet, I assume it will be 5.4.1-0.0~bpo11+1 manpages-l10n shipped the localized manpages before 4.1.0-1. This is odler than stable. It also shipped them in every backport until 4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1. But I wonder if I should remove them there. Please tell me, which languages you (intend to) ship in the backport. On Tue, Jan 31, 2023 at 09:50:20AM +, Thorsten Glaser wrote: > Sebastian Andrzej Siewior dixit: > > >It is bpo but if you look I'd you look at the files for the same > >version in bpo and sid you will see that sid skipped a few man pages > >while bpo created them. > > Ouch! > > That adds to the problems, of course. That makes fully resolving > this in all possible combinations a nightmare. > > In general, these have to go: Let's try: > stable → next-stable No problem, manpages-l10n never shipped it in stable and next-stable. > stable → stable+backports I assume if I *remove* the xz manpages for 4.17.0-2~bpo11+1, then users upgrading manpages-l10n and/or xz-utils get the translations from xz-utils (no longer from manpages-l10n). I keep the conflict, in case they take xz-utils with manpages-l10n 4.16.0-3~bpo11+1 installed. > stable+backports → next-stable The conflict in manpages-l10n backports ensures that it is not co-installed with xz-utils in next-stable. > stable+backports → stable+backports+backports-sloppy I don't know "stable+backports+backports-sloppy" and I never uploaded to -sloppy. > stable+backports+backports-sloppy → next-stable+backports Dito. > stable → testing (at any point) No problem, manpages-l10n never shipped the localizied man-pages in stable. > stable → unstable (at any point) The same. > testing → testing (at any point) The same. > testing → unstable (at any point) The same. > unstable → unstable (at any point) The same. > testing (at any point) → next-stable The same. > stable+backports → testing (at any point) The conflict in the upcoming manpages-l10n 4.17.0-2~bpo11+1 should ensure this. > stable+backports → unstable (at any point) The same. > In addition, partial upgrades that do not span more than a release > either way need to work (so you could have, say, manpages-fr from > buster and xz-utils from sid(before the bookworm release), or vice > versa, on one single bullseye system). I think these are covered in your considerations above. > Explicit Depends are needed to make all these either work or the > package manager not consider them (which forces upgrading a part > of the system to match). In addition, Build-Depends need versioning > unless present in stable, better oldstable, because buildds are not > required to upgrade (only update) before a run, plus packages can be > lagging on some architectures. I don't see any depends involved here, Replaces/Breaks and conflicts should suffice. There should not be any problems with build-depends. > Now backports take from testing at the point of backporting. > If the backported packages significantly differ from the > package in testing, however, combinatory explosion, as the > above holds true for every single package… This is what we try to tame here, yes. And I hope we did it right. > In particular, I’ve personally held back from backporting > packages when I know I had versioned constraints on the > package in question but backporting would require bringing > the old behaviour back (i.e. the backported package needs > to behave like the new one, not the old one, and if that’s > not possible in the old distro, then don’t package it). Translations need to mirror the english content. If that evolves in backports, then so do need the translations. > I see why this would be a problem for manpages… but you > cannot re-enable manpages in bpo that aren’t in testing > meaningfully when there’s also a backport of the package > from testing that includes the manpage (and you cannot > meaningfully drop the manpage from the backport because > then the package relationships aren’t possible any more). Yes, this is the first time a translation moved packages *and* there was a backport of said package (here: xz-utils). > Good luck, Thanks Greetings -- 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/ signature.asc Description: PGP signature
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Hello Sebastian, On Mon, Jan 30, 2023 at 07:53:51PM +0100, Sebastian Andrzej Siewior wrote: > On 2023-01-30 18:04:35 [+], Thorsten Glaser wrote: > > reopen 1028375 > > found 1028375 5.4.1-0.0 > > thanks > > > > Patrice Duroux dixit: > > > > >Was this supposed to be closed? Or will it be with another manpages-fr bpo? So far the manpages-fr bpo has not yet happend. My sponsor intends to upload it today and then we need to wait for NEW processing. > > 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) > > so the upload did not fix the problem. > > > > As far as I can tell it must be (<< 4.17.0-1~) instead. > > (Also do note the tilde, it breaks bpo otherwise.) > > Okay. So I add this new suggested version and close 1028375? The problem is that we both upload (conflicting) packages to backports. I'm not sure a good solution exists here. If the freeze continues for quite some time, even 4.18.0-1~ might hit backports. (In the last freeze it was the case.). This is rather tricky. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1029174: Bug#1029176: please check dhcpcd 9.4.1-14 in unstable
Hello all,
On Thu, Jan 19, 2023 at 09:22:45PM +0100, Beat Bolli wrote:
> On 19.01.23 16:35, Martin-Éric Racine wrote:
> > We've just pushed dhcpcd 9.4.1-14 into unstable. Can you please check
> > whether that fixes it?
>
> Indeed, this new version works.
>
> Thanks!
The same for me - it works and thanks!
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#1029174: dhcpcd-base: Brakes networking completely
Package: dhcpcd-base
Version: 9.4.1-13
Severity: grave
Justification: renders package unusable
When this version is installed, all networking is broken, e.g.
root@twentytwo:~# LC_ALL=C ping lwn.net
ping: lwn.net: Temporary failure in name resolution
I cannot access *any* outside resource. No IP, no ssh, no ping, ..
Additionally, comands involving network state take several minutes,
i.e. running into timeouts. E.g.
systemctl restart networking
Or shutdown takes several minutes (for each interface) before
completion.
If I strace such a command, I see:
access("/run/network/ifstate.enp3s0", R_OK) = 0
openat(AT_FDCWD, "/run/network/ifstate.enp3s0",
O_RDWR|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = 3
fcntl(3, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}) = -1
EAGAIN (Die Ressource ist zur Zeit nicht verfügbar)
write(2, "ifdown: ", 8ifdown: ) = 8
write(2, "waiting for lock on /run/network"..., 47waiting for lock on
/run/network/ifstate.enp3s0) = 47
write(2, "\n", 1
) = 1
fcntl(3, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}
And there it hangs. (I did not search if this is the only place for
hangs, but it was the first).
Downgrading to 9.4.1-11 fixes the problem, i.e. the machine behaves
normally after reboot.
This is reproducible, i.e. upgrading to -13 and rebooting and the
broken network is back; downgrading and rebooting and the network is
fine again.
Please tell me which data you need to further boil this down and I can
provide it.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages dhcpcd-base depends on:
ii adduser 3.130
ii libc6 2.36-8
ii libudev1 252.4-1
dhcpcd-base recommends no packages.
dhcpcd-base suggests no packages.
-- no debconf information
--
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/
signature.asc
Description: PGP signature
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
Hello Sebastian, On Wed, Jan 11, 2023 at 11:24:43PM +0100, Sebastian Andrzej Siewior wrote: > On 2023-01-11 21:01:11 [+0100], To Helge Kreutzmann wrote: > > > For your update you should use as version "<< 4.1.0-1". > > > (and remember to put it in for both manpages-de and manpages-fr) > > > > Okay, will do. > > Just to double check: This is what I did: > > https://salsa.debian.org/debian/xz-utils/-/commit/6d608a9e56921abbad77f07e9e0fe4bc78e93854 > > and you say that this is okay, right? I'm just checking that you really > meant 4.1.0-1 and not 4.10.0-1. I double checked. This is the last version of manpages-l10 which contained the templates for unstable/stable: ## Version 4.0.0 *Mon Mar 2 22:09:38 CET 2020* This is the first version of manpages-l10 which no longer contains the templates for unstable/stable (but for backports!). ## Version 4.1.0 *Wed Jul 1 12:26:57 CEST 2020* I did not check which man pages are actually shipped - this depends on how complete the translations are. If necessary, one would need to get the debs and review them. But I don't think this is necessary. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
Hello Sebastian, On Wed, Jan 11, 2023 at 11:16:45PM +0100, Sebastian Andrzej Siewior wrote: > On 2023-01-11 21:53:14 [+0100], Helge Kreutzmann wrote: > > Hello Sebastian, > Hello Helge, > > > Well, this is not correct. See, e.g., > > https://packages.debian.org/bullseye-backports/all/manpages-de/filelist > > > > The man pages are there. > > yes, in backports. Not in the "regular" package. This is true - I cannot change the regular package after release - I have to take what translators provided me at that point of time. This is what backports is for. > > We just took our probably final "snapshot". I.e. in the next backport > > version, the man page as it was on monday in backports (or stable, if > > backports was empty) is used as base. So this will be the final > > release in bullseye-backports from our side. > > > > I don't know what the best solution is here. I see several options, > > all not very nice: > > > > 1. xz-utils does not ship translated man pages in backports. But then > >the translated man page is out of sync with the package (it is a > >pity that the upload to backports has not been done, already). > > > > 2. I manually remove the translations in my final backport. Then there > >is no file conflict. For this case, please tell me which man pages > >I should delete. And the final version shipping it in backports > >from my side would be "4.16.0-3~bpo11+1". > > > >Please tell me which version is the first backport version of your > >package containing the translations, and I will set the appropriate > >file relationships myself; however, I don't know if all upgrade paths > >will work, but we can try. > > > >With "all upgrade paths" I mean the user can have backports for > >either package or none. > > Okay. Let me get to this and then I will talk to you again once the > release team gives an ack. Ack. Just for your information: I expect upstream to release "this weekend" - but this might be actually next monday/tuesday. Then I might take a day or two to package this for unstable. After migration ( ~ 5 days) I would like to prepare my backports, which would need the proper package relations. (But I can delay this a few days, if necessary, of course). Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1028233: xz-utils: tries to overwrite files in manpages-fr (4.16.0-3~bpo11+1)
Hello Sebastian, On Wed, Jan 11, 2023 at 09:01:10PM +0100, Sebastian Andrzej Siewior wrote: > On 2023-01-10 09:36:04 [+0100], Helge Kreutzmann wrote: > > On Mon, Jan 09, 2023 at 09:38:31PM +0100, Sebastian Andrzej Siewior wrote: > > > Oki. That means if I intend to upload xz-utils to Buster with translated > > > man-pages than I need to check with you first? > > This will note prevent this bug, but see below for this case. However, > > it will fix peoples systems not using backports and upgrading from > > bullseye to bookworm after release. > > > > And this also explains why this bug was not seen on our side: During > > this time maintainership both for upstream and for the Debian package > > transitioned to new persons. And when I got responsible, I simply did > > not realise this one was forgotten. > > > > For bullseye: > > Do you want to publish a backport for xz-utils? Then it gets > > complicated. > > I planned to upload the latest v5.2.X release to bullseye. Code wise it > contains only fixes. Feature wise it contains more translations. There is > a bug open in xz-utils that the man-page for xz vanished in xz-utils. It > was provided by manpages-de but the release in Bullseye does not have > it. > The release team does not know about it and I have no idea if they allow > so I'm checking with you first before i collides somehow with manpages-fr > ;) Well, this is not correct. See, e.g., https://packages.debian.org/bullseye-backports/all/manpages-de/filelist The man pages are there. Of course, only those we have (had) in manpages-l10n, but de definitely. We just took our probably final "snapshot". I.e. in the next backport version, the man page as it was on monday in backports (or stable, if backports was empty) is used as base. So this will be the final release in bullseye-backports from our side. I don't know what the best solution is here. I see several options, all not very nice: 1. xz-utils does not ship translated man pages in backports. But then the translated man page is out of sync with the package (it is a pity that the upload to backports has not been done, already). 2. I manually remove the translations in my final backport. Then there is no file conflict. For this case, please tell me which man pages I should delete. And the final version shipping it in backports from my side would be "4.16.0-3~bpo11+1". Please tell me which version is the first backport version of your package containing the translations, and I will set the appropriate file relationships myself; however, I don't know if all upgrade paths will work, but we can try. With "all upgrade paths" I mean the user can have backports for either package or none. > > > > Technically, we treat debian-unstable and debian-backport as if they > > > > were two different distributions (say arch and fedora). > > > > > > > > What got lost (and I will investigate this later this week, maybe > > > > tomorrow) are the correct package relations. I have a vague idea, but > > > > I will check. And the next upload (including the one to bpo) will have > > > > the correct ones. > > > > > > Since "recently" xz provides translated man-pages and sid is not > > > affected. My understaning is that the bpo version of man-pages gets a > > > breaks statement against xz. If so that would >= 5.2.7. > > > Should I reassing the bug to manpages-l10n or do you do it yourself? > > > > Will be done, see above. And given that upstream got the translated man > > pages in April 2020, I understand the quotes around "recently". > > > > From your changelog I gathered the version "(<< 5.3.3alpha-0.0)". > > The man-pages started to appear in 5.2.7 which I uploaded to unstable at > the time. It was later superseded by the 5.3-beta series which become > 5.4 (non-beta) and was cooked at the same time in experimental. I fixed this for my upcoming package. > … > > As a side note: > > We have man page translations for several other languages as well. > > Over time, they will disappear, so I suggest to move them to xz-utils > > as well. I can send the po files to you and inform the translators > > about this, if you want. Then you can include them in your next upload > > (to fix bug "-1") as well. > > I would forward them to upstream if there is anything. Right now there > are man pages in ro/de/fr. Will do. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1026477: Not reproducible on testing
Hello Markus, I just rebuild mediathekview (successfully) on Testing (on amd64). As this failure is from ~ 2 weeks ago, I find this strange (I would have expected the cause to be migrated to testing already). If there is something I could try/do to support you in keeping mediathekview in bookworm, please tell me. Unfortunately, I'm not a (java) programmer, but maybe some testing could help. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
Hello Thorsten,
On Thu, Sep 01, 2022 at 06:39:18PM +0200, Thorsten Glaser wrote:
> > For Debian, as stated above, I can do another upload removing this
> > file as well.
>
> Thanks. Feel free to reassign/close this bug at will then… or do we
> need another sysvinit upload with updated Replaces/Breaks/… as well,
> Andreas?
The upload of manpages-l10n (manpages-fr) was just accepted in
unstable.
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
Hello Thorsten, On Thu, Sep 01, 2022 at 06:39:18PM +0200, Thorsten Glaser wrote: > […] > > Yes, that would be the best option. A few days ago I informed all > > translation teams about the transfer of translations to sysvinit, so > > if the French team could integrate the translation of bootlogd there, > > that'll be great. > > ok, great! > > > For Debian, as stated above, I can do another upload removing this > > file as well. > > Thanks. Feel free to reassign/close this bug at will then… or do we > need another sysvinit upload with updated Replaces/Breaks/… as well, > Andreas? I'll do the upload on the weekend. I guess the best is that you close it afterwards? Or reassign it to manpages-l10n? Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
Hello Torsten et al, On Wed, Aug 31, 2022 at 11:04:25PM +0200, Thorsten Glaser wrote: > On Wed, 31 Aug 2022, Mark Hindley wrote: > > > > there seems to be one manpage (in bootlogd) missing conflict handling: > > > > > > /usr/share/man/fr/man8/bootlogd.8.gz > > > > Thanks. I was under the impression that manpages-i10n had changed to > > systemd versions (which doesn't have bootlogd.8) but apparently not. I > > think we should continue to use the manpages-i10n version and not have > > any more dpkg diversions than are absolutely necessary. No. This is not the intention, quite the contrary. This file probably escaped me, because I did not realize that the package bootlogd originates from sysvinit. I can do another upload removing this file as well. > > I am away for a week, but will resolve this once I am back. > > Perhaps in this time a french speaker can compare the two versions, > from sysvinit and manpages-l10n, and see which one is “better”, then > contribute that to sysvinit so manpages-l10n can remove theirs as > bootlogd isn’t provided with systemd? Yes, that would be the best option. A few days ago I informed all translation teams about the transfer of translations to sysvinit, so if the French team could integrate the translation of bootlogd there, that'll be great. I suggest we keep this source file in the manpage l10n upstream repository for a few more weeks and then I ask upstream (Mario Blättermann) to move it to the archive. (Best if the French team would indicate a good time). For Debian, as stated above, I can do another upload removing this file as well. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found
Hello Markus,
On Tue, Aug 09, 2022 at 03:09:08PM +0200, Markus Koschany wrote:
> I have pushed a new branch which includes version 13.9.1.
…
> Those are the major issues we have to fix in order to package a new upstream
> release of mediathekview. And we also need to fix kotlin in unstable. If
> someone wants to help, that's our todo list.
This sounds like a plan. Unfortunately, I basically don't have a clue
on these issues, so I cannot help. Since I'm only a DM, I can't even
push an upload. But if I should test something, please let me know.
Unfortunately, since yesterday mediathekview does not start anymore
(i.e. hangs during startup). I might try to debug it a little, but
probably will have to use the version provided by upstream; hopefully
the new Debian version can be provided soon. I really use it a lot.
Thanks for maintaining and working on the new version.
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found
Hello Markus,
On Tue, May 17, 2022 at 10:09:08PM +0200, Markus Koschany wrote:
> Control: severity -1 serious
>
> Am Dienstag, dem 17.05.2022 um 21:59 +0200 schrieb mt...@nurfuerspam.de:
> > Package: mediathekview
> > Version: 13.2.1-4
> > Severity: important
> >
> > Dear Maintainer,
> >
> > after libh2-java was updated from version 2.1.210+really1.4.197-1 to
> > 2.1.212-
> > 1
> > there is an enormous occurrence of the following error exceptions when
> > starting mediathekview:
>
> Hello and thanks for the report. Currently this cannot be avoided because we
> had to move forward with the h2 database in Debian. The latest version of
> mediathekview should not require h2 anymore. I don't have the time to package
> a
> new upstream release right now but if someone wants to beat me to it, please
> go
> ahead and mark yourself as the owner of this bug report.
I hope that you'll have some time so that mediathekview is shipped in
Testing/Futures stables again.
I tried to have a look at it (though I've really no clue about java
and building java progs) and unfortunately the situation is worse than
I thought.
To save others time, that's what I tried:
1) Using the existing debian directory with or without applying
patches no longer works (this is what I expected).
2) A direct ("upstream") build also fails (and the documentation on
building is very terse) and on a quick search I could not find a
workaround.
Direct build:
./mvnw compile
…
Downloaded from central:
https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/19-ea+7/javafx-graphics-19-ea+7-linux.jar
(4.8 MB at 1.3 MB/s)
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 10.034 s
[INFO] Finished at: 2022-07-20T14:49:04+02:00
[INFO]
[ERROR] Failed to execute goal on project MediathekView: Could not resolve
dependencies for project de.mediathekview:MediathekView:jar:13.9.1: Could not
find artifact airsquared:JMacNotification:jar:1.1 in local-maven-repository
(file:tmp/mtvb2/MediathekView-13.9.1/maven-repository) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
and indeed,
/tmp/mtvb2/MediathekView-13.9.1/maven-repository/airsquared/JMacNotification/1.1/JMacNotification-1.1.jar
does not exists, and even worse (explaining the failure):
https://repo.maven.apache.org/maven2/airsquared/JMacNotification/1.1/JMacNotification-1.1.jar
is 404 (does not exist)
I could find maybe a read only copy here:
https://github.com/mediathekview/MediathekViewArchiv/blob/master/maven-repository/airsquared/JMacNotification/1.1/JMacNotification-1.1.jar
So this would require verification and then somehow to be included
into the build.
Maybe this helps getting the ball rolling …
Greetings
Helge
P.S. Besides the errors the current version still seems to work
--
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/
signature.asc
Description: PGP signature
Bug#1012077: linuxinfo FTBFS on riscv64
Hello Alan, On Sat, Jun 04, 2022 at 08:52:40AM -0400, Alan Beadle wrote: > It looks like this will always be a complex issue on RISC-V since > there is such a variety of manufacturers. However I think the > following would be the best approach. > > First, if there is a uarch field, use that since it will describe the > design of the cores present, such as Sifive's U74-MC which can be > licensed to other manufacturers, in a similar way to ARM core IP. > > If there isn't a uarch field, try to use the "model name" field if it > is present, since on the C910 this seems to replace the uarch field > (C910 is a core). > > Finally, if neither of those fields exist, the isa field might be ok > but I would add "unknown core" to the output. The letters at the end > of the isa field indicate which instruction set extensions are > present. (i for basic integer support, a for atomics, v for vector, > etc) So it is useful info, but it is vendor-generic for the most part. Ok, implented this. Thanks! I'll release the new version in the next days and then feedback is highly welcome (as I cannot try it out myself). Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1012077: linuxinfo FTBFS on riscv64
Hello Alan,
hello Bo,
hello Xiao,
hello Tienhock,
I have preliminary support for riscv now locally. However, there is a
design question:
How would you put riscv processors into families? On x86, thats done
be vendor and some marketing label ("AMD" and "Ryzen"). On Alpha,
that's the model (i.e. generation).
Looking at the cpuinfos you send me, I think the field "isa" is the
suitable one. Is this correct?
If so, what should linuxinfo write:
rv64imafdc → ???
rv64imafdcsu → ???
any other?
Some (but not all) cpuinfo also carry the field uarch. But since this
is not always present, it doesn't look like a good candidate.
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#1012077: add one riscv CPU info for linuxinfo package, T-HEAD XuanTie C910
Hello all, I'll work on this at the weekend, thanks for providing the information, it is highly helpful! Best greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#1012077: linuxinfo FTBFS on riscv64
Hello Alan, On Sun, May 29, 2022 at 02:45:29PM -0400, Alan Beadle wrote: > Package: linuxinfo > Version: 3.3.3-1 > Severity: serious > Tags: ftbfs patch upstream > Justification: fails to build from source > X-Debbugs-Cc: ab.bea...@gmail.com > > Dear Maintainer, > > linuxinfo currently fails to build on riscv64 due to this architecture not > being > supported by upstream. I am attaching a patch which adds placeholder support > for > this architecture and allows building the riscv64 debian package from source. > > Please consider applying this patch (or similar) for the next upload. > In addition, the /proc information below is for a riscv64 VisionFive V1 SBC. Thanks a lot! This was on my wishlist already. I'll review and possibly ammend your patch next weekend and then will proceed with an upload. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#816393: Works now?
Hello, for what is worth: helge@samd:/tmp$ debget nghttp2 Get:1 http://172.16.18.51:/ftp.de.debian.org/debian bullseye/main amd64 nghttp2 all 1.43.0-1 [14.4 kB] Fetched 14.4 kB in 0s (117 kB/s) Best greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de
Hello Hideki,
On Fri, Jul 02, 2021 at 10:29:53AM +0900, Hideki Yamane wrote:
> On Thu, 1 Jul 2021 21:07:03 +0200
> Helge Kreutzmann wrote:
> > It now has. So this bug is closed, if users upgrade to the latestes
> > backport version.
>
> Hmm, however, this bug is not closed automatically. Weird.
>
> https://tracker.debian.org/news/1243791/accepted-manpages-l10n-4100-1bpo101-source-into-buster-backports-backports-policy-buster-backports/
This is normal, somehow Closes in backported packages don't work. I
asked this earlier and was told otherwiese, but it still applies.
> We can close it via mail, but should investigate its reason, IMO.
I already did that, however, I can do it again, if necessary.
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de
Hello Hideki, On Wed, Jun 30, 2021 at 01:46:37PM +0900, Hideki Yamane wrote: > Have it reached to buster-backports repo? It now has. So this bug is closed, if users upgrade to the latestes backport version. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de
Hello Hideki, On Wed, Jun 30, 2021 at 01:46:37PM +0900, Hideki Yamane wrote: > from buster-backports > Message-Id: <20210630134637.d8e6f92027ef11aeb9a09...@iijmio-mail.jp> > In-Reply-To: <20210627060424.GA7522@Debian-50-lenny-64-minimal> > X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > > On Sun, 27 Jun 2021 08:04:24 +0200 Helge Kreutzmann > wrote: > > manpages-l10n (4.10.0-1~bpo10+1) buster-backports; urgency=medium > > > > * Rebuild for buster-backports. > > * Properly conflict with future versions of psmisc and procps so that > > upgrades to bullseye will work without file conflicts. Closes: #989799 > > > > -- Helge Kreutzmann Sun, 20 Jun 2021 10:27:10 +0200 > > > > Also tracker.debian.org does not show (yet), that it has been accepted. > > Have it reached to buster-backports repo? As far as I can see, no. I'll check in depth later. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
Hello Paul, On Sat, Jun 26, 2021 at 07:10:47PM +0200, Paul Gevers wrote: > On 26-06-2021 18:03, Helge Kreutzmann wrote: > > I fixed it in 4.9.3-4~bpo10. > > > > However, I think the BTS does not pick up Closes lines from backports? > > I think it does, but the changelog doesn't have an appropriate "Closes" > stanza, so the BTS has no way to know: > https://tracker.debian.org/news/1237690/accepted-manpages-l10n-493-4bpo101-source-into-buster-backports-backports-policy-buster-backports/ Ok, now I'm more awake. First, my package as uploaded has a different stanza: manpages-l10n (4.10.0-1~bpo10+1) buster-backports; urgency=medium * Rebuild for buster-backports. * Properly conflict with future versions of psmisc and procps so that upgrades to bullseye will work without file conflicts. Closes: #989799 -- Helge Kreutzmann Sun, 20 Jun 2021 10:27:10 +0200 Also tracker.debian.org does not show (yet), that it has been accepted. I will close it with a mail to cont...@bugs.debian.org in a moment, so that the BTS is fully aware of the situation. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: Closing the file conflict appropriately
reassign 989799 manpages-l10n 4.9.3-4~bpo10+1 # This is not yet formally accepted, inform the BTS anyway fixed 989799 4.10.0-1~bpo10+1 # affects psmisc procps thanks This is to ensure this bug is appropriately closed. The changelog actually should have done it already: * Rebuild for buster-backports. * Properly conflict with future versions of psmisc and procps so that upgrades to bullseye will work without file conflicts. Closes: #989799 -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
Hello Craig,
On Sun, Jun 27, 2021 at 10:42:53AM +1000, Craig Small wrote:
> I'm still not sure if procps and psmisc need to be updated to cater for the
> later version of manpages-de.
I don't belive so.
> I think the issue is that some of the conflicting manpages made it back
> into that package, so I need to update psmisc/procps?
Yes, and I included a forward fix.
I tested this, i.e. created a buster chroot with manpages-de, psmisc,
procps. Enabled backports for manpages-de and dist-upgraded all
packages. Installed the backport for 4.10.0.1. Then switched sources
to testing and did another dist-ugprade.
Everything worked. No conflicts, all packages at the expected version.
Greetings
Helge
--
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/
signature.asc
Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
Hello Paul, On Sat, Jun 26, 2021 at 07:10:47PM +0200, Paul Gevers wrote: > On 26-06-2021 18:03, Helge Kreutzmann wrote: > > I fixed it in 4.9.3-4~bpo10. > > > > However, I think the BTS does not pick up Closes lines from backports? > > I think it does, but the changelog doesn't have an appropriate "Closes" > stanza, so the BTS has no way to know: > https://tracker.debian.org/news/1237690/accepted-manpages-l10n-493-4bpo101-source-into-buster-backports-backports-policy-buster-backports/ Yes, sorry. I missed this one after running my tests. I'll do so manually. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
Hello Paul, On Sat, Jun 26, 2021 at 03:08:34PM +0200, Paul Gevers wrote: > On Mon, 14 Jun 2021 12:19:17 +0200 Axel Beckert wrote: > > Hi Craig and Helge, > > > > Craig Small wrote: > > > reassign -1 manpages-de > > > > Might be the right place indeed, but maybe not in the way you'd > > expect. See below. > > Reading this bug report, it seems that the consensus was that > manpages-de should have the bug. However, that never happened. Is this > bug now fixed in manpages-de (and can thus be closed)? I fixed it in 4.9.3-4~bpo10. However, I think the BTS does not pick up Closes lines from backports? Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
Hello all, I locally build the backport for 4.10.0. I created a buster chroot, installed manpages-de, manpages-fr and manpages-pl from backports and did a dist-ugprade to current testing. If I do this without the fix, the upgrade fails (as now expected), however, a "apt-get -f install" seems to fix it. On Mon, Jun 14, 2021 at 12:19:17PM +0200, Axel Beckert wrote: > Craig Small wrote: > > reassign -1 manpages-de > > Might be the right place indeed, but maybe not in the way you'd > expect. See below. > 2) So I wonder if the buster-backports package of manpages-de could >conflict with the psmisc and procps package in bullseye(*)? This >should probably take care that it is upgraded before procps and >psmisc are upgraded and hopefully solves the issue without too many >side-effects. > >(I'm not sure if Breaks/Replaces with ">>" or ">=" really work as >expected. I've never seen that in use anywhere before. Taking >Guillem into Cc so maybe he can tell something about if Conflicts >or Breaks/Replaces are the better choice here.) > >I only see these hopefully only minor disadvantages of that latter >solution: > >* Users need to have uptodate buster-backports package, i.e. > 4.9.3-4~bpo10+2. If they don't upgrade to 4.9.3-4~bpo10+2 before > dist-upgrading and then upgrade with 4.9.3-4~bpo10+1 still being > installed, they will run into this issue again. Might be > something for the Release Notes. > >* I'm not sure if apt gets confused while trying to find a good > order for dist-upgrading if the Conflicts/Breaks/Replaces is in > the old package and not the to-be-upgraded-to one. I hopefully > think that this is no issue, but I'm Cc'ing the APT team for > input on that to be on the safe side. If I add the Conflicts as suggested and necessary, the same procedure suceeds, i.e. the update happens as expected and all intended packages (procps, psmics and the manpages-de, manpages-fr and manpages-pl) are present in their version as of testing. I'm now preparing the official upload to backports. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
ion, Craig had in mind when reassigning the bug report. > >IMHO this is also a viable solution if variant 2) has too many side >effects as it IMHO only has a minor impact on the usability of the >manpages-de package in buster-backports. But this would partially defeat the purpose of the backport, to provide localized man pages where upstream did not. So from a maintainer POV I would prefer either solution 1) or 2). And as this situation will come up again and again in the future (with other packages of course, manplages-l10n has > 100 upstreams) I think it is worth investigation into a proper solution. So, in conclusion, I'd prefer 2) for the long run (if possible), 1) for now (with agreed upon versions) and 3) only as emergency fall back if 2) or 1) really do not work at all. I currently imported the latest version of manpages-l10n in sid, namely 4.10. I intend to ask the RMs to accept this in testing and then provide a backport again. This one could contain the "right" solution we decide upon. > Footnotes: > > (*) buster-backports neither seems to have psmisc nor procps which > surely makes this issue less complicated than it could be. :-) I wonder if and who manages file conflicts amongst backported packages? Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
Hello Craig, On Mon, Jun 14, 2021 at 06:35:19PM +1000, Craig Small wrote: > On Mon, 14 Jun 2021 at 18:04, Axel Beckert wrote: > > > JFTR: What came to me after sending that mail and what I didn't check > > so far, is if 4.9.3-4 is fine, but 4.9.3-4~bpo10+1 has those files. > > > > Actually in that case, I have no idea how the Breaks/Replaces headers > > and the maintainer scripts need to look like. > > > > $ debdiff manpages-de_4.9.3-4_all.deb manpages-de_4.9.3-4_bpo10+1_all.deb | > head > [The following lists of changes regard files as different if they have > different names, permissions or owners.] > > Files in second .deb but not in first > - > -rw-r--r-- root/root /usr/share/man/de/man1/fuser.1.gz > -rw-r--r-- root/root /usr/share/man/de/man1/killall.1.gz > -rw-r--r-- root/root /usr/share/man/de/man1/lzmainfo.1.gz > -rw-r--r-- root/root /usr/share/man/de/man1/peekfd.1.gz > -rw-r--r-- root/root /usr/share/man/de/man1/prtstat.1.gz > > There's about 20 "new" files and 20 removed files. > > For some reason, the backport version included files that clash with the > procps and psmisc packages. The sid version on 4.9.3-4 doesn't have those > conflicting files. That is on purpose. manpages-l10n has various flavours, one is tracking unstable, another one is tracking Buster (currently). Additionally, when translations are moving upstream, they get (manually, if needed be) removed from the version for unstable. So two cases may occur: 1. The translation status is different for unstable and buster. Then the localized man page may appear only in either unstable or buster. 2. Due to the moving of translations to upstream package, the translation may be contained in buster (where upstream did not contain the translation) and not in unstable (where upstream contains the translation and so its no longer present in manpages-l10n). Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports
Hello Craig, On Mon, Jun 14, 2021 at 11:41:56AM +1000, Craig Small wrote: > On Mon, 14 Jun 2021 at 00:03, Axel Beckert wrote: > > > So the Breaks and Replaces headers (c.f. #982059) should likely be > > against "<< 4.9.3-4", not just against "<< 4.9.1-1". > > > > It looks like both the psmisc and procps manpages came back from the dead. > They were removed in manpages-de 4.9.1-1 and all was good but then they > came back in 4.9.3 > Helge, the package maintainer for manpages-l10n, then removed them at > 4.9.3-4. Yes, I did a packaging error back then, which was fixed in -4. > > Is that how you see it Helge? I can re-release procps and psmisc with the > updated breaks/replaces but just making sure I hit the right version. > I agree with Axel, it looks like 4.9.3-4 is the right one to aim for now. > I assume that the just imported 4.10.0 won't have these files (again). Correct. The only change is the updated set of translations (at least in de). The "removal" is unchanged. Best greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#988584: manpages-hu: Contains undistributable content - All rights reserved
Package: manpages-hu Version: 20010119-7 Severity: serious Justification: Policy 2.3 X-Debbugs-Cc: Mario Blättermann Short: man8/ssh.8 states: .\" Copyright (c) 1995 Tatu Ylonen , Espoo, Finland .\"All rights reserved Long: The copyright situation is very unclear. I reviewed some files and besides the above one some are "GNU licensed" (without version), some require redistribution of copyright information in binary versions (I'm not sure if 2.3 Nr.3 remedies this), while others don't come with any statement at all. And debian/copyright places the burden of proof on the users in case comercial distribution is intended (e.g. Debian downstreams like Ubuntu). I wonder how this passed debian-legal? (This is just a selection, e.g. man.7,tsort.1,as.1 are interesting as well…) I tried looking at the mentioned upstream homepage, i.e. http://lme.linux.hu/forditas/index.html but this page is down atm. To resolve this bug, I suggest the following: 1. Remove all pages like ssh.8 which are clearly not distributable (After contacting with upstream or the respective authors they might be included in later versions again, if the license is updated) 2. Create a machine readable copyright including all authors (both of the english version and the respective translators) and the respective licenses. 3. Get the copyrights reviewed, e.g. on debian-legal, possibly catching more pages which cannot be distributed. 4. Check with upstream about a newer version. The pages are *old*. Is this really a service to your users? 5. Talk to manpages-l10n for integration of those pages, where copyright allows so. This way the maintance both for legal reasons and for updating (we use po4a) is vastly improved. Bonus if some translators are available, who could update the pages (its much easier with po4a). -- System Information: Debian Release: 11.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) manpages-hu depends on no packages. manpages-hu recommends no packages. Versions of packages manpages-hu suggests: ii man-db [man] 2.9.4-2 -- 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/ signature.asc Description: PGP signature
Bug#982035: Please consider reverting (i.e. re-adding dependency)
Hello Holger, On Thu, Mar 04, 2021 at 11:59:43PM +0100, Holger Wansing wrote: > Helge Kreutzmann wrote (Thu, 25 Feb 2021 18:35:47 > +0100): > > Hello Paul, > > hello Holger, > > manpages-it comes back, just from a new source package > > (manpages-l10n). The reason this was delayed is that I cannot get this > > through NEW myself, as I'm only a Debian Maintainer, so I needed a > > sponsor (Toddy is currently unavailable). This has been resolved, so > > now manpages-it is on it's way through Testing. I received positive > > signals from the release team that it will be accepted. > > > > Currently manpages-l10n (and with it manpages-it) still hast to wait 5 > > more days, before it can enter testing. (So it is already in unstable) > > manpages-it is in testing now. > I have re-added manpages-it to task-italian in tasksel (in git). > Tagging #982043 as pending. > This also draws a final line at #982035 now. Thanks. > > Please note, that manpages-l10n ships the following languages > > currently, so you might check tasksel if it follows suit: > > manpages-de > > manpages-es > > manpages-fr > > manpages-it > > manpages-mk > > manpages-nl > > manpages-pl > > manpages-bt-BR > > manpages-ro > > Missing in tasksel are currently: > manpages-es > manpages-mk > manpages-nl > manpages-bt-BR > manpages-ro > > Are these in a good condition for stable? Yes. Both upstream and myself only ship (enable) languages we have some confidence in. > Should they be added to the respective language tasks? This would be a very good idea. Thanks for taking care Helge -- 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/ signature.asc Description: PGP signature
Bug#982035: Please consider reverting (i.e. re-adding dependency)
Hello Paul, hello Holger, manpages-it comes back, just from a new source package (manpages-l10n). The reason this was delayed is that I cannot get this through NEW myself, as I'm only a Debian Maintainer, so I needed a sponsor (Toddy is currently unavailable). This has been resolved, so now manpages-it is on it's way through Testing. I received positive signals from the release team that it will be accepted. Currently manpages-l10n (and with it manpages-it) still hast to wait 5 more days, before it can enter testing. (So it is already in unstable) Please note, that manpages-l10n ships the following languages currently, so you might check tasksel if it follows suit: manpages-de manpages-es manpages-fr manpages-it manpages-mk manpages-nl manpages-pl manpages-bt-BR manpages-ro If you have any questions regaring the manpage translations, do not hesitate to ask (there are more langauges in the pipeline, but not for Bullseye) Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: Bug#982372: Bug#982059: manpages-de: procps: File sconflict between procps and manpages-de
Hello Craig, On Sun, Feb 14, 2021 at 09:29:12PM +1100, Craig Small wrote: > OK, found a minor problem. The procps version needs an epoch to correctly > match. Not 3.3.17-1 but 2:3.3.17-1 First things first: manpages-l10n passed NEW! To minimize the impact, I suggest that I prepare and upload 4.9.1-3, with just the corrected epoch for procps. If you have any (further) comments on this, then please let me know asap, otherwise I perform the upload latest tomorrow evening. I'll update the unblock request accordingly. I suggest that manpages-l10n 4.9.2 is not shipped, I also did not have the time to investigate the build failure. Thanks for spotting and feedback. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello Craig, I updated the package to package in the debian repository to 4.9.2-1 and it is now building (gdb buildpackage). As soon as this is completed, I put it up on my webspace so you can obtain it either from the salsa repository or from my webspace. If you feel that we should rather use 4.9.1 (where your patch removes the conflicting files by hand) than 4.9.2. (where they are no longer shipped, but instead the file conflict with manpages-es-extra needs to be resolved), than I trust your judgment and please do not upload 4.9.2 in this case. Please note my responds might come late tonight (I'm offline for some time tonight). Thanks again for your support. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello Mario,
On Wed, Feb 10, 2021 at 02:53:14PM +0100, Mario Blättermann wrote:
> to mention that Craig just released procps-ng-3.3.17 which also ships
> translated man pages. To avoid file conflicts, I've fixed the procps
> .po files in manpages-l10n in a way that the man pages don't get built
> anymore, except for Buster (for possible backports). Then I've
> released v4.9.2 which now needs to be packaged to fix the file
> conflicts.
I saw your update and release. Does this version already have a file
conflict with manpages-es-extra? I think the initial plan was to
include them in march, correct?
I contacted the maintainer (cf. #980885, which you also contributed
to), but he did not respond yet, unfortunately.
Thanks
Greetigs
Helge
--
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/
signature.asc
Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello Craig, thank you very much for your support. I was tired and frustrated yesterday. On Mon, Feb 08, 2021 at 04:34:19PM -0500, Craig Small wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > The first problem I can see is you haven't pushed the git tags. Salsa > doesn't know about the 4.9.1 update[1] > git push --tags should do it This says "Everything up-to-date" > So it fails to build for me here > $ gbp buildpackage --git-pbuilder > gbp:info: Building with (cowbuilder) for sid > gbp:error: upstream/4.9.1 is not a valid treeish > > "not valid teeish" = cant find the tag. I resolved this one by (manually) copying the build tree in place. But this build system is very opaque to me. > For your problem, I think you've not included some file, but can't see the > problem myself as I need the tag. > > Don't give up, it does look all bewildering but you'll get there in the > end. Based on the (never uploaded 4.9.1-1 version) I build version 4.91-2 "the good old way", i.e. without using git, gbp and similar. This worked just fine. You can pick it up from: https://www.helgefjell.de/data/manpages-l10n_4.9.1-2_set.tar.xz https://www.helgefjell.de/data/manpages-l10n_4.9.1-2_set.tar.xz.sig Again, this contains all files for and from the build. When Tobias has more time again, we might need to repair the git repository (I'm confident Tobias is able to fix everything), but right now I'm more interested in working packages for users. As reported by Sedat in 982372 the version I prepared now worked for him, so could you upload this version? Thanks again for your support. Greetings helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello Craig, I updated the packge but now this gdb-thingy (sorry) is on strike and I have now idea why: helge@samd:/tmp/debian-manpages-l10n$ LC=ALL=C gbp buildpackage gbp:info: Performing the build dpkg-buildpackage -us -uc -ui -i -I dpkg-buildpackage: Information: Quellpaket manpages-l10n … debian-manpages-l10n/po/ro/Makefile.in dpkg-source: Fehler: Abbruch aufgrund unerwarteter Änderungen in den Originalquellen, siehe /tmp/manpages-l10n_4.9.1-2.diff.n75akF dpkg-source: Information: Sie können die lokalen Änderungen mit dpkg-source --commit integrieren dpkg-buildpackage: Fehler: Unterprozess dpkg-source -i -I -b . lieferte Exitstatus 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui -i -I failed gbp:error: 'debuild -i -I' failed: it exited with 29 Probably with some git magic I could repair this, but even helge@samd:/tmp/debian-manpages-l10n$ gbp import-orig --uscan gbp:info: Launching uscan... gbp:info: package is up to date, nothing to do. … Looks like no more localized manpages in Debian. I simply fail to understand this complicated toolchain, sorry. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello Craig, On Tue, Feb 09, 2021 at 06:54:54AM +1100, Craig Small wrote: > On Tue, 9 Feb 2021 at 05:16, Helge Kreutzmann wrote: > > On Sun, Feb 07, 2021 at 04:51:14PM -0500, Craig Small wrote: > > > I think you have the control lines wrong. You have both the lines from > > > psmisc and manpages-de there. > > > > > > Breaks: manpages-de (<= 2.16-1), psmisc (<< 23.4-2) > > > Replaces: manpages-de (<= 2.16-1) > > > > This is correct, it also breaks (and replaces) older manpages-de from > > stable. > > > As the standard part of dpkg installing a newer version of package, it > uninstalls all previous versions on the same package. Correct. > > This is not related to this bug but stems from the fact that the > > source package manpages-de was replaced manpages-l10n which in turn > > now builds manpages-de amongst others. > > > They are source packages, the binary package is still manpages-de. Think > about it, have you ever been able to have two versions of the same package > installed no matter what the source package name was? > > For #982059 yes, but if you perform an update from stable (without > > psmic involved) then the other breaks is needed as well, see #959846. > > > Let's have a look at #959846... > > manpages-de: missing Breaks+Replaces: manpages-de-dev (<< 4) > > manpages-de-***dev*** is the conflicting package name. So yes, you should > have something about manpages-de-dev otherwise you get: > > dpkg: error processing archive > /var/cache/apt/archives/manpages-de_4.0.0-3_all.deb (--unpack): >trying to overwrite '/usr/share/man/de/man4/console_ioctl.4.gz', > which is also in package manpages-de-dev 2.12-1 > > And probably other problems too. > > If you can find a reference somewhere where changing the source package > means you need something for the corresponding binary package of the same > name, I'm happy to see it but I've never seen that before. I'm not a specialist in this kind of relationsships. I'll update the package accordingly, thanks for the explanation. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello Craig, On Sun, Feb 07, 2021 at 04:51:14PM -0500, Craig Small wrote: > I think you have the control lines wrong. You have both the lines from > psmisc and manpages-de there. > > Breaks: manpages-de (<= 2.16-1), psmisc (<< 23.4-2) > Replaces: manpages-de (<= 2.16-1) This is correct, it also breaks (and replaces) older manpages-de from stable. This is not related to this bug but stems from the fact that the source package manpages-de was replaced manpages-l10n which in turn now builds manpages-de amongst others. Sorry if this is confusing. > Think of Breaks as "someone won't have the manpage or there will be two of > them if this happens" > Replaces is "we took the file from that package", its replacing files not > packages. > > So, manpage-de should have "Breaks: psmisc ( << 23.4-2)" This I got, so for #982059 the package should be ready to go. > This means: > * If you install this new manpage-de and have psmisc below 23.4-2 you > won't have the German psmisc manpages. > > The next psmisc release will have "Breaks: manpage-de (<< 4.9.1-1), > Replaces: manpages-de ( << 4.9.1-1)" > This means: > * If you install a new psmisc and old manpage-de then there are TWO > manpages, so don't do that. > * The new psmisc replaces files in the old manpage-de > > manpages-de *only* needs the Breaks psmisc bit. For #982059 yes, but if you perform an update from stable (without psmic involved) then the other breaks is needed as well, see #959846. Hope this clarifies. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
tags 982059 + pending thanks Hello Craig, the manpage-l10n package is ready to go. You can either pick it up from git https://salsa.debian.org/debian/manpages-l10n.git and perfom "gbp buildpackage" or you can download the packages "ready to sign and upload" from my site: https://www.helgefjell.de/data/manpages-l10n_4.9.1-1.tar.xz https://www.helgefjell.de/data/manpages-l10n_4.9.1-1.tar.xz.sig Since the Freeze is rapidly approaching an upload at your earliest possiblity would be highly appreciated. In case of problems I'll respond within 24 hours. Thanks for your support. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello Craig, On Sun, Feb 07, 2021 at 09:06:26PM +1100, Craig Small wrote: > It's not the entire package, just the specific man pages that are carried > by the program package. So the de fuser.1 will still exist, just in psmisc > not manpages-de. The benefit is that the psmisc po4a will update the man > page every time the main man page is updated so they stay in sync. I know, but thanks for the explanation. > So the control file for the new 4.9.1-1 manpages-de package will have: > Breaks: psmisc (<< 23.4-2) Are you should the relationship is correct? The conflict *starts* in 23.4-2 if I got that right, so it should psmisc (>> 23.4-1). Earlier versions are co-installable. > 23.4-2, which I will have to update with these control lines, will have: > Breaks: manpages-de (<< 4.9.1-1) > Replaces: manpages-de (<< 4.9.1-1) > Does that seem to make sense to everyone? Although it appears a little counter-intuitive, according to https://www.debian.org/doc/debian-policy/ch-relationships.html This appears to be correct. > As Mario said, we are going to go through this again with procps, so > hopefully, it will go smoother. If we nut this out properly it will go > better. Yes. > On Sun, 7 Feb 2021 at 20:42, Helge Kreutzmann wrote: > > > However, as Tobias is busy with real life and manpages-l10n needs to > > go through new (as new langauges are contained) I cannot proceed any > > further, as a DM I'm not allowed to upload to NEW. > > > > Any help from a DD appreciated on this. > > > I can help here, I'm a DD. That would be very much appreciated. Once we resolved the correct relationships, I can push the commits and then please tell me what exactly you would like to get for the upload into NEW. (Again, once NEW is no longer an issue, I'm able and allowed to perform the uploads myself, of course). Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello all, On Sun, Feb 07, 2021 at 09:40:46AM +0100, Mario Blättermann wrote: > Of course, I knew about the raised file conflicts. Yesterday we have > released manpages-l10n v4.9.1 [1], without the psmisc translations. This version is ready to go, I only need to run git commit. However, as Tobias is busy with real life and manpages-l10n needs to go through new (as new langauges are contained) I cannot proceed any further, as a DM I'm not allowed to upload to NEW. Any help from a DD appreciated on this. If the solution would be to remove manpages-de than this would be great disservice to both the user base (manpages ships e.g. systemd translations any many more) as well as an dishounur of the translators. Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#979027: manpages-it: Package severely outdated, should not be shipped (as is) with Bullseye, successor to be released soon
Package: manpages-it Version: 3.73-2.1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: "Dr. Tobias Quathamer" , Francesco Paolo Lovergine The last real upload happend in 2014, more than 6 years ago. The upstream man pages are now at version 5.10-1, even o-o-stable (which will become o-o-o-stable once bullseye is released) has a newer version of the man pages. There has been extensive work on the upstream man pages as well (inclunding, but not limited to, new major version of the tools described). Therefore these very outdated man pages are strongly misleading to Italian speaking users and should not be shipped. Additionally, upstream has moved its translation to manpages-l10n where current translations (as far as possible) are maintained. The upstream maintainer Mario Blättermann has just announced that Italian will be distributed (first time) in the next major version, slated for release on or around February 6th. It is the intention of the Debian manpage-l10n maintainers to also enable Italian in that manpage-l10n version. Therefor Itialian users will enjoy current localized man pages (just shipped by a different source package). Francesco, if you want to help us in the transition (I'm currently helping Tobias in maintaining manpages-l10n, but more help would be appreciated) please contact us. Release team: Even if for some highly unlikely reason manpages-l10n would not ship manpages-it, Bullseye should not mislead Itialian users for thinking to read current (localized) translation when in fact it is more than 6 years old. -- System Information: manpages-it depends on no packages. manpages-it recommends no packages. Versions of packages manpages-it suggests: ii konqueror [man-browser] 4:20.08.3-1 ii man-db [man-browser] 2.9.3-2 -- 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/ signature.asc Description: PGP signature
Bug#922396: Updated package / patch and status information
tags 922396 + patch
thanks
Hello,
this is a central package, so I had a look at it. Unfortunately,
README.source is outdated, the following recipe works:
* apt-get source
* cd mozilla-noscript-10.1.9.6
* uscan
* create appropriate directory, cd into it and tar xJvf
../mozilla-noscript_….orig.tar.xz
* copy over debian directory from 10.1.9.6
* export QUILT_PATCHES=debian/patches
* quilt new 0002b-remove-websites-from-default-white-list.patch
* quilt edit common/Policy.js
* quilt refresh
* comment out 0002 (original) patch in debian/patches/series
* dch -i und Changelog-Eintrag vorgenommen (Note: version number)
* debuild
for version 11.0.34 the (new/updated) patch is as follows:
Author: Ximin Luo , Helge Kreutzmann
Description: remove websites from default white list
Original patch by
From: arno
Date: Tue, 25 Aug 2009 23:32:30 +0200
Subject: remove websites from default white list
Index: mozilla-noscript-11.0.34/common/Policy.js
===
--- mozilla-noscript-11.0.34.orig/common/Policy.js
+++ mozilla-noscript-11.0.34/common/Policy.js
@@ -294,21 +294,7 @@ var {Permissions, Policy, Sites} = (() =
function defaultOptions() {
return {
sites:{
-trusted: `addons.mozilla.org
- afx.ms ajax.aspnetcdn.com
- ajax.googleapis.com bootstrapcdn.com
- code.jquery.com firstdata.com firstdata.lv gfx.ms
- google.com googlevideo.com gstatic.com
- hotmail.com live.com live.net
- maps.googleapis.com mozilla.net
- netflix.com nflxext.com nflximg.com nflxvideo.net
- noscript.net
- outlook.com passport.com passport.net passportimages.com
- paypal.com paypalobjects.com
- securecode.com securesuite.net sfx.ms tinymce.cachefly.net
- wlxrs.com
- yahoo.com yahooapis.com
- yimg.com youtube.com
ytimg.com`.split(/\s+/).map(Sites.secureDomainKey),
+trusted: ``.split(/\s+/).map(Sites.secureDomainKey),
untrusted: [],
custom: {},
},
Now I have to check if this updated version works …
Btw., version 10.1.9.6. still seems to work in firefox 68.10.0esr-1.
Greetings
Helge
P.S. If someone takes over mozilla-noscript, README.source should be
updated as well
--
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/
signature.asc
Description: PGP signature
Bug#934458: linkchecker-gui: Fails to start at all
Hello Paolo, I just saw your message. Please, next time send your reply also to 934458-submit...@bugs.debian.org, because the answer to the bugs are not forwarded to the submitter, unfortunately. I have python-xdg installed, but this does not change anything: ii python-xdg 0.25-5 all Python 2 library to access freedesktop.org standards Anything else I can try? (Unfortunately I don't speak python). I see that in the PTS linkchecker(-gui) does not look very well. I put the current Maintainer, Antoine, in CC, maybe he (she?) can shed some light on the current support status of linkchecker? (Or should I look for another tool?) Greetings Helge -- 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/ signature.asc Description: PGP signature
Bug#934458: linkchecker-gui: Fails to start at all
Package: linkchecker-gui Version: 9.3-4 Severity: grave Justification: renders package unusable Trying to start linkchecker-gui fails: helge@samd:~$ linkchecker-gui Traceback (most recent call last): File "/usr/bin/linkchecker-gui", line 78, in main() File "/usr/bin/linkchecker-gui", line 68, in main window = LinkCheckerMain(**mainkwargs) File "/usr/lib/python2.7/dist-packages/linkcheck/gui/__init__.py", line 121, in __init__ self.init_menu() File "/usr/lib/python2.7/dist-packages/linkcheck/gui/__init__.py", line 142, in init_menu self.urlinput.addMenuEntries(self.menuEdit) File "/usr/lib/python2.7/dist-packages/linkcheck/gui/lineedit.py", line 179, in addMenuEntries if find_chrome(): File "/usr/lib/python2.7/dist-packages/linkcheck/gui/lineedit.py", line 207, in find_chrome from ..bookmarks.chrome import find_bookmark_file File "/usr/lib/python2.7/dist-packages/linkcheck/bookmarks/chrome.py", line 20, in from xdg import xdg_config_home ImportError: cannot import name xdg_config_home I only use it irregularly, but some month ago it still worked. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.1.15 (SMP w/4 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linkchecker-gui depends on: ii libqt4-sql-sqlite 4:4.8.7+dfsg-18 ii linkchecker9.4.0-2 ii python 2.7.16-1 ii python-qt4 4.12.1+dfsg-2+b1 ii python-qt4-sql 4.12.1+dfsg-2+b1 Versions of packages linkchecker-gui recommends: pn python-qscintilla2 linkchecker-gui suggests no packages. -- no debconf information -- 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/ signature.asc Description: PGP signature
Bug#925411: Count me as happy user of make-kpkg
Hello, I'm quite "suprised" by todays dist-upgrade. I use make-kpkg (with some wrapper scripts) since I switched to Debian around 2000. I just build 5.0.7 last Sunday. So this is a bad suprise this late in the development cycle. I did not have a chance to read all details of all bugs/links in this bug report (I'm in a bit of rush at the moment). Hopefully the replacement works as flawlessly as make-kpkg did. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#924076: tvtime: insecure use of /tmp
Hello Jakub, On Mon, Mar 25, 2019 at 11:15:59AM +0100, Jakub Wilk wrote: > Hi Helge! > > * Helge Kreutzmann , 2019-03-23, 20:48: > >+/* Create a secure private temporary directory */ > >+fifosdir = mkdtemp(FIFODIR "tvtimeXX"); > > The mkdtemp(2) man page says: "Since it will be modified, template must not > be a string constant, but should be declared as a character array." This is > the reason it segfaults. > > Also, slash is missing between FIFODIR and "tvtime". > > You would need something like this: > > char *fifosdir; > char fifosdir_buf[] = FIFODIR "/tvtimeXX"; > fifosdir = mkdtemp(fifosdir_buf); Thanks. As said, I'm not a programmer but a user of tvtime who previously did some very simple coding. > So (with the addition of error handling) this would fix insecure use of > /tmp; but it also breaks communication between tvtime-command(1) and > tvtime(1). They need to use the same fifo to communicate, but mkdtemp() > ensures that this is never the case: > > $ tvtime-command QUIT > Reading configuration from /etc/tvtime/tvtime.xml > Reading configuration from /home/jwilk/.tvtime/tvtime.xml > tvtime-command: Cannot open /tmp/tvtimeHH48wA/.TV-jwilk/tvtimefifo-borsuk: > No such file or directory > > It would be best to avoid using /tmp for fifos. tvtime already falls back to > $HOME when /tmp couldn't be used (grep for "put the fifo in $HOME" in > src/utils.c), to this should be a matter of disabling the /tmp codepath. Great. Could you update the patch accordingly? If you need someone to upload I can most likely arrange that (but if you know someone yourself, even better, as I'm mostly offline the next ~10 days). Thanks for your kind help. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#924076: Idea how to solve this
Hello,
I'm not a C programmer but I guess solving this issue might go along
the following path:
Description: Create a secure directory for the FIFO
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
tvtime (1.0.11-4) unstable; urgency=medium
.
* QA upload.
* Add the missing build dependency on pkg-config.
Author: Helge Kreutzmann
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: other
Bug-Debian: https://bugs.debian.org/924076
Forwarded:
Reviewed-By:
Last-Update: 2019-03-23
--- tvtime-1.0.11.orig/src/utils.c
+++ tvtime-1.0.11/src/utils.c
@@ -167,14 +167,19 @@ char *get_tvtime_fifo_filename( uid_t ui
char *fifodir;
char *fifo;
+char *fifosdir;
+
+/* Create a secure private temporary directory */
+fifosdir = mkdtemp(FIFODIR "tvtimeXX");
+
/* Create string for the directory in FIFODIR */
pwuid = getpwuid( uid );
if( pwuid ) {
-if( asprintf( &fifodir, FIFODIR "/.TV-%s", pwuid->pw_name ) < 0 ) {
+if( asprintf( &fifodir, "%s/.TV-%s", fifosdir, pwuid->pw_name ) < 0 ) {
return 0;
}
} else {
-if( asprintf( &fifodir, FIFODIR "/.TV-%u", uid ) < 0 ) {
+if( asprintf( &fifodir, "%s/.TV-%u", fifosdir, uid ) < 0 ) {
return 0;
}
}
This code segfaults, does not contain error checks but hopefully
someone with real C knowledge can make it work (and prevent tvtime
from being removed).
Greetings
Helge
--
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/
signature.asc
Description: Digital signature
Bug#915345: Remove roar support for now? (Fixes FTBFS)
Hello Ryan, cmus is marked for autoremoval, the freeze is approaching (where no removed packages are allowed to reenter testing) and I see no activity from the cmus side. Also at least the mpd developers are not very confident in the code quality of libroar https://github.com/MusicPlayerDaemon/MPD/commit/06ca08ce555 I just checked, with the following patch cmus builds just fine (although of course without roaraudio), so I suggest to apply it at least until roaraudio is fixed: root@samd:/tmp# diff -u cmus-2.7.1+git20160225/debian/control cmus-2.7.1+git20160225.new/debian/control --- cmus-2.7.1+git20160225/debian/control 2018-05-17 11:10:59.0 +0200 +++ cmus-2.7.1+git20160225.new/debian/control 2019-01-09 15:21:35.615201691 +0100 @@ -25,7 +25,6 @@ libncursesw5-dev, libopusfile-dev, libpulse-dev (>= 0.9.19), - libroar-dev, libsamplerate0-dev, libvorbis-dev, libwavpack-dev, root@samd:/tmp# diff -u cmus-2.7.1+git20160225/debian/rules cmus-2.7.1+git20160225.new/debian/rules --- cmus-2.7.1+git20160225/debian/rules 2018-05-17 11:10:59.0 +0200 +++ cmus-2.7.1+git20160225.new/debian/rules 2019-01-09 15:47:02.105477216 +0100 @@ -4,7 +4,7 @@ LDFLAGS+=-Wl,--as-needed CFLAGS+=-I/usr/include/ncursesw -suggested_deps = pulse roar jack +suggested_deps = pulse jack EXTRA_CMUS_DIR_OP_PLUGINS = debian/cmus/usr/lib/cmus/op/ EXTRA_CMUS_PLUGINS := $(foreach plugin,$(suggested_deps),$(plugin).so) Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#915657: [Android-tools-devel] Bug#915657: Bug#851860: Intent to NMU google-android-installers to fix longstanding l10n bugs
Hello Kai-Chung
On Thu, Dec 06, 2018 at 10:34:37PM +0800, seam...@debian.org wrote:
> > Could you contact him or provide me his contact details so I can ask
> > him?
>
> He subscribes to the emails as well, and we can be found in #debian-mobile.
> His username is "_hc" on IRC.
Then I wait until he approaches me.
> But thank you for the fix!
Hopefully @eighthave will do it in the spirit of your team, but
otherwise I'll provide a fix.
Greetings
Helge
--
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/
signature.asc
Description: Digital signature
Bug#915657: [Android-tools-devel] Bug#915657: Bug#851860: Intent to NMU google-android-installers to fix longstanding l10n bugs
Hello Kai-Chung,
On Thu, Dec 06, 2018 at 10:20:34PM +0800, seam...@debian.org wrote:
> > Otherwiese I would work out a fix and prepare another NMU.
>
> I really can't say for much as I don't maintain those packages. Perhaps
> @eighthave knows better.
Could you contact him or provide me his contact details so I can ask
him?
Thanks!
Greetings
Helge
--
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/
signature.asc
Description: Digital signature
Bug#915657: [Android-tools-devel] Bug#851860: Intent to NMU google-android-installers to fix longstanding l10n bugs
Hello Kai, On Mon, Sep 03, 2018 at 06:44:34PM +0800, 殷啟聰 | Kai-Chung Yan wrote: > I am one of the devs at `android-tools` team although I don't > maintain the contrib installer packages like this. AFAIK Mouaad is > MIA after his work in GSoC 2016, but I can say he will be fine with > the NMU and he is not preparing for a new release yet. Please go > ahead with your other NMUs on the l10n as well. > > Thank you for the contribution! In my NMU an error popped up (sorry), cf. #915657 for details. Do you (or someone from your team) want to prepare a proper fix which would suite the (long term) maintanence of google-android-installers? Otherwiese I would work out a fix and prepare another NMU. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#913498: qpsmtpd: [FTBFS] Does not build in unstable, prerequisite Time::TAI64 0 not found
Hello Adrian, On Sun, Nov 11, 2018 at 10:09:38PM +0200, Adrian Bunk wrote: > On Sun, Nov 11, 2018 at 09:04:49PM +0100, Helge Kreutzmann wrote: > >... > > Strange. > > yes. Feel free to downgrade / close. If I can diagnose it further I probably need to open a different bug somewhere (or fix my chroot). > > The main difference appears to be here: > > > > Use of uninitialized value $thisperl in pattern match (m//) at > > > > /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1993. > > > > Use of uninitialized value $file in pattern match (m//) at > > > > /usr/lib/x86_64-linux-gnu/perl/5.28/File/Spec/Unix.pm line 131. > > > > Use of uninitialized value $_[0] in substitution (s///) at > > > > /usr/share/perl/5.28/File/Basename.pm line 180. > > > > fileparse(): need a valid pathname at > > > > /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1122. > > > > Which version of perl is installed on the system? (Sorry, if that is > > obvious, I could not find it in the logs). > > buildinfo says > perl (= 5.28.0-3), > perl-base (= 5.28.0-3), > perl-modules-5.28 (= 5.28.0-3), Same for me, so no "quick" clue atm. Thanks for the pointer. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#913498: qpsmtpd: [FTBFS] Does not build in unstable, prerequisite Time::TAI64 0 not found
Hello Adrian, On Sun, Nov 11, 2018 at 09:30:30PM +0200, Adrian Bunk wrote: > On Sun, Nov 11, 2018 at 07:13:31PM +0100, Helge Kreutzmann wrote: > > Package: qpsmtpd > > Version: 0.94-2 > > Severity: serious > > > > In testing, qpsmtpd builds fine. > > > > In current unstable, however, the build fails: > > root@samd:/tmp/orig/qpsmtpd-0.94# debuild > > dpkg-buildpackage -rfakeroot -us -uc -ui > > dpkg-buildpackage: Warnung: Verwendung eines root-werde-Befehls, obwohl > > bereits root > > dpkg-buildpackage: Information: Quellpaket qpsmtpd > > dpkg-buildpackage: Information: Quellversion 0.94-2 > > dpkg-buildpackage: Information: Quelldistribution unstable > > dpkg-buildpackage: Information: Quelle geändert durch Devin Carraway > > > > dpkg-source --before-build . > > dpkg-buildpackage: Information: Host-Architektur amd64 > > fakeroot debian/rules clean > > dh_testdir > > dh_testroot > > dh_auto_clean > > dh_clean > > dpkg-source -b . > > dpkg-source: Information: Quellformat »3.0 (quilt)« wird verwendet > > dpkg-source: Information: qpsmtpd wird unter Benutzung des existierenden > > ./qpsmtpd_0.94.orig.tar.gz gebaut > > dpkg-source: Information: Patchliste aus debian/patches/series wird > > verwendet > > dpkg-source: Information: qpsmtpd wird in qpsmtpd_0.94-2.debian.tar.xz > > gebaut > > dpkg-source: Information: qpsmtpd wird in qpsmtpd_0.94-2.dsc gebaut > > debian/rules build > > dh_testdir > > perl Makefile.PL INSTALLDIRS=vendor > > Warning: prerequisite File::Tail 0 not found. > > Warning: prerequisite Mail::DKIM 0 not found. > > Warning: prerequisite Time::TAI64 0 not found. > > Use of uninitialized value $thisperl in pattern match (m//) at > > /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1993. > > Use of uninitialized value $file in pattern match (m//) at > > /usr/lib/x86_64-linux-gnu/perl/5.28/File/Spec/Unix.pm line 131. > > Use of uninitialized value $_[0] in substitution (s///) at > > /usr/share/perl/5.28/File/Basename.pm line 180. > > fileparse(): need a valid pathname at > > /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1122. > > Checking if your kit is complete... > > Looks good > > make: *** [debian/rules:14: configure] Fehler 29 > > dpkg-buildpackage: Fehler: Unterprozess debian/rules build lieferte > > Exitstatus 2 > > debuild: fatal error at line 1182: > > dpkg-buildpackage -rfakeroot -us -uc -ui failed > > > > > > The first two warnings can be removed by adding > > libfile-tail-perl and libmail-dkim-perl to the > > build depends. I could not find, however, what is needed for > > Time::TAI64, i.e. where it is appropriately provided in Debian. > >... > > Builds for me and builds in reproducible: > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/qpsmtpd.html > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. >Pearl S. Buck - Dragon Seed Strange. The main difference appears to be here: > > Use of uninitialized value $thisperl in pattern match (m//) at > > /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1993. > > Use of uninitialized value $file in pattern match (m//) at > > /usr/lib/x86_64-linux-gnu/perl/5.28/File/Spec/Unix.pm line 131. > > Use of uninitialized value $_[0] in substitution (s///) at > > /usr/share/perl/5.28/File/Basename.pm line 180. > > fileparse(): need a valid pathname at > > /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1122. Which version of perl is installed on the system? (Sorry, if that is obvious, I could not find it in the logs). Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#913498: qpsmtpd: [FTBFS] Does not build in unstable, prerequisite Time::TAI64 0 not found
Package: qpsmtpd Version: 0.94-2 Severity: serious In testing, qpsmtpd builds fine. In current unstable, however, the build fails: root@samd:/tmp/orig/qpsmtpd-0.94# debuild dpkg-buildpackage -rfakeroot -us -uc -ui dpkg-buildpackage: Warnung: Verwendung eines root-werde-Befehls, obwohl bereits root dpkg-buildpackage: Information: Quellpaket qpsmtpd dpkg-buildpackage: Information: Quellversion 0.94-2 dpkg-buildpackage: Information: Quelldistribution unstable dpkg-buildpackage: Information: Quelle geändert durch Devin Carraway dpkg-source --before-build . dpkg-buildpackage: Information: Host-Architektur amd64 fakeroot debian/rules clean dh_testdir dh_testroot dh_auto_clean dh_clean dpkg-source -b . dpkg-source: Information: Quellformat »3.0 (quilt)« wird verwendet dpkg-source: Information: qpsmtpd wird unter Benutzung des existierenden ./qpsmtpd_0.94.orig.tar.gz gebaut dpkg-source: Information: Patchliste aus debian/patches/series wird verwendet dpkg-source: Information: qpsmtpd wird in qpsmtpd_0.94-2.debian.tar.xz gebaut dpkg-source: Information: qpsmtpd wird in qpsmtpd_0.94-2.dsc gebaut debian/rules build dh_testdir perl Makefile.PL INSTALLDIRS=vendor Warning: prerequisite File::Tail 0 not found. Warning: prerequisite Mail::DKIM 0 not found. Warning: prerequisite Time::TAI64 0 not found. Use of uninitialized value $thisperl in pattern match (m//) at /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1993. Use of uninitialized value $file in pattern match (m//) at /usr/lib/x86_64-linux-gnu/perl/5.28/File/Spec/Unix.pm line 131. Use of uninitialized value $_[0] in substitution (s///) at /usr/share/perl/5.28/File/Basename.pm line 180. fileparse(): need a valid pathname at /usr/share/perl/5.28/ExtUtils/MM_Unix.pm line 1122. Checking if your kit is complete... Looks good make: *** [debian/rules:14: configure] Fehler 29 dpkg-buildpackage: Fehler: Unterprozess debian/rules build lieferte Exitstatus 2 debuild: fatal error at line 1182: dpkg-buildpackage -rfakeroot -us -uc -ui failed The first two warnings can be removed by adding libfile-tail-perl and libmail-dkim-perl to the build depends. I could not find, however, what is needed for Time::TAI64, i.e. where it is appropriately provided in Debian. If you fix this error, please contact me, as I would like to fix several other (mainly l10n) errrors in this package so we can join forces. For my planned NMU I contacted the debian maintainer, however, he did not respond. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- 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/ signature.asc Description: Digital signature
Bug#906468: goobox: FTBFS in buster/sid (aclocal-1.15: command not found)
tag 906468 +confirmed
thanks
On Fri, Aug 17, 2018 at 07:21:08PM +, Santiago Vila wrote:
> dh_testdir
> # Building package
> /usr/bin/make
> make[1]: Entering directory '/<>'
> CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /<>/missing
> aclocal-1.15 -I m4
> /<>/missing: line 81: aclocal-1.15: command not found
> WARNING: 'aclocal-1.15' is missing on your system.
> You should only need it if you modified 'acinclude.m4' or
> 'configure.ac' or m4 files included by 'configure.ac'.
> The 'aclocal' program is part of the GNU Automake package:
> <http://www.gnu.org/software/automake>
> It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> <http://www.gnu.org/software/autoconf>
> <http://www.gnu.org/software/m4/>
> <http://www.perl.org/>
> make[1]: *** [Makefile:464: aclocal.m4] Error 127
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:60: build-stamp] Error 2
> dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit
> status 2
>
This happens in a sid changeroot as well. The fix is not hard.
> The build was made with "dpkg-buildpackage -B" in my autobuilder.
> Most probably, it also fails here in reproducible builds:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/goobox.html
Here I'm still working, getting a reproducible build.
Greetings
Helge
--
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/
signature.asc
Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Andreas Henriksson, On Sun, Aug 12, 2018 at 05:35:35PM +0200, Andreas Henriksson wrote: > Hello Helge Kreutzmann, > > Sorry if my comments sounded too negative, some more reasoning below. No problem. > On Sun, Aug 12, 2018 at 04:35:47PM +0200, Helge Kreutzmann wrote: > > Hello Andreas Henriksson, > > I'm a bit puzzled by your e-mail. Simon asked me to provide some text, > > Chris prodded me and Davide and Simon reviewed my text (which does not > > imply that it is perfect or so). > [...] > > Well, I think for _Debian_ users the change *is* suprising, but only > > because the su version (and its configuration / behaviour) has > > changed. > [...] > > If the change in behaviour isn't something we can just live with > I think solving it via pam configuration seems like the best course > of action. Please see the mail I just quickly banged together and > sent to debian-devel (with you BCCed). Yes, I read it. Thanks for letting me know. > [...] > > Which is clearly not the case here. So upstreaming is no option. > > Carrying patches downstream forever isn't something I'm very Not forever: Only until the next stable release has happend. Then drop it again. Clear timeline. > enthusiastic about as you probably understand. As you might have > also noticed I've removed myself from util-linux maintenance (lack of No, I've not researched about util-linux any further, I just stumbled over the bug and wanted to add my few cents to help resolving it. I belive writing patches is better than simply complaining, and for documentation this is within my skill set. > time). I thus don't really see it suitable for me to add patches like > this that someone else gets to maintain, but anyone with upload > privilegies can upload a NMU themselves ofcourse! (so there's no need > to wait for me to do it.) Hopfeully your successor can chime in and put his/her POV on this. > OTOH please consider I've spent years to back util-linux out of the > corner it was stuck in. Non upstreamed/upstreamable patches was part > of the problem. I would very much appreciate some sympathy on that > rather than pushing things back into the corner as soon as I turn my > back. ;P Thanks for your efforts. And I perfectly understand that you want to avoid (ongoing) distribution specific patches where possible. > [...] > > Thanks. But as stated earlier, having it in NEWS is only part of the > > solution, [...] > > I'd even call it a workaround which simply serves the purpose of me > not having to touch the pam configuration with zero peer review. > (And I also doubt more people read manpages than read NEWS. Targeting > release notes might be a much better option. Things that aren't new > but just best practises we want to spread the knowledge of might be > better suited for debian-handbook or similar) And again who reads the release notes, especially ordinary users who (like me at work) simply get a system delivered, without any further "changelog", "NEWS", "release information"? There is no perfect solution. So besides the NEWs file you mentioned, the other two options could work in parallel. [...] > Sorry for sending another sloppy mail today, but hopefully you can > make some sense of what I wrote. Really need to attend personal > things now instead Final words, don't expect me to actually maintain > util-linux anymore. Don't wait for me to upload what you think is > sensible. I wish you good success to your personal endavours and thanks for the time you invested in Debian. I'm not going to do an NMU for a documentation patch, so let's wait for your sucessor. (For me the bug is solved, this bug report is just about spreading the word appropriately). Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Andreas Henriksson, I'm a bit puzzled by your e-mail. Simon asked me to provide some text, Chris prodded me and Davide and Simon reviewed my text (which does not imply that it is perfect or so). On Sun, Aug 12, 2018 at 05:56:14AM +0200, Andreas Henriksson wrote: > Hello Helge Kreutzmann, > > I'm skeptical how relevant it is to document how X and ssh works > in the _su_ manpage, but either way since you're patching the I'm fine to skip the X and ssh part, but as stated above the reviewer liked the idea and I actually tried to keep it short and simple. And no, I don't intend to go into any more details, which would be way over top in the su manpage. > manpage this is something you want to send upstream for review if > you think it's worth persuing and my opinion doesn't count there. Well, I think for _Debian_ users the change *is* suprising, but only because the su version (and its configuration / behaviour) has changed. For upstream util-linux this is not the case, there no change has occured, only one more distribution is now using the su implementation. So I could very well understand if util-linux upstream would reject the change, as there nothing has happend (and why should users of other distributions care about a Debian specific issue?). > As always to increase chances of a favourable review getting the > administrative details right from the start is useful, so please > see Documentation/howto-contribute.txt As you can see from the bug log, there already was some review. Looking at howto-contribute.txt, it also says: * neutrality: the files in util-linux should be distribution-neutral. Which is clearly not the case here. So upstreaming is no option. > (You might also want to replace references to 'Debian 9' with > 'shadow su implementation' or similar.) I think the explicit reference to Debian serves a purpose here: The user might not know that previous versions of su came from shadow, and current ones from util-linux. They just see their workflow break. > I'll add a note to util-linux.NEWS about DISPLAY and XAUTHORITY. Thanks. But as stated earlier, having it in NEWS is only part of the solution, because in larger installations NEWS are not seen by ordinary users, e.g at work I've never seen any NEWS file, I simply was informed than an upgrade had happened, so I rely on other information sources, where man pages are my first try. (And search in the web and hopefully finding bug reports like this are really disliked last options.) So I would ask you to carry a patch simliar to the one proposed (maybe stripped, if you don't like the part about better solutions, security wise) until the next Debian version is released and then drop it again, so people on the next stable version can read it in the man page. If you agree I'm fine to further tune the patch. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Davide, hello Simon, On Thu, Aug 09, 2018 at 09:53:48PM +0200, Davide Prina wrote: > On 09/08/2018 21:06, Helge Kreutzmann wrote: > > >+Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent > >fast-user-switching feature in other desktop environments), > > here probably it is better to say that the user can switch from one to other > user with the Ctrl-Alt-Fx keys > > >+Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost". > > and here, I think it is better to write somethings like: > +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no $OTHERUSER@$LOCALHOST". > +Where $OTHERUSER is the user you want to use to execute commands > +and $LOCALHOST is your localhost (it can be: localhost, 127.0.0.1, ...) I introduced otheruser above. I updated the text to explicitly include localuser as well. > and probably it is better to mention that you need sshd process active in > your system (you must install openssh-server). Remember that this is not an introduction of how to use all those other tools but rather points to them. I explicitly referenced now the man page of ssh. > I don't know if it is better to evidence that with this solution you can > have performance problems and not all can work correctly as you expected. I think the man page is not the right place to discuss those issues. It is intended as first pointer for future reading or simply using (i.e. the user might now already about those solutions, but simply needs a gentle reminder). > >+Allow \fBsu\fR explicit display access by issuing "xhost > >+si:localuser:otheruser" in > > and here, I think it is better to write somethings like: > +explicit display access by issuing "xhost +si:localuser:$OTHERUSER" > ... > > >+the originating X session and "DISPLAY=:0 command" under \fBsu\fR. As stated above, I updated the introduction of the roles localuser and otheruser. > and here > +the originating X session and "DISPLAY=:0 $COMMAND" under \fBsu\fR. I don't know if using $COMMAND provides more clarity than command. > +or export the DISPLAY variable as "export DISPLAY=:0" > +and then execute all the commands with GUI you like: "$COMMAND &" > +where $COMMAND is the GUI command you like to exec (eg: qcalculate &) This is longer and I would rather avoid writing this, because using graphical applications should remain the exception, and explaining this here might people lend to have such shell open permanently and running much more than desired. And again, people who need this either know how to export the DISPLAY permanenetly or they can now look up other documentation to find out how to do it. Keep it short and simple and let the other documentation do its work. > Probably it is better to put some link to documentation > man sshd > man ssh_config > man sshd_config No, this is going beoynd what is needed here. In ssh(1) you get all the pointers. > man xhost I reworded the text to include this link. On Fri, Aug 10, 2018 at 08:13:05AM +0100, Simon McVittie wrote: > On Thu, 09 Aug 2018 at 21:06:37 +0200, Helge Kreutzmann wrote: > > +Further by default > > +.B su > > +does not allow the commands to access the current X display. > > This is perhaps misleading: su isn't allowing or denying anything, it's > the X server that isn't allowing other users to access it. Perhaps just > state the facts and let the user sort out the implications: "Unlike the > su implementation in Debian 9 and older releases, this su implementation > does not copy the X display address (DISPLAY) and credentials (XAUTHORITY) > to the commands"? I update the text. > There are two situations with different behaviour and expectations: > escalating privileges from a non-root user to root, and changing/dropping > privileges from a user (whether root or not) to a different non-root user. > > When escalating from an non-root user to root, the old su in src:shadow > copied the DISPLAY and XAUTHORITY variables to the root process. This > told X clients which X display they could use (DISPLAY), and also the > file containing credentials to use when authenticating to that display > (XAUTHORITY). The file whose name is the value of XAUTHORITY is normally > only readable by the user who owns the X display, but root can read it > anyway, because root is privileged and can exercise CAP_DAC_OVERRIDE. In > this situation, it is also unnecessary to defend against root being > able to escalate privileges to the invoking user (for instance via X > misconfiguration or via bugs like CVE-2016-2779), because root can do > that anyway. > > (It hopefully goes without saying that running X applications as root > is
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Chris, On Wed, Aug 08, 2018 at 08:58:24PM +0200, Chris Hofstaedtler wrote: > * Helge Kreutzmann [180808 18:57]: > > On Tue, Aug 07, 2018 at 08:20:23PM +0100, Simon McVittie wrote: > > > Andreas already asked for a merge request, so it seems that proposing a > > > patch would indeed be welcome. > > > > I'll do, incorporating your excellent explaination. I'll do so until > > the end of the week (latest). > > Gentle reminder about this. Here you are: --- ./su.1.orig 2017-09-27 11:05:13.717361420 +0200 +++ ./su.1 2018-08-09 21:04:24.370998117 +0200 @@ -261,6 +261,27 @@ .RS .br session required pam_lastlog.so nowtmp +.PP +.RE +Further by default +.B su +does not allow the commands to access the current X display. To allow +graphical applications with the privileges of a different user +(called "otheruser" in this example) several +options exists. These are, in order of preference (security-wise): +.RS 10 +.TP +o +Use a separate X display (e.g. "Switch User" in GNOME, or the equivalent fast-user-switching feature in other desktop environments), or a "thicker" remoting layer like VNC, Spice or Xpra. +.TP +o +Use ssh, e.g. "ssh -X -oForwardX11Trusted=no otheruser@localhost". +.TP +o +Allow \fBsu\fR explicit display access by issuing "xhost +si:localuser:otheruser" in +the originating X session and "DISPLAY=:0 command" under \fBsu\fR. +This has serious security implications and hence should only be used in +trusted environments. .RE .SH "SEE ALSO" .BR setpriv (1), Feel free to update. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#905409: upgrade of util-linux and login break the xhost command for other users
Hello Simon, On Tue, Aug 07, 2018 at 08:20:23PM +0100, Simon McVittie wrote: > On Mon, 06 Aug 2018 at 17:31:35 +0200, Helge Kreutzmann wrote: > > this change (requiring a DISPLAY=:0) is really suprising. I'v used su > > for ages and a simple xhost + (yes, I know that this has security > > implications) was sufficient. > > "xhost +" grants access to your display to *literally any user*, > including special-purpose system users like "nobody" and the users > that run network servers. Please avoid this pattern! If you need to > grant unlimited access to your display to another user, at least use > "xhost +si:localuser:$THEIR_USERNAME". (Or, again, consider using a > separate X display, or Xpra, or similar.) I'm aware, but thanks for the pointer anyhow. > > Plese document this in a public place, the best would be the man page > > as that is where users are looking for (a NEWS entry would only catch > > administrators once). > > > > I suggest putting it under NOTES. If you like, I can draft up a patch. > > Andreas already asked for a merge request, so it seems that proposing a > patch would indeed be welcome. I'll do, incorporating your excellent explaination. I'll do so until the end of the week (latest). Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#905409: Please document
Hello maintainers, this change (requiring a DISPLAY=:0) is really suprising. I'v used su for ages and a simple xhost + (yes, I know that this has security implications) was sufficient. Plese document this in a public place, the best would be the man page as that is where users are looking for (a NEWS entry would only catch administrators once). I suggest putting it under NOTES. If you like, I can draft up a patch. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#905124: Acknowledgement (abcde: Can't use an undefined value as an ARRAY reference at /usr/bin/abcde-musicbrainz-tool line 98)
Hello Steve, On Thu, Aug 02, 2018 at 03:55:34AM +0100, Steve McIntyre wrote: > On Wed, Aug 01, 2018 at 06:03:50PM +0200, Helge Kreutzmann wrote: > >I read in #892480 (which seems a similar issue) that you need the > >output of abcde with "-D" added. > > > >I attached it to this e-mail. > > ACK, thanks. There's an upstream fix for this already and I just need > to roll out a new release. Coming very soon - I'm at DebConf at the > moment so time is tight for the next few days. > > See https://git.einval.com/cgi-bin/gitweb.cgi?p=abcde.git > for the latest code if you're interested. I used the two updated files (modulo the changelog) from that git repository and abcde works normally (at least with this CD). Thanks for the hint! Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#905124: Acknowledgement (abcde: Can't use an undefined value as an ARRAY reference at /usr/bin/abcde-musicbrainz-tool line 98)
Hello Maintainers,
I'm trying to debug this. I added
my $key;
my $value;
foreach $key (keys %$response )
{
# $value = %$response ($key);
$value = $response->{$key};
print "Schlüssel: $key Wert: $value\n";
}
before the offending line and got the additional output:
Schlüssel: tracks Wert: ARRAY(0x557516e32b38)
Schlüssel: title Wert: Die Olchis im Bann des Magiers
Schlüssel: track-count Wert: 10
Schlüssel: id Wert: 15hnoNO43l2LUGvUkfXAwvWnOhQ-
Schlüssel: barcode Wert: 9783837306460
Schlüssel: artist Wert: Erhard Dietl read by Rainer Schmitt
Schlüssel: disambiguation Wert: CD 2 / 2
The values are as expected, but there is no key "releease" (and
subsequently no ARRAY behind it).
Sorry, I guess that is all I can do to debug this myself, please tell
me what other information are helpful for you.
Greetings
Helge
--
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/
signature.asc
Description: Digital signature
Bug#905124: Acknowledgement (abcde: Can't use an undefined value as an ARRAY reference at /usr/bin/abcde-musicbrainz-tool line 98)
Hello Maintainer(s), I read in #892480 (which seems a similar issue) that you need the output of abcde with "-D" added. I attached it to this e-mail. Greetings Helge -- 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/ + getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt + case "$opt" in + OUTPUTTYPE=mp3 + getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt + case "$opt" in + PADTRACKS=y + getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt + case "$opt" in + EXTRAVERBOSE=1 + getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt + case "$opt" in + EJECTCD=y + getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt + case "$opt" in + COMMENT='Ripped 01.08.2018 on samd' + getopts 1a:bBc:C:d:DefgGhj:klLmMnNo:pPQ:r:s:S:t:T:UvVxX:w:W:z opt + shift 8 + '[' n = y ']' + echo /dev/cdrom + grep -i '.flac$' + '[' -n '' ']' + '[' '' = flac ']' + '[' '' = '' ']' + for DEFAULT_CDROMREADER in $DEFAULT_CDROMREADERS + new_checkexec cdparanoia + '[' '!' cdparanoia = '' ']' ++ echo cdparanoia ++ cut '-d ' -f2 + X=cdparanoia ++ which cdparanoia + WHICH=/usr/bin/cdparanoia + '[' -z /usr/bin/cdparanoia ']' + '[' '!' -x /usr/bin/cdparanoia ']' + return 0 + CDROMREADERSYNTAX=cdparanoia + break + '[' cdparanoia = '' ']' + '[' '' = y ']' + '[' 0 -gt 0 ']' + DOCDDB=n + DOREAD=n + DONORMALIZE=n + DOPREPROCESS=n + DOENCODE=n + DOPOSTPROCESS=n + DOTAG=n + DOMOVE=n + DOREPLAYGAIN=n + DOPLAYLIST=n + DOCLEAN=n + '[' '' '!=' y ']' + DOCUE=n ++ echo cddb,read,encode,tag,move,clean ++ tr , ' ' + for ACTION in $(echo "$ACTIONS" | tr , \ ) + case $ACTION in + DOCDDB=y + for ACTION in $(echo "$ACTIONS" | tr , \ ) + case $ACTION in + DOREAD=y + for ACTION in $(echo "$ACTIONS" | tr , \ ) + case $ACTION in + DOENCODE=y + DOREAD=y + for ACTION in $(echo "$ACTIONS" | tr , \ ) + case $ACTION in + DOTAG=y + DOREAD=y + DOENCODE=y + DOCDDB=y + for ACTION in $(echo "$ACTIONS" | tr , \ ) + case $ACTION in + DOMOVE=y + DOTAG=y + DOREAD=y + DOENCODE=y + DOCDDB=y + for ACTION in $(echo "$ACTIONS" | tr , \ ) + case $ACTION in + DOCLEAN=y + '[' n = y ']' ++ echo year,genre ++ tr , ' ' + for SHOWCDDBFIELD in $(echo "$SHOWCDDBFIELDS" | tr , \ ) + case $SHOWCDDBFIELD in + SHOWCDDBYEAR=y + for SHOWCDDBFIELD in $(echo "$SHOWCDDBFIELDS" | tr , \ ) + case $SHOWCDDBFIELD in + SHOWCDDBGENRE=y + '[' X/dev/cdrom '!=' X ']' + '[' '' = y ']' + '[' '!' -e /dev/cdrom ']' + '[' X = Xy ']' + '[' X = Xy ']' + '[' n = y ']' + '[' Xmp3 = X ']' + case "$CDROMREADERSYNTAX" in + CDROMREADER=cdparanoia + CDROMREADEROPTS= + case "$NORMALIZERSYNTAX" in + NORMALIZER=normalize-audio + NORMALIZEROPTS= + case "$OUTPUTTYPE" in ++ echo mp3 ++ tr , ' ' + for OUTPUT in $(echo "$OUTPUTTYPE" | tr , \ ) + case $OUTPUT in + '[' default = default ']' + MP3ENCODERSYNTAX=lame + '[' y = y ']' + NEEDTAGGER=y + '[' n = y ']' + '[' '' = y ']' + case "$MP3ENCODERSYNTAX" in + MP3ENCODEROPTS= + MP3ENCODER=lame + case "$OGGENCODERSYNTAX" in + case "$OPUSENCODERSYNTAX" in + case "$MKAENCODERSYNTAX" in + case "$AIFFENCODERSYNTAX" in + case "$FLACENCODERSYNTAX" in + case "$SPEEXENCODERSYNTAX" in + case "$MPCENCODERSYNTAX" in + case "$WVENCODERSYNTAX" in + case "$TTAENCODERSYNTAX" in + case "$APENCODERSYNTAX" in + case "$MP2ENCODERSYNTAX" in + case "$AACENCODERSYNTAX" in + case "$ID3TAGV" in + TAGGER=eyeD3 + '[' 6 -lt 6 ']' + eyeD3 --help + grep -q -- --set-encoding + ID3SYNTAX=eyed3 + TAGGEROPTS='--encoding utf16 ' + '[' n = y ']' + case "$CUEREADERSYNTAX" in + CUEREADEROPTS=/dev/cdrom + CUEREADER=mkcue + case "$CDDBTOOL" in + '[' X = Xogg ']' + '[' 10 ']' + ENCNICE='-n 10' + '[' 10 ']'
Bug#905124: abcde: Can't use an undefined value as an ARRAY reference at /usr/bin/abcde-musicbrainz-tool line 98
Package: abcde Version: 2.9.1-1 Severity: grave Justification: renders package unusable On (old)stable I used a comment like the following for decades (last time on Sundy while I still was on stable), now after upgrading to testing it fails: $ abcde -o mp3 -p -V -x -w "Ripped 31.07.2018 on samd" Executing customizable pre-read function... done. Getting CD track info... Querying the CD for audio tracks... Grabbing entire CD - tracks: 01 02 03 04 05 06 07 08 09 10 abcde: attempting to resume from /scr/media/audio/VonCD/tmp/MP3/abcde.910ed70a.. . Found 0 matches so far Trying lookup method musicbrainz Obtaining Musicbrainz results... Can't use an undefined value as an ARRAY reference at /usr/bin/abcde-musicbrainz-tool line 98. [ERROR] abcde: abcde-musicbrainz-tool failed to run; ABORT I looked at the code. In line 88 "$response" is defined. I do not expect the CD to be found in musicbrainze (actually the first CD of the set was not found either, before the upgrade to testing). So I would expect in line 93 than an error was raised, which it seems to not do? Please tell me what I can do for debugging this. Thanks. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.10samd.01 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages abcde depends on: ii cd-discid 1.4-1+b1 ii cdparanoia 3.10.2+debian-13 ii lame3.100-2+b1 ii libmusicbrainz-discid-perl 0.04-1 ii libwebservice-musicbrainz-perl 1.0.4-2 ii vorbis-tools1.4.0-10.1 ii wget1.19.5-1 Versions of packages abcde recommends: pn bsd-mailx pn glyrc ii imagemagick 8:6.9.10.2+dfsg-3 ii imagemagick-6.q16 [imagemagick] 8:6.9.10.2+dfsg-3 ii libperl5.24 [libdigest-sha-perl] 5.24.1-3+deb9u4 ii perl [libdigest-sha-perl] 5.26.2-6 ii vorbis-tools 1.4.0-10.1 Versions of packages abcde suggests: ii atomicparsley0.9.6-1+b1 pn distmp3 ii eject2.1.5+deb1+cvs20081104-13.2 ii eyed30.8.5-1 ii id3 1.1.0-1 ii id3v20.1.12+dfsg-1 ii mkcue1-5+b1 pn mp3gain pn normalize-audio ii vorbisgain 0.37-2+b1 -- no debconf information -- 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/ signature.asc Description: Digital signature
Bug#894317: goobox: Drop Build-Depends on gconf
tags 894317 + pending
On Wed, Mar 28, 2018 at 09:33:29PM -0400, Jeremy Bicha wrote:
> Source: goobox
> Version: 3.4.2-7
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs gconf
> Tags: patch
>
> Your package build-depends on libgconf2-dev, but gconf will be removed from
> Debian soon.
>
> The good news is that it looks like the dependency is unnecessary. Please
> remove it. You can also remove the dh_gconf call from your debian/rules. (No
> patch attached but this should be fairly easy.)
Yep. Preparing a new release. Either today or it might take a few
days.
Greetings
Helge
--
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/
signature.asc
Description: Digital signature
Bug#852018: zapping: Segfaults immediately
tags 852018 +patch thanks Hello Bernhard, On Thu, Jan 26, 2017 at 05:30:07PM +0100, Bernhard Übelacker wrote: > Hello Helge, > net being the zapping maintainer, I just tried to have a look at it. Thanks! > It looks like alloc_aligned does truncate the pointer to 32 bits. > > Therefore storing the original pointer, for being able to free it later, > fails. > > common/alloc.c: > 37 p = (void *)(((long)((char *) b + align)) & -align); > > 1: b = (void *) 0x55c04a20 > 2: p = (void *) 0x55c04a40 > > Attached patch should fix the issue. > Even better would probably be build with HAVE_MEMALIGN defined. Yes, this patch works. I'll see that I get it into Debian testing as fast as possible. Thanks again Helge -- 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/ signature.asc Description: Digital signature
Bug#852018: zapping: Segfaults immediately
crip =
0x556301e9 "Disable video overlay",
argDescrip = 0x0}, {longName = 0x556301ff "remote", shortName =
0 '\000', argInfo = 0,
arg = 0x55896170 , val = 0,
descrip = 0x55630820 "X display is remote, disable video
overlay", argDescrip = 0x0}, {
longName = 0x55630206 "no-vbi", shortName = 105 'i', argInfo =
0,
arg = 0x5589616c , val = 0, descrip =
0x5563020d "Disable VBI support",
argDescrip = 0x0}, {longName = 0x55630221 "no-plugins",
shortName = 112 'p', argInfo = 0,
arg = 0x7fffdc3c, val = 0, descrip = 0x5563022c "Disable
plugins", argDescrip = 0x0}, {
longName = 0x5563023c "no-zsfb", shortName = 122 'z', argInfo =
0, arg = 0x7fffdc40, val = 0,
descrip = 0x55630244 "Obsolete", argDescrip = 0x0}, {longName =
0x5563024d "esd-out",
shortName = 0 '\000', argInfo = 0, arg = 0x5589613c
, val = 0,
descrip = 0x55630850 "Copy recorded sound to sound daemon",
argDescrip = 0x0}, {
longName = 0x55630255 "ivtv-audio", shortName = 0 '\000',
argInfo = 0,
arg = 0x55896138 , val = 0, descrip =
0x55630260 "Use ivtv audio device",
argDescrip = 0x0}, {longName = 0x55630276 "bpp", shortName = 98
'b', argInfo = 2,
arg = 0x7fffdc34, val = 0, descrip = 0x5563027a "Color
depth of the X display",
argDescrip = 0x55630297 "BPP"}, {longName = 0x556302b3
"debug", shortName = 100 'd',
argInfo = 0, arg = 0x55896154 , val = 0, descrip =
0x5563029b "Print debug messages",
argDescrip = 0x0}, {longName = 0x556302b0 "io-debug", shortName
= 0 '\000', argInfo = 0,
arg = 0x55896150 , val = 0, descrip = 0x0,
argDescrip = 0x0}, {
longName = 0x556302b9 "dword-align", shortName = 0 '\000',
argInfo = 0, arg = 0x7fffdc38,
val = 0, descrip = 0x55630878 "Force dword alignment of the
overlay window", argDescrip = 0x0}, {
longName = 0x556302c5 "command", shortName = 99 'c', argInfo =
1, arg = 0x7fffdc50, val = 0,
descrip = 0x556308a8 "Execute the given command and exit",
argDescrip = 0x55638262 "CMD"}, {
longName = 0x556302cd "yuv-format", shortName = 121 'y',
argInfo = 1, arg = 0x7fffdc58, val = 0,
---Type to continue, or q to quit---
descrip = 0x55630244 "Obsolete", argDescrip = 0x0}, {longName =
0x556302d8 "tunerless-norm",
shortName = 110 'n', argInfo = 1, arg = 0x7fffdc60, val = 0,
descrip = 0x55630244 "Obsolete",
argDescrip = 0x0}, {longName = 0x556302e7 "cpu-features",
shortName = 0 '\000', argInfo = 1,
arg = 0x7fffdc68, val = 0, descrip = 0x556302f4 "Override
CPU detection", argDescrip = 0x0}, {
longName = 0x0, shortName = 0 '\000', argInfo = 0, arg = 0x0, val =
0, descrip = 0x0, argDescrip = 0x0}}
__func__ = "main_0_10cvs6"
__PRETTY_FUNCTION__ = "main_0_10cvs6"
#10 0x737772b1 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#11 0x55586f3a in _start ()
No symbol table info available.
Downgrading to 0.10~cvs6-10+b1 make zapping usuable again as expected.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.15samd.01-grsec (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages zapping depends on:
ii gconf-service 3.2.6-4
ii gconf2 3.2.6-4
ii libc6 2.24-8
ii libesd0 0.2.41-11
ii libgconf-2-43.2.6-4
ii libgdk-pixbuf2.0-0 2.36.3-1
ii libglade2-0 1:2.6.4-2
ii libglib2.0-02.50.2-2
ii libgnome-2-02.32.1-5
ii libgnomeui-02.24.5-3.1
ii libgnomevfs2-0 1:2.24.4-6.1+b1
ii libgtk2.0-0 2.24.31-1
ii libjpeg62-turbo 1:1.5.1-2
ii liblirc-client0 0.9.4c-7
ii libpango-1.0-0 1.40.3-3
ii libpng16-16 1.6.28-1
ii libpython2.72.7.13-1
ii libx11-62:1.6.4-2
ii libxext62:1.3.3-1
ii libxinerama12:1.1.3-1+b1
ii libxml2 2.9.4+dfsg1-2.1
ii libxmu6 2:1.1.2-2
ii libxv1 2:1.0.11-1
ii libxxf86dga12:1.1.4-1+b1
ii libxxf86vm1 1:1.1.4-1
ii libzvbi00.2.35-13
zapping recommends no packages.
zapping suggests no packages.
-- no debconf information
--
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/
signature.asc
Description: Digital signature
Bug#806418: mediathekview: Spawns VLC-process with fills up hard disc space 100% without being told to do so
Package: mediathekview
Version: 7.1-1
Severity: grave
Dear Maintainer,
I use mediathekview a lot, althought not on this system (which is
actually only a VM). I never experienced this problem before, but now
repeatedly which makes mediathekview and the entire system unusuable.
I will check on my main system next week.
Steps to reproduce:
1: Start Mediathekview
2. Acknowledge newer version and missing programms (only on first
call, not on subsequent ones).
3. Select "Sandmann" in Thema/Titel. Select a "Sandmännchen" and
choose (Right Mouse button) "Film aufzeichnen".
4. Choose "OK"
5. Sometimes the download works as expected, but in most cases the
following happens:
a) a vlc process appears, ps aux tells me:
kreutzm+ 27684 15.0 1.3 762504 28124 pts/4Sl+ 10:45 0:04
/usr/bin/vlc
http://http-stream.rbb-online.de/san/sendung/sendung_20151126_lennart_im_grummetal_lecker_kraecker_WEB_L_16_9_960x544.mp4?url=5
:sout=#standard{access=file,mux=ts,dst=/home/kreutzmannhelge/MediathekView/Sandmann/Sandmann-Unser_Sandmännchen_vom_26.11.2015-sendung_20151126_lennart_im_grummetal_lecker_kraecker_WEB_L_16_9_960x544.mp4.ts}
-I dummy --play-and-exit
b) Mediathekview does not give visual feedback at all (at least I
don't see any). Also no (vlc) window appears.
c) In the following seconds / minutes the hard disc is completely
filled up, if I delete files the space is immediately occupied by a
(bogus?) ts file, i.e.
root@debian:/home/kreutzmannhelge/MediathekView/Sandmann# ls -hltr
insgesamt 5,1G
-rw-r--r-- 1 kreutzmannhelge kreutzmannhelge 5,1G Nov 27 10:51
Sandmann-Unser_Sandmännchen_vom_26.11.2015-sendung_20151126_lennart_im_grummetal_lecker_kraecker_WEB_L_16_9_960x544.mp4.ts
Note that this file should be ~ 127 MB.
d) The system (which is a single partion set up as recommended by the
debian installer) breaks, i.e. many processes / programms no longer
work as no space is left. When I discovered this two days ago it took
me quite some time (and I deleted quite some files first) before I
discovered the root cause and killed (requires -9!) the unwanted vlc process and
removed the > 5 GB file.
Please note, that after kill -9 mediathekview brings a pop up that the
downlaod was erreounus ("fehlerhaft").
Two notes:
a) If I actually choose "Film (URL) abspielen" vlc starts as expected
and plays the file.
b) If I actually choose "URL kopieren" and use wget to download the
file I get a file which can be played and has an expected size
(although a different date and name then I expected).
I only use this VM occasionally when travelling, so I don't know when
exactly it started to appear. It definitley worked in October, but
broke on Wednesday.
Regarding the severity: The system became almost unusaable (many
programs behave strange when no space is left) while mediathekview was
giving me no indication of the problem. I really was not expecting the
problem here (rather in some database of logging process). Also there
is no obvious way to resolve the issue, e.g. cloisng mediathekview
does not kll the vlc process and remove the bogous (big) file. Thus
the severity.
If you have any (further) questions or tests you would like me to make
please do not hesitate to ask. Also I only have occasional access to
this system so it would be great if we could do the tests this
weekend. I'll also check how my ordinary system behaves on monday
evening. (Though there a more advanced partitioning system has been
used, reducing the impact of this bug).
-- System Information:
Debian Release: 8.2
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages mediathekview depends on:
ii default-jre [java7-runtime]2:1.7-52
ii java-wrappers 0.1.28
ii libcommons-compress-java 1.9-1
ii libcommons-lang3-java 3.3.2-1
ii libjackson2-core-java 2.4.2-2
ii libjgoodies-forms-java 1.6.0-4
ii libjide-oss-java 3.6.2+dfsg-1
ii libmac-widgets-java0.10.0+svn416-dfsg1-1
ii libswingx-java 1:1.6.2-2
ii libtimingframework-java1.0-1
ii libxz-java 1.5-1
ii openjdk-7-jre [java7-runtime] 7u91-2.6.3-1~deb8u1
Versions of packages mediathekview recommends:
ii flvstreamer 2.1c1-1
ii vlc 2.2.0~rc2-2+deb8u1
Versions of packages mediathekview suggests:
pn libav-tools
-- no debconf information
--
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/
signature.asc
Description: Digital signature
Bug#788484: netsurf-gtk: Nothing visual happens
t/urldb.c urldb_load 534: Successfully loaded URL file (0.164733) gtk/gui.c gui_init 417: Set CSS DPI to 96.151367 (0.166221) desktop/treeview.c treeview_init 3849: Initialising treeview module (0.166298) desktop/treeview.c treeview_init 3871: Initialised treeview module (0.166308) desktop/global_history.c global_history_init 718: Loading global history (0.166333) gtk/font_pango.c nsfont_pango_check 61: Creating nsfont_pango_context. (0.166346) gtk/font_pango.c nsfont_pango_check 66: Creating nsfont_pango_layout. (0.168632) desktop/global_history.c global_history_init 774: Loaded global history (0.171064) desktop/cookie_manager.c cookie_manager_init 760: Generating cookie manager data (0.171341) desktop/cookie_manager.c cookie_manager_init 797: Generated cookie manager data (0.172778) desktop/hotlist.c hotlist_init 1148: Loading hotlist (0.173436) desktop/hotlist.c hotlist_init 1185: Loaded hotlist Please tell me which other information you need to debug this issue. -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.69sneo.01-grsec (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages netsurf-gtk depends on: ii libc62.19-18 ii libcairo21.14.0-2.1 ii libcurl3 7.38.0-4+deb8u2 ii libexpat12.1.0-6+b3 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgtk2.0-0 2.24.25-3 ii libjpeg62-turbo 1:1.3.1-12 ii libmozjs185-1.0 1.8.5-1.0.0+dfsg-4.3 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpng12-0 1.2.50-2+b2 ii librsvg2-2 2.40.5-1 ii libssl1.0.0 1.0.1k-3 ii netsurf-common 3.2+dfsg-2 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages netsurf-gtk recommends: ii mime-support 3.58 netsurf-gtk suggests no packages. -- no debconf information -- 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/ signature.asc Description: Digital signature
Bug#779663: sound-juicer: debian/copyright incomplete
Package: sound-juicer Version: 3.14.0-1 Justification: Policy 12.5 Severity: serious I'm unsure about the severity, reading debian policy it might "only" be important, please correct severity if I'm mistaken. debian/copyright is outdated and incomplete. Example: sj-cell-renderer-text.c: * Copyright (C) 2014 Phillip Wood however, Phillip Wood is not in debian/copyright debian/copyright says: ... debianized ... 2013 however, the latest year is 2008. The latest upstream release in Debian is from 2014 however, the latest year is 2008. I did not continue the investigation. -- 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/ signature.asc Description: Digital signature
Bug#766353: [libjpeg-progs] Conflicts with libjpeg-turbo-progs 1:1.3.1-3
Hello, I just ran into this as well. On Sat, Oct 25, 2014 at 06:56:05PM +0200, Bill Allombert wrote: > On Sat, Oct 25, 2014 at 05:57:39PM +0200, Michael Banck wrote: > > severity 766353 serious > > thanks > > > > On Wed, Oct 22, 2014 at 04:30:54PM +0200, Bill Allombert wrote: > > > On Wed, Oct 22, 2014 at 03:20:41PM +0200, Rafael Belmonte wrote: > > > > Package: libjpeg-progs > > > > Version: 1:9a-2 > > > > Severity: important > > > > > > > > --- Please enter the report below this line. --- > > > > The package is not installable or upgradable if libjpeg-turbo-progs > > > > is already installed. > > > > This is the apt-get output: > > > > dpkg: error processing archive > > > > /var/cache/apt/archives/libjpeg-progs_1%3a9a-2_i386.deb (--unpack): > > > > trying to overwrite '/usr/share/man/man1/exifautotran.1.gz', which > > > > is also in package libjpeg-turbo-progs 1:1.3.1-3 > > > > I ran into this as well just now when upgrading jessie. > > > > > Indeed, you need to remove the broken libjpeg-turbo-progs 1:1.3.1-3 > > > before the upgrade. Later version of libjpeg-turbo-progs are fixed. > > > > Erm, in that case, there should be additional Conflicts/Replaces > > whatever relationships, methinks? > > libjpeg-turbo-progs 1:1.3.1-3 is RC buggy and has never been part of a stable > release, so I do not think this is necessary. Why? a) On my machine, which run stable up to about ~1.5 month ago I never explicitly installed libjpeg-turbo-progs, so stable users who upgrade are most likly affected. (I only run dist-ugprade) b) It is (more than) a courtesy for users / developers who run testing c) RC-buggy packages are removed from the testing suite in the archives, but not from users machines (and, btw. libjpeg-turbo is no longer rc-buggy) d) Looking at debian-policy, I read: It is usually an error for a package to contain files which are on the system in another package. I do not see an exception for rc-buggy relationships or such. Further as I understand it, it is the normal procedure for taking over files, to use breaks/replaces. e) Is there any problem of uploading libjpeg-progs just with the appropriate breaks/relationship? I think the RMs would have no problem accelerating this into testing. > The cause of the breackage you see is that the fixed libjpeg-turbo-progs > 1:1.3.1-d for d>3 reached much later than I expected and in particular after > libjpeg-progs 9-2. Sorry, I don't understand this sentence. Greetings Helge -- 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/ signature.asc Description: Digital signature
Bug#749237: L10N NMU initiated
Hello Charlie, I just sent the NMU to Tobias Quathamer , he will upload it in the next days to a delayed queue. Please note that this NMU also fixes the RC bug 749237; please verify that ampache indeed still works (from the bug log I understood a simply rebuild should be sufficient). Greetings Helge -- 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/ signature.asc Description: Digital signature
