Bug#988584: manpages-hu: Contains undistributable content - All rights reserved
Hello, Helge Kreutzmann schrieb am So., 16. Mai 2021, 12:27: > 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? See below for the plans to get rid of this outdated stuff. > 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). > We are planning to merge the remaining outdated manpages-* packages into manpages-l10n anyway. So manpages-hu will be the next candidate for the import. I will create a framework for Hungarian soon, and import the old files step by step. The creation of the translated versions remains disabled until the import is finished; once it is done, manpages-hu needs to be removed from Debian to avoid package conflicts. Best Regards, Mario
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Am Mi., 10. Feb. 2021 um 16:52 Uhr schrieb Helge Kreutzmann : > > 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? > The plan is to ship the imported (and until then hopefully somewhat updated) files with the next major release of manpages-l10n in march/april. But it wouldn't make sense to add the files to the Git repo as late as possible, giving translators no time to work on the updates. > I contacted the maintainer (cf. #980885, which you also contributed > to), but he did not respond yet, unfortunately. > I know... The more time we loose, the less chance is to get rid of the manpages-es-extra package before Bullseye gets frozen. But let's concentrate first on the file conflicts raised with psmisc and procps. Best Regards, Mario
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello, 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. Best Regards, Mario Am Di., 9. Feb. 2021 um 19:40 Uhr schrieb Helge Kreutzmann : > > 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.9.1-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/
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello, > > 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. > I'm not familiar with Debian packaging, but it looks a bit strange... The »Breaks:« line seems to be OK, but if psmisc »replaces« manpages-de-4.2.0 and someone installs psmisc-23.4, could it happen that manpages-de-4.2.0 will be deleted, without updating it to v4.9.1? Best Regards, Mario
Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz
Hello all, our project manpages-l10n is actually the second best solution to provide translated man pages. The files are always somewhat older than the original ones, because we download distribution packages, extract the man pages, translate the contents and release a new version every three months. If man page translations are maintained directly in the appropriate upstream projects, there's no delay, and the translated versions are always up-to-date. That's why the latter way is always to prefer. For this reason I try to encourage upstream projects to implement a po4a stack -- with varying degrees of success... Of course, I knew about the raised file conflicts. Yesterday we have released manpages-l10n v4.9.1 [1], without the psmisc translations. This solves the problem without forcing packagers to find some workarounds -- at the risk of that they disable the conflicting man pages in psmisc instead of manpages-l10n. Once the maintainers of the Debian package (CC'ing them) have updated it, all is fine again. BTW, the same applies to procps-ng. Once the final v3.3.17 has been released, I will do a bugfix release of manpages-l10n with the procps man pages removed. [1] https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/tags/v4.9.1 Best Regards, Mario Am So., 7. Feb. 2021 um 01:51 Uhr schrieb Craig Small : > > Yep, psmisc now ships with translated packages. So fuser.1 and friends are in > two places. > > So manpages-de has fuser, killall, peekfd, pslog and pstree but not prstat. > There is also manpages-nl and manpages-pl but neither of those languages are > in psmisc. psmisc has ft, pt_BR, ru and uk and the corresponding manpage-* > packages don't have the psmisc man pages. > > So the psmisc overlap is only with manpages-de. > > We can tackle this a few ways, but Debian should only ship one! As luck would > have it, both manpages-de[1] and the upstream issue for psmisc[2] come the > same person, Mario Blättermann who I have CC'ed. > > Hi Mario, as upstream for both sets of translations, what's your future > plans? Keep both? Ship only one or prefer one over the other? I've happy > enough to either remove the clashing de manpages or put a Replaces line in to > override it, but I'd like to line it up with what upstream for both is > planning on doing. > > - Craig > > 1: > https://salsa.debian.org/debian/manpages-l10n/-/blob/master/debian/copyright#L1890 > 2: https://gitlab.com/psmisc/psmisc/-/issues/22 > > > On Sat, 6 Feb 2021 at 16:48, Axel Beckert wrote: >> >> Package: manpages-de,psmisc >> Severity: serious >> Version: manpages-de/4.2.0-1 >> Version: psmisc/23.4-1 >> >> Hi, >> >> there seems a new file conflict between manpages-de (uploaded in >> December) and the most recent psmisc upload: >> >> As I first run into it: >> >> Unpacking psmisc (23.4-1) over (23.3-1) ... >> dpkg: error processing archive >> /tmp/apt-dpkg-install-IViNm3/17-psmisc_23.4-1_i386.deb (--unpack): >> trying to overwrite '/usr/share/man/de/man1/fuser.1.gz', which is also in >> package manpages-de 4.2.0-1 >> >> But of course also happens the opposite way: >> >> Unpacking manpages-de (4.2.0-1) ... >> dpkg: error processing archive >> /var/cache/apt/archives/manpages-de_4.2.0-1_all.deb (--unpack): >> trying to overwrite '/usr/share/man/de/man1/fuser.1.gz', which is also in >> package psmisc 23.4-1 >> >> Please decide which package should ship that man page. >> >> -- System Information: >> Debian Release: bullseye/sid >> APT prefers unstable >> APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), >> (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), >> (1, 'buildd-experimental') >> Architecture: amd64 (x86_64) >> Foreign Architectures: i386 >> >> Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) >> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set >> Shell: /bin/sh linked to /bin/dash >> Init: sysvinit (via /sbin/init) >> LSM: AppArmor: enabled
Bug#956013: Fails to install
Hi David, David Prévot schrieb am Mo., 6. Apr. 2020, 18:51: > Le 06/04/2020 à 02:39, Dr. Tobias Quathamer a écrit : > > > I think that this bug is now fixed in git. If you have the time, I'd > > value your input if I've thought of everything before I start another > > upload cycle. > > I very much doubt it is manpages-l10n task to take over > manpages-fr-extra (especially via a transnational dummy package). > It *is* the task of manpages-l10n because the source tarball contains translations which were previously maintained within manpages-fr-extra. Well, alternatively we could disable the man pages which come from there and keep publishing the old manpages-fr-extra package again and again, with all the outdated stuff it contains. Doesn't make sense at all. Instead, let's go a step ahead and switch to up-to-date man pages. Best Regards, Mario Anyway, adding a manpages-fr-extra package with a version lower the one > currently in unstable will not supersede it. > > Regards > > David > >
Bug#802260: gnome-gmail: Some dependencies missing
Package: gnome-gmail
Version: 1.9.3-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
after installing gnome-gmail in Stretch, I was a bit surprised about the few
extra dependencies which have to be installed on a KDE-only system. After
launching gnome-gmail then, I got some error messages, gnome-gmail didn't
start:
mariobl@debian:~$ gnome-gmail
/usr/share/gnome-gmail/gnomegmail.py:37: PyGIWarning: Gtk was imported without
specifying a version first. Use gi.require_version('Gtk', '3.0') before import
to ensure that the right version gets loaded.
from gi.repository import Gtk
/usr/share/gnome-gmail/gnomegmail.py:41: PyGIWarning: Secret was imported
without specifying a version first. Use gi.require_version('Secret', '1')
before import to ensure that the right version gets loaded.
from gi.repository import Secret
/usr/share/gnome-gmail/gnomegmail.py:42: PyGIWarning: Notify was imported
without specifying a version first. Use gi.require_version('Notify', '0.7')
before import to ensure that the right version gets loaded.
from gi.repository import Notify
Traceback (most recent call last):
File "/usr/share/gnome-gmail/gnomegmail.py", line 43, in
from gi.repository import Wnck
ImportError: cannot import name Wnck
According to the messages, I installed python-wnck and gir1.0-wnck-3.0. The
messages have been shrinked a bit, and I the setup window has been opened where
I could submit my Gmail address. But there remain some terminal messages, and
gnome-gmail is still unusable:
mariobl@debian:~$ gnome-gmail
/usr/share/gnome-gmail/gnomegmail.py:37: PyGIWarning: Gtk was imported without
specifying a version first. Use gi.require_version('Gtk', '3.0') before import
to ensure that the right version gets loaded.
from gi.repository import Gtk
/usr/share/gnome-gmail/gnomegmail.py:41: PyGIWarning: Secret was imported
without specifying a version first. Use gi.require_version('Secret', '1')
before import to ensure that the right version gets loaded.
from gi.repository import Secret
/usr/share/gnome-gmail/gnomegmail.py:42: PyGIWarning: Notify was imported
without specifying a version first. Use gi.require_version('Notify', '0.7')
before import to ensure that the right version gets loaded.
from gi.repository import Notify
/usr/share/gnome-gmail/gnomegmail.py:43: PyGIWarning: Wnck was imported without
specifying a version first. Use gi.require_version('Wnck', '3.0') before import
to ensure that the right version gets loaded.
from gi.repository import Wnck
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 103, in
_builder_connect_callback
handler, args = _extract_handler_and_args(obj_or_map, handler_name)
File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 83, in
_extract_handler_and_args
raise AttributeError('Handler %s not found' % handler_name)
AttributeError: Handler onUserSelClose not found
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 103, in
_builder_connect_callback
handler, args = _extract_handler_and_args(obj_or_map, handler_name)
File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 83, in
_extract_handler_and_args
raise AttributeError('Handler %s not found' % handler_name)
AttributeError: Handler onOkClicked not found
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Traceback (most recent call last):
File "/usr/share/gnome-gmail/gnomegmail.py", line 765, in
main()
File "/usr/share/gnome-gmail/gnomegmail.py", line 762, in main
browser().open(gmailurl, new_browser, True)
File "/usr/share/gnome-gmail/gnomegmail.py", line 63, in browser
bpath = app.get_filename()
AttributeError: 'NoneType' object has no attribute 'get_filename'
Maybe it's only about missing dependencies... On a Fedora 23 system, with
similar software versions, gnome-gmail works as expected, although it is
actually Gnome 2 software.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.2.0-1-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 gnome-gmail depends on:
ii gir1.2-secret-1 0.18.3-1
ii libgtk-3-bin 3.16.6-1
ii python-gi3.18.0-1
ii python2.72.7.10-5
gnome-gmail recommends no packages.
gnome-gmail suggests no packages.
-- no debconf information
Bug#800468: crashes in liblmdb on start-up
On 03.10.2015 19:42, Felix Geyer wrote: Hi, On Sat, 03 Oct 2015 15:58:34 +0200 Mario Blättermann wrote: Same behavior on a freshly installed Stretch. The gdb output: (gdb) run Starting program: /usr/bin/dolphin [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe235a700 (LWP 14801)] [New Thread 0x7fffdafbd700 (LWP 14802)] Program received signal SIGSEGV, Segmentation fault. 0x7fffead34960 in mdb_txn_begin () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 It happened after I tried to config Dolphin to let the preview sidebar appear. Could you please test if upgrading libkf5baloo5 and libkf5balooengine5 to 5.14.0-2 (unstable) fixes the crash? All is fine again :) Dolphin starts as usual, and I'm able to open the desired preview sidebar using F11. The Problem has been solved for me. Best Regards, Mario
Bug#800468: crashes in liblmdb on start-up
Same behavior on a freshly installed Stretch. The gdb output: (gdb) run Starting program: /usr/bin/dolphin [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe235a700 (LWP 14801)] [New Thread 0x7fffdafbd700 (LWP 14802)] Program received signal SIGSEGV, Segmentation fault. 0x7fffead34960 in mdb_txn_begin () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0 It happened after I tried to config Dolphin to let the preview sidebar appear. Best Regards, Mario
