Bug#1066903: libgnt: please drop runtime dependencies
This sounds reasonable to. It looks like you beat me to this with an
NMU. Thanks!
On 2024-03-15 04:08, Gianfranco Costamagna wrote:
Package: libgnt
Version: 2.14.4-1.1
Severity: serious
Tags: patch
Hello, I found some runtime dependencies, such as removed libglib2.0-0
breaking every 32bit build except i386 due to
time64_t transition.
Please update, remove them, let debhelper evaluate them via shlibs:Depends.
Also I added libxml2-dev build-dependency, looks like the support was
not enabled.
before:
Run-time dependency glib-2.0 found: YES 2.79.3
Run-time dependency gobject-2.0 found: YES 2.79.3
Run-time dependency gmodule-2.0 found: YES 2.79.3
Did not find CMake 'cmake'
Found CMake: NO
Run-time dependency libxml-2.0 found: NO (tried pkgconfig and cmake)
Now:
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
Run-time dependency glib-2.0 found: YES 2.79.3
Run-time dependency gobject-2.0 found: YES 2.79.3
Run-time dependency gmodule-2.0 found: YES 2.79.3
Run-time dependency libxml-2.0 found: YES 2.9.14
Also dpkg shows correct dependencies now:
Package: libgnt0t64
[...]
Depends: libc6 (>= 2.38), libglib2.0-0t64 (>= 2.75.3), libncursesw6 (>=
6), libtinfo6 (>= 6), libxml2 (>= 2.7.4)
Breaks: finch (<< 2.14.1), libgnt0 (<< 2.14.4-1.2)
Replaces: finch (<< 2.14.1), libgnt0
Provides: libgnt0 (= 2.14.4-1.2)
[...]
Thanks for considering the patch.
*** /tmp/tmpkfjro47y/libgnt_2.14.4-1.1ubuntu1.debdiff
diff -Nru libgnt-2.14.4/debian/control libgnt-2.14.4/debian/control
--- libgnt-2.14.4/debian/control 2024-03-08 06:22:50.0 +0100
+++ libgnt-2.14.4/debian/control 2024-03-15 09:59:05.0 +0100
@@ -1,6 +1,7 @@
libglib2.0-dev,
libglib2.0-doc,
libncurses-dev,
+ libxml2-dev,
meson,
Build-Depends-Indep: gtk-doc-tools,
Homepage: https://keep.imfreedom.org/libgnt/libgnt
@@ -18,10 +18,7 @@
Package: libgnt0t64
Provides: ${t64:Provides}
Architecture: any
-Depends: libglib2.0-0,
- libncursesw6,
- libxml2,
- ${misc:Depends},
+Depends: ${misc:Depends},
${shlibs:Depends},
Breaks: libgnt0 (<< ${source:Version}), finch (<< 2.14.1),
Replaces: libgnt0, finch (<< 2.14.1),
--
Richard
OpenPGP_signature.asc
Description: OpenPGP digital signature
Bug#1058511: ntpsec: FTBFS: mv: cannot stat 'debian/tmp/lib/systemd/system/ntpd.service': No such file or directory
Control: fixed 1.2.2+dfsg1-3 This looks to be the same as #1052664. -- Richard OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057570: libgnt: FTBFS: error: invalid use of incomplete typedef ‘PANEL’ {aka ‘struct panel’}
On 2023-12-20 09:57, Sven Joachim wrote: I have not tested it myself, but these errors should be fixed in libgnt 2.14.4 which has been released upstream the other day. See https://keep.imfreedom.org/libgnt/libgnt/rev/2da723f790d6, which explicitly mentions this bug. Thanks for letting me know! -- Richard
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
Is this reproducible for you? If you have experience with building from source, upstream has proposed the following patch. Otherwise, I could build a test package for you. diff --git a/ntpd/nts_cookie.c b/ntpd/nts_cookie.c index 166d0230f..a73955fb7 100644 --- a/ntpd/nts_cookie.c +++ b/ntpd/nts_cookie.c @@ -382,6 +382,9 @@ bool nts_unpack_cookie(uint8_t cookie, int cookielen, if (NULL == cookie_ctx) return false; /* We aren't initialized yet. */ + + if (0 == nts_nKeys) + return false; /* No cookies. We are not an NTS server. */ /* We may get garbage from the net */ if (cookielen > NTS_MAX_COOKIELEN) return false; -- Richard
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
Some questions from upstream, with my commentary added... How busy is this sustem? Is it just a simple client or also a server? If server, how busy? From the stack trace, the server side is trying to decode a NTS cookie. Is this box setup as a NTS server? That needs a certificate and key so it takes more than just upgrading from bullseye to bookworm. It's not, right? We previously established that this is using the stock ntp.conf? What are the chances that a valid NTP request with NTS arrived at this system? ntpq -c ntsinfo will show counters. It would be good if you could check this. But if an NTS request is crashing ntpd, you might never see non-zero counters. The log file from starting up might be helpful. -- Richard
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
On 2023-06-28 20:14, forest.ow...@riseup.net wrote: On 2023-06-28 02:39, Richard Laager wrote: The original submitter replied off the tracker (probably by accident). I'll summarize here. The ntp.conf he included is the stock ntp.conf. He indicated he will try to get a backtrace. I'm trying to setup ntpsec to get a backtrace. I installed the ntpsec-dbgsym package, but I'm not sure that I did it correctly. Shouldn't the output from this file command include the text "no stripped". I don't think it should change that. I think the debug symbols end up somewhere else. -- Richard
Bug#1036113: libpurple0: license conflict with libsasl2
On 2023-06-27 17:35, Bastian Germann wrote: Am 28.06.23 um 00:13 schrieb Richard Laager: The last bugfix release took them more than 3 years and when #767 is released is unknown. When a release happens is irrelevant, as you can carry #767 as a patch in the Debian package until then. Even when that happens, upstream still has to eliminate the last instance of the RSA-MD license. What is the remaining instance of RSA-MD licensed code after #767? License compliance will not just magically happen by ignoring the problematic parts in Debian. I didn't suggest it would, nor am I ignoring anything. My point is that, in this particular case, it seems that you have everything solved or close to solved by yourself. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
The original submitter replied off the tracker (probably by accident). I'll summarize here. The ntp.conf he included is the stock ntp.conf. He indicated he will try to get a backtrace. -- Richard
Bug#1036113: libpurple0: license conflict with libsasl2
Wait a minute... You are a maintainer for cyrus-sasl. You have already addressed the BSD-4-clause-KTH in the latest upload. You also fixed debian/copyright to reference BSD-3-Clause-Attribution in the latest upload. That license is fine for the reasons I mentioned. That just leaves the MD5 stuff, right? You have authored a fix for that, which it looks like will be merged shortly: https://github.com/cyrusimap/cyrus-sasl/pull/767 It seems like you can have this fixed any time (by merging in upstream #767) and will have it fixed shortly. So why do I need to do anything? -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1036113: libpurple0: license conflict with libsasl2
Bastian, I see you have raised the severity on this bug again. What is your goal here? Cyrus SASL has reverse (binary) dependencies in the ballpark of 7,500. Quickly taking that list through UDD gives me just over 4,500 source packages. Surely, a large number of those are going to be GPL licensed. Is your plan to file Severity: serious bugs against all of them? If so, isn't that an MBF that needs discussion on debian-devel first? If not, then why are you singling out Pidgin, a project that is struggling to stay alive right now? Your position in bug #996892 is that cyrus-sasl2 / libsasl2 should be considered a system library. If libsasl2 can be considered a system library, then by your own position, there is no bug in libpurple0. I don't see how you can have it both ways. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]
I'm not sure if you saw this, as he didn't send it directly to you, but Matt Selsky asked: > Can you please share your ntp.conf or if there's a particular server > that seems to cause this segfault so that we can try to reproduce it? Also, can you get a stack trace? There are some instructions in the Debian wiki: https://wiki.debian.org/HowToGetABacktrace -- Richard
Bug#1012600: [Pkg-zfsonlinux-devel] Bug#1012600:
I think this is because it Depends: a kernel << 5.18 and not Conflicts/Breaks a kernel >= 5.18. Since you can install multiple kernel packages, your existing kernel package is satisfying the dependency. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1011166: [Debian-on-mobile-maintainers] Bug#1011166: Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0
On 5/20/22 01:56, Evangelos Ribeiro Tzaras wrote: Hi, On Thu, 2022-05-19 at 22:23 -0500, Richard Laager wrote: On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote: Thanks for the patch! I'll upload a fixed version soon. If you upload a new version, you (or I) can then close the binNMU request, bug #1011201. I have prepared an update on salsa [0]. I was wondering one thing though: The packaging used to have override dh_shlibdeps: dh_shlibdeps -l/usr/lib/purple-2 which I stripped, because a) the path is now wrong b) it doesn't seem to get used at all, judging by compairing packages built with an updated path and without the override Since I'm not 100% sure if this was ever actually needed, I was curious if you could potentially shed some light ;) No idea. Judging from the description in the man page, it's probably not necessary. And your testing seemingly confirms that. I think you're right to strip it. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1011166: [Debian-on-mobile-maintainers] Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0
On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote: Thanks for the patch! I'll upload a fixed version soon. If you upload a new version, you (or I) can then close the binNMU request, bug #1011201. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0
Control: notfound 1011166 pidgin/2.14.9-2
Control: tags 1011166 patch
On 5/17/22 15:34, Paul Gevers wrote:
I note that
the library moved location from /usr/lib/purple-2/libjabber.so.0.0.0 to
/usr/lib/x86_64-linux-gnu/purple-2/libjabber.so.0.0.0.
I converted from an ancient compat version to modern debhelper. This
brought in multiarch support. Rather than fight it, I just went with
that, since the problem looked tractable.
Naively I would
have expected it to be picked up, but maybe the /purple-2 in the middle
of the path is preventing that.
-- BEGIN RED HERRING --
I would expect it to be picked up.
libpurple/plugin.c sets up the search path for that purple-2 directory
(which is where all libpurple plugins are installed):
purple_plugins_add_search_path(LIBDIR);
In libpurple/Makefile.am, AM_CPPFLAGS has:
-DLIBDIR=\"$(libdir)/purple-$(PURPLE_MAJOR_VERSION)/\"
This should cause us to find libxmpp.so, the protocol plugin. It then
needs to bring in libjabber.so, an internal library. It should be
finding this with RUNPATH, I believe:
$ readelf -a /usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so | grep -i path
0x001d (RUNPATH)Library runpath:
[/usr/lib/x86_64-linux-gnu/purple-2]
If I run: LD_DEBUG=libs pidgin -n
That is indeed what happens:
43864: find library=libjabber.so.0 [0]; searching
43864: search
path=/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/purple-2/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls/haswell:/usr/lib/x86_64-linux-gnu/purple-2/tls/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/tls:/usr/lib/x86_64-linux-gnu/purple-2/haswell/x86_64:/usr/lib/x86_64-linux-gnu/purple-2/haswell:/usr/lib/x86_64-linux-gnu/purple-2/x86_64:/usr/lib/x86_64-linux-gnu/purple-2
(RUNPATH from file
/usr/lib/x86_64-linux-gnu/purple-2/libxmpp.so)
If I run: LD_DEBUG=libs chatty
It fails:
43926: find library=libjabber.so.0 [0]; searching
43926: search path=/usr/lib/purple-2 (RUNPATH from file
chatty)
43926: trying file=/usr/lib/purple-2/libjabber.so.0
43926: search cache=/etc/ld.so.cache
43926: search
path=/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/lib/x86_64-linux-gnu/tls/haswell/x86_64:/lib/x86_64-linux-gnu/tls/haswell:/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/haswell/x86_64:/lib/x86_64-linux-gnu/haswell:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v3:/usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2:/usr/lib/x86_64-linux-gnu/tls/haswell/x86_64:/usr/lib/x86_64-linux-gnu/tls/haswell:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/haswell/x86_64:/usr/lib/x86_64-linux-gnu/haswell:/usr/lib/x86_64-linux-gnu/x86_64:/usr/lib/x86_64-linux-gnu:/lib/glibc-hwcaps/x86-64-v3:/lib/glibc-hwcaps/x86-64-v2:/lib/tls/haswell/x86_64:/lib/tls/haswell:/lib/tls/x86_64:/lib/tls:/lib/haswell/x86_64:/lib/haswell:/lib/x86_64:/lib:/usr/lib/glibc-hwcaps/x86-64-v3:/usr/lib/glibc-hwcaps/x86-64-v2:/usr/lib/tls/haswell/x86_64:/usr/lib/tls/haswell:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/haswell/x86_64:/usr/lib/haswell:/usr/lib/x86_64:/usr/lib
(system search path)
At first glance, it felt like the RUNPATH from chatty was winning over
that from libxmpp.so.
-- END RED HERRING --
Upon further investigation, the real issue is that chatty is directly
linking to libjabber.so, and they're setting a RUNPATH to do it.
chatty's src/meson.build has:
executable('chatty', chatty_sources, resources,
include_directories: src_inc,
dependencies: chatty_deps,
link_with: libchatty.get_static_lib(),
install: true,
install_rpath: purple_plugdir,
)
Note the install_rpath.
and src/purple/meson.build has (manual wrapping added for email):
purple_plugdir = purple_dep.get_pkgconfig_variable('plugindir')
jabber = meson.get_compiler('c').find_library(
'jabber', dirs: purple_plugdir)
In terms of "Who is at fault?", I blame chatty for explicitly linking to
an internal library. However, in fairness, I understand that they have
their reasons and a better solution was never found with upstream (at
least in part because no significant changes are going to go into purple
2 at this point):
https://source.puri.sm/Librem5/chatty/-/issues/266
The good news here is that a rebuild of chatty is all that's necessary.
A binNMU should be sufficient to fix the bug. I've submitted a request
for one, but this was my first time, so I might have done something wrong.
To fix it fully correctly, though, I think we want a versioned
Build-Depends to ensure it cannot be built against an old libpurple0
(not that such a thing should happen). And a lintian override needs
updating. Here is a MR for that:
https://salsa.debian.org/DebianOnMobile-
Bug#1006350: pidgin: crashes when typing past visible number of lines
This has hopefully been fully fixed now (upstream). It will land in the 2.14.9 release, which should be coming next week. However, I've uploaded a backport of it now. -- Richard
Bug#1001610: Gbonds
On 1/31/22 19:37, Trey Glover wrote: I had no idea that the treasury was doing this. Is there a code fix in place yet? In unstable, yes; it's fixed in 2.0.3-17. I wrote code to use the Treasury API to generate old-style sbMM.asc files which are stored (as always) in ~/.gbonds/ In stable, no; see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002563 -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#1001610: GBonds Unable to Update Redemption Tables
Package: gbonds Version: 2.0.3-8 Severity: grave The U.S. Treasury has discontinued publishing the sbMM.asc files on its FTP site. Unfortunately, this means that GBonds is unable to update its redemption tables. Given that a, if not the, major reason to use GBonds is to track the current redemption value of one's U.S. Savings Bonds, this renders the application mostly broken as of December 1, 2021. The good news is that Savings Bond value data is available at the FiscalData site as a JSON-based RESTful API. I have ported GBonds to use this API and will be making an upload shortly. -- Richard
Bug#980464: [Pkg-zfsonlinux-devel] Bug#980464: zfs-dracut: dracut+ZFS-on-root systems rendered unbootable
FWIW, I gave the patch a review and it seems sane to me. I also looked at the package in unstable and confirmed that zgenhostid is being installed to /sbin, not /bin. -- Richard
Bug#957616: ntpsec: ftbfs with GCC-10
On 7/25/20 5:27 PM, Reiner Herrmann wrote: > this has been fixed in version 1.1.9. > The relevant commit is this one: > > https://gitlab.com/NTPsec/ntpsec/-/commit/ccdd9d4b941b30fc44b301595e42809dbe48628d Thanks for that information! That saves me investigating. I need to get 1.1.9 packaged anyway, so I'll proceed straight to that. -- Richard signature.asc Description: OpenPGP digital signature
Bug#962424: [Pkg-zfsonlinux-devel] Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint
On 6/9/20 7:02 PM, Wxcafé wrote: > I don't use zfs-import-cache since it's a single pool that contains the > root so it's in the kernel cmdline and imported at that point. I wasn't asking about the pool cache, but the filesystem cache file used by zfs-mount-generator. That would show all the datasets involved and their properties and would allow testing the generator to see what units it is producing for you. -- Richard signature.asc Description: OpenPGP digital signature
Bug#962424: [Pkg-zfsonlinux-devel] Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint
On 6/7/20 3:12 PM, wxcafe wrote: > The systemd zfs-mount-generator script > (/lib/systemd/system-generators/zfs-mount-generator) can break system > boot if there are multiple datasets with the same mountpoint, because it > ignores the zfs property canmount=noauto. It certainly does not "ignore" canmount=noauto. There's all kinds of logic in the generator to deal with canmount=noauto. > I store backups on my system and after upgrading the system wouldn't > boot anymore because while my backups are canmount=noauto, the generator > was trying to mount multiple datasets to the same mountpoints (/, /usr/, > ...) which obviously breaks... everything. If you have datasets marked as canmount=on, they should take precedence over any marked canmount=noauto for the same mountpoint. Are there multiple pools involved here, or just one? Can you provide a copy of your cache file(s) from /etc/zfs/zfs-list.cache? -- Richard signature.asc Description: OpenPGP digital signature
Bug#939739: openipmi: fails to detect udev
tags 939739 patch Attached is a patch to fix this. Also attached is a debdiff for an NMU that fixes this and some other small issues. -- Richard diff -Nru openipmi-2.0.25/debian/openipmi.init openipmi-2.0.25/debian/openipmi.init --- openipmi-2.0.25/debian/openipmi.init 2018-05-19 04:04:51.0 -0500 +++ openipmi-2.0.25/debian/openipmi.init 2020-03-07 00:50:04.0 -0600 @@ -77,7 +77,7 @@ DEV_IPMI_TIMEOUT=15 UDEV_EXISTS=0 -if [ -e /sbin/udev -o -e /sbin/udevd ]; then +if [ -e /lib/systemd/systemd-udevd ]; then UDEV_EXISTS=1 fi diff -Nru openipmi-2.0.25/debian/changelog openipmi-2.0.25/debian/changelog --- openipmi-2.0.25/debian/changelog2019-03-27 16:57:19.0 -0500 +++ openipmi-2.0.25/debian/changelog2020-03-07 01:19:35.0 -0600 @@ -1,3 +1,13 @@ +openipmi (2.0.25-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Fix udev detection (Closes: 939739) + * Update Standards-Version to 4.5.0 +- Set Rules-Requires-Root: no + * Add LGPL-2+ license grant to debian/copyright + + -- Richard Laager Sat, 07 Mar 2020 01:19:35 -0600 + openipmi (2.0.25-2.1) unstable; urgency=medium * Non-maintainer upload, with pre-approval from current maintainer. diff -Nru openipmi-2.0.25/debian/control openipmi-2.0.25/debian/control --- openipmi-2.0.25/debian/control 2018-05-18 17:15:41.0 -0500 +++ openipmi-2.0.25/debian/control 2020-03-07 01:16:36.0 -0600 @@ -3,7 +3,8 @@ Priority: optional Maintainer: Noël Köthe Build-Depends: debhelper (>> 11.0.0), libsnmp-dev, libpopt-dev, libncurses5-dev, chrpath, libssl-dev -Standards-Version: 4.1.4 +Standards-Version: 4.5.0 +Rules-Requires-Root: no Homepage: http://openipmi.sourceforge.net/ Package: openipmi diff -Nru openipmi-2.0.25/debian/copyright openipmi-2.0.25/debian/copyright --- openipmi-2.0.25/debian/copyright2018-05-19 04:04:51.0 -0500 +++ openipmi-2.0.25/debian/copyright2020-03-07 01:19:35.0 -0600 @@ -6,6 +6,11 @@ Files: * Copyright: 2004- MontaVista Software Inc., Corey Minyard License: LGPL + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public License + as published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + . On Debian systems, the full text of the LGPL License can be found in the file `/usr/share/common-licenses/LGPL'. diff -Nru openipmi-2.0.25/debian/openipmi.init openipmi-2.0.25/debian/openipmi.init --- openipmi-2.0.25/debian/openipmi.init2018-05-19 04:04:51.0 -0500 +++ openipmi-2.0.25/debian/openipmi.init2020-03-07 00:50:04.0 -0600 @@ -77,7 +77,7 @@ DEV_IPMI_TIMEOUT=15 UDEV_EXISTS=0 -if [ -e /sbin/udev -o -e /sbin/udevd ]; then +if [ -e /lib/systemd/systemd-udevd ]; then UDEV_EXISTS=1 fi signature.asc Description: OpenPGP digital signature
Bug#919412: rng-tools: Build-Depends on cruft package libgcrypt11-dev
On 3/7/20 12:19 AM, Richard Laager wrote:
> Also attached is a debdiff for an NMU that fixes this and some other
> small issues.
Updated NMU debdiff attached. This one sets Rules-Requires-Root: no.
--
Richard
diff -Nru rng-tools-5/debian/changelog rng-tools-5/debian/changelog
--- rng-tools-5/debian/changelog2018-12-02 04:00:52.0 -0600
+++ rng-tools-5/debian/changelog2020-03-07 01:36:36.0 -0600
@@ -1,3 +1,15 @@
+rng-tools (5-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix libgcrypt Build-Depends (Closes: 919412)
+ * Update Standards-Version to 4.5.0 (no changes)
+- Set Rules-Requires-Root: no
+ * Rename debian/NEWS.Debian to debian/NEWS so it is installed.
+ * Fix indentation in debian/NEWS (and rewrap as required).
+ * Fix spelling errors in debian/NEWS
+
+ -- Richard Laager Sat, 07 Mar 2020 01:36:36 -0600
+
rng-tools (5-1) unstable; urgency=medium
[ David Härdeman ]
diff -Nru rng-tools-5/debian/control rng-tools-5/debian/control
--- rng-tools-5/debian/control 2018-12-02 04:00:52.0 -0600
+++ rng-tools-5/debian/control 2020-03-07 01:35:56.0 -0600
@@ -2,8 +2,9 @@
Section: utils
Priority: optional
Maintainer: Henrique de Moraes Holschuh
-Build-Depends: debhelper (>= 10), libtspi-dev, libgcrypt11-dev
-Standards-Version: 4.2.1
+Build-Depends: debhelper (>= 10), libtspi-dev, libgcrypt20-dev
+Standards-Version: 4.5.0
+Rules-Requires-Root: no
Package: rng-tools
Architecture: any
diff -Nru rng-tools-5/debian/NEWS rng-tools-5/debian/NEWS
--- rng-tools-5/debian/NEWS 1969-12-31 18:00:00.0 -0600
+++ rng-tools-5/debian/NEWS 2020-03-07 00:07:43.0 -0600
@@ -0,0 +1,17 @@
+rng-tools (2-unofficial-mt.9-1) experimental; urgency=low
+
+ rng-tools now features an user-space driver to interface to the VIA PadLock
+ security engine's RNG. In order to better support such extensions, rngd is
+ being revised to work with better modularized entropy sources ("input
+ drivers") and entropy sinks ("output drivers").
+
+ To accommodate for these changes, the public interfaces have been changed
+ slightly. The "intel" TRNG profile has been renamed to "intelfwh" (in
+ hindsight, it should have been named like that since day one). The "via"
+ TRNG profile has been renamed "viakernel", and a new TRNG profile,
+ "viapadlock", was added.
+
+ It is probable that the command line interface will be throughoutly modified
+ soon, to better accommodate the modular drivers.
+
+ -- Henrique de Moraes Holschuh Fri, 5 Nov 2004 08:57:35
-0200
diff -Nru rng-tools-5/debian/NEWS.Debian rng-tools-5/debian/NEWS.Debian
--- rng-tools-5/debian/NEWS.Debian 2014-03-18 14:56:45.0 -0500
+++ rng-tools-5/debian/NEWS.Debian 1969-12-31 18:00:00.0 -0600
@@ -1,17 +0,0 @@
-rng-tools (2-unofficial-mt.9-1) experimental; urgency=low
-
-rng-tools now features an user-space driver to interface to the VIA PadLock
-security engine's RNG. In order to better support such extensions, rngd is
-being revised to work with better modularized entropy sources ("input drivers")
-and entropy sinks ("output drivers").
-
-To accomodate for these changes, the public interfaces have been changed
-slightly. The "intel" TRNG profile has been renamed to "intelfwh" (in
-hindsight, it should have been named like that since day one). The "via"
-TRNG profile has been renamed "viakernel", and a new TRNG profile,
-"viapadlock", was added.
-
-It is probable that the command line interface will be throughoutly modified
-soon, to better accomodate the modular drivers.
-
- -- Henrique de Moraes Holschuh Fri, 5 Nov 2004 08:57:35
-0200
signature.asc
Description: OpenPGP digital signature
Bug#953231: python-humanize: autopkgtest regression: No module named 'pkg_resources'
Attached is a patch to fix this.
I also submitted it as a merge request:
https://salsa.debian.org/python-team/modules/python-humanize/-/merge_requests/2
--
Richard
From 1b7c39261508f7652c8e767a591786a7c2349f20 Mon Sep 17 00:00:00 2001
From: Richard Laager
Date: Sat, 7 Mar 2020 00:35:56 -0600
Subject: [PATCH] Depend on python3-pkg-resources
Closes: 953231
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index bf6bf61..c39a6df 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Testsuite: autopkgtest-pkg-python
Package: python3-humanize
Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}
+Depends: python3-pkg-resources, ${misc:Depends}, ${python3:Depends}
Description: Python Humanize library (Python 3)
This library proposes various common humanization utilities, like turning
a number into a fuzzy human readable duration ('3 minutes ago') or into a
--
2.25.0
signature.asc
Description: OpenPGP digital signature
Bug#919412: rng-tools: Build-Depends on cruft package libgcrypt11-dev
tags 919412 patch
Attached is a patch to fix this.
Also attached is a debdiff for an NMU that fixes this and some other
small issues.
--
Richard
diff -Nru rng-tools-5/debian/control rng-tools-5/debian/control
--- rng-tools-5/debian/control 2018-12-02 04:00:52.0 -0600
+++ rng-tools-5/debian/control 2020-03-06 23:48:20.0 -0600
@@ -2,7 +2,7 @@
Section: utils
Priority: optional
Maintainer: Henrique de Moraes Holschuh
-Build-Depends: debhelper (>= 10), libtspi-dev, libgcrypt11-dev
+Build-Depends: debhelper (>= 10), libtspi-dev, libgcrypt20-dev
Standards-Version: 4.2.1
Package: rng-tools
diff -Nru rng-tools-5/debian/changelog rng-tools-5/debian/changelog
--- rng-tools-5/debian/changelog2018-12-02 04:00:52.0 -0600
+++ rng-tools-5/debian/changelog2020-03-07 00:16:37.0 -0600
@@ -1,3 +1,14 @@
+rng-tools (5-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix libgcrypt Build-Depends (Closes: 919412)
+ * Update Standards-Version to 4.5.0 (no changes)
+ * Rename debian/NEWS.Debian to debian/NEWS so it is installed.
+ * Fix indentation in debian/NEWS (and rewrap as required).
+ * Fix spelling errors in debian/NEWS
+
+ -- Richard Laager Sat, 07 Mar 2020 00:16:37 -0600
+
rng-tools (5-1) unstable; urgency=medium
[ David Härdeman ]
diff -Nru rng-tools-5/debian/control rng-tools-5/debian/control
--- rng-tools-5/debian/control 2018-12-02 04:00:52.0 -0600
+++ rng-tools-5/debian/control 2020-03-07 00:16:37.0 -0600
@@ -2,8 +2,8 @@
Section: utils
Priority: optional
Maintainer: Henrique de Moraes Holschuh
-Build-Depends: debhelper (>= 10), libtspi-dev, libgcrypt11-dev
-Standards-Version: 4.2.1
+Build-Depends: debhelper (>= 10), libtspi-dev, libgcrypt20-dev
+Standards-Version: 4.5.0
Package: rng-tools
Architecture: any
diff -Nru rng-tools-5/debian/NEWS rng-tools-5/debian/NEWS
--- rng-tools-5/debian/NEWS 1969-12-31 18:00:00.0 -0600
+++ rng-tools-5/debian/NEWS 2020-03-07 00:07:43.0 -0600
@@ -0,0 +1,17 @@
+rng-tools (2-unofficial-mt.9-1) experimental; urgency=low
+
+ rng-tools now features an user-space driver to interface to the VIA PadLock
+ security engine's RNG. In order to better support such extensions, rngd is
+ being revised to work with better modularized entropy sources ("input
+ drivers") and entropy sinks ("output drivers").
+
+ To accommodate for these changes, the public interfaces have been changed
+ slightly. The "intel" TRNG profile has been renamed to "intelfwh" (in
+ hindsight, it should have been named like that since day one). The "via"
+ TRNG profile has been renamed "viakernel", and a new TRNG profile,
+ "viapadlock", was added.
+
+ It is probable that the command line interface will be throughoutly modified
+ soon, to better accommodate the modular drivers.
+
+ -- Henrique de Moraes Holschuh Fri, 5 Nov 2004 08:57:35
-0200
diff -Nru rng-tools-5/debian/NEWS.Debian rng-tools-5/debian/NEWS.Debian
--- rng-tools-5/debian/NEWS.Debian 2014-03-18 14:56:45.0 -0500
+++ rng-tools-5/debian/NEWS.Debian 1969-12-31 18:00:00.0 -0600
@@ -1,17 +0,0 @@
-rng-tools (2-unofficial-mt.9-1) experimental; urgency=low
-
-rng-tools now features an user-space driver to interface to the VIA PadLock
-security engine's RNG. In order to better support such extensions, rngd is
-being revised to work with better modularized entropy sources ("input drivers")
-and entropy sinks ("output drivers").
-
-To accomodate for these changes, the public interfaces have been changed
-slightly. The "intel" TRNG profile has been renamed to "intelfwh" (in
-hindsight, it should have been named like that since day one). The "via"
-TRNG profile has been renamed "viakernel", and a new TRNG profile,
-"viapadlock", was added.
-
-It is probable that the command line interface will be throughoutly modified
-soon, to better accomodate the modular drivers.
-
- -- Henrique de Moraes Holschuh Fri, 5 Nov 2004 08:57:35
-0200
signature.asc
Description: OpenPGP digital signature
Bug#919513: CVE-2019-6442 CVE-2019-6443 CVE-2019-6444 CVE-2019-6445
I've prepared an upload of NTPsec 1.1.3 which includes these fixes. I have sent this to my sponsor for uploading. -- Richard
Bug#919513: CVE-2019-6442 CVE-2019-6443 CVE-2019-6444 CVE-2019-6445
Thanks for letting me know. I was planning to package 1.1.3 in the next couple of days, but I was not aware there were CVEs fixed in this release. I will try to do a package release today. -- Richard > On Jan 16, 2019, at 13:21, Moritz Muehlenhoff wrote: > > Source: ntpsec > Severity: grave > Tags: security > > Please see > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6442 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6443 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6444 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6445 > > Cheers, >Moritz
Bug#915831: [Pkg-zfsonlinux-devel] Bug#915831: Fwd: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure
On 12/31/18 6:34 PM, Rich wrote:
> It seems like what we might want is an OR dependency on two child
> zfs-{systemd,sysvinit} packages - and for those two packages to
> conflict with each other (and require the appropriate respective init
> packages)?
I don't think that's desirable. If this is actually required, then
wouldn't every package trying to support systemd and sysvinit need to do
that same? That would be a lot of work. No other packages are doing
this; there should be some other solution.
If systemd-sysv and insserv are not co-installable, that conflict should
be expressed in those packages.
--
Richard
Bug#885638: GBonds Modernization
I have a new version of the gbonds package prepared and sent to my sponsor for upload. The vast majority of the credit for this upload goes to Yavor Doganov who submitted a series of patches to modernize the gbonds code, porting it to GTK+ 3, GIO, and GSettings and restoring printing support! This resolves the serious bugs which would have otherwise required the removal of gbonds prior to the Buster release. I am extremely grateful for this generous contribution of coding time and skill! Yavor Doganov: I made the following changes to your patches in the process of accepting them: Port to GTK+ 3 and GIO: - Dropped spurious diff header changes to other files - Folded in the remainder of debian/patches/libgnomeprint ^ These changes were cosmetic in nature. Port to GSettings: - Install the schema and setting files into gbonds-data ^ These files were required. I simply added them to debian/gbonds-data.install so they ended up in the package. I tested this with my usual real-world data file and usage. I also tested downloading new redemption data from the Treasury. I tested the printing functionality to the point of a Preview. It looks great to me! -- Richard
Bug#885638: gbonds: Please drop Build-Depends on rarian-compat
On 11/23/18 7:38 AM, Jeremy Bicha wrote: > gbonds is now 1 of the last 2 packages keeping rarian in Debian > Unstable. Do you think you'll be able to review these patches soon? Yes. I've been busy with a new baby at home, but I intend to get to these very soon. -- Richard
Bug#905678: ntpsec-ntpdate: /sbin/dhclient-script: 30: /etc/dhcp/dhclient-exit-hooks.d/ntpsec-ntpdate: Syntax error: word unexpected (expecting "do")
On 08/07/2018 06:17 PM, Axel Beckert wrote: > /sbin/dhclient-script: 30: /etc/dhcp/dhclient-exit-hooks.d/ntpsec-ntpdate: > Syntax error: word unexpected (expecting "do") That unfortunately slipped through my testing. I found that this morning myself, actually. I've sent my sponsor an upload to fix this. -- Richard
Bug#893542: ntpsec-ntpviz: shares /var/log/ntpstats with ntp, which gets zapped when ntp is purged
On 03/30/2018 05:31 PM, Richard Laager wrote: > If this coordination is acceptable, I believe it solves the various > interactions. I'm happy to test more scenarios if anyone thinks I missed > something. > > If this coordination is not acceptable, I'm open to alternative suggestions. My current plan is to rename (on the ntpsec side) everything that conflicts. I have a start on this, and it won't be too bad. There will be a different set of trade-offs. -- Richard
Bug#893542: ntpsec Status Update
I got back to ntpsec packaging work today. #901439 has another ntp/ntpsec conflict. Fixing that is somewhat tied up in the questions about coordination as discussed in #893542. I still need to package up the upstream 1.1.1 release too. I will hopefully have an upload ready in a few days. -- Richard
Bug#893542: ntpsec-ntpviz: shares /var/log/ntpstats with ntp, which gets zapped when ntp is purged
On 06/18/2018 01:46 PM, Paride Legovini wrote: > Just a friendly ping on this, as I'd like to see ntpsec migrate to > testing. What are your plans for this patch? I've been in some communication with an ntp maintainer, but no updates as of recently. At this point, my intention is to package the new 1.1.1 release with this and a few other fixes and then close this as fixed from my side. I had hoped to do that yesterday, but I didn't get to it. I hope to complete this in the next couple of days. -- Richard
Bug#893542: ntpsec-ntpviz: shares /var/log/ntpstats with ntp, which gets zapped when ntp is purged
I did some testing just now.
I've updated ntpsec.postrm in git. I dropped the unnecessary LANG=C on
the first check, updated the style of the "then" statement, and most
importantly, moved the deluser inside the "! dpkg -s ntp" block:
if ! dpkg -s ntp > /dev/null 2>&1; then
rm -rf /var/lib/ntp/
rm -rf /var/log/ntpstats/
if ! LANG=C dpkg -s ntpsec-ntpviz 2> /dev/null | \
grep -qE "^Status: (hold|install)"; then
deluser --system --quiet ntp || true
fi
fi
Here is the equivalent diff for ntp, which I have tested and confirmed:
diff --git a/debian/ntp.postrm b/debian/ntp.postrm
index d959aa5..7ec4b6b 100644
--- a/debian/ntp.postrm
+++ b/debian/ntp.postrm
@@ -25,7 +25,12 @@ installinit_error() {
#DEBHELPER#
if [ "$1" = "purge" ]; then
- deluser --system --quiet ntp || true
- rm -rf /var/lib/ntp/
- rm -rf /var/log/ntpstats/
+ if ! dpkg -s ntpsec > /dev/null 2>&1; then
+ rm -rf /var/lib/ntp/
+ rm -rf /var/log/ntpstats/
+ if ! LANG=C dpkg -s ntpsec-ntpviz 2> /dev/null | \
+grep -qE "^Status: (hold|install)"; then
+ deluser --system --quiet ntp || true
+ fi
+ fi
fi
If this coordination is acceptable, I believe it solves the various
interactions. I'm happy to test more scenarios if anyone thinks I missed
something.
If this coordination is not acceptable, I'm open to alternative suggestions.
--
Richard
Bug#893542: ntpsec-ntpviz: shares /var/log/ntpstats with ntp, which gets zapped when ntp is purged
On 03/19/2018 02:42 PM, Julian Gilbey wrote: > Package: ntpsec-ntpviz > Version: 1.0.0+dfsg1-5 > Severity: serious > > I installed the ntpsec suite, then purged the ntp packages. > Unfortunately, this zapped the /var/log/ntpstats directory, which is > needed by ntpsec-ntpviz. There needs to either been some agreement > between ntp and ntpsec about the use of this directory, or ntpsec > needs to use a different log directory. We have the same situation in reverse too, it seems. Keeping the same log directory between ntp and ntpsec is desirable, for several reasons: - The log format is the same. - Logs are not lost on conversions from ntp to ntpsec or ntpsec to ntp. - ntpsec-ntpviz is co-installable with ntp and works. This might be desirable, if someone wants to continue using ntp but use ntpviz to create useful graphs. - IIRC, the default /etc/ntp.conf from ntp references this path, so keeping the logging path the same means we don't need to change /etc/ntp.conf on conversions from ntp<->ntpsec. Likewise for /var/lib/ntp, where the drift file is stored. There again, it is very desirable to keep the same drift file upon conversions from ntp<->ntpsec. Otherwise, accuracy is lost until the new ntpd has a chance to recalculate the drift value. Related, there's the issue of the ntp user (and ntp group). Those should not be removed until /var/log/ntpstats is gone. The ntpsec-ntpviz package also needs the ntp user and group, so coordination is required there too. An alternative would be to _copy_ the log files and drift file on initial installation of ntpsec. This has some downsides: - Only ntp -> ntpsec conversions benefit. If someone goes the other way, or goes to ntpsec and then back, logs are still lost, unless ntp also adopts a copying approach (but then why copy instead of share?). - ntpsec needs to sed /etc/ntp.conf to change the paths. This breaks logging if someone moves back to ntp, unless ntp also seds the config file (again then why not just share?). - This breaks anything else that someone might be doing with the log files (and drift file, but that seems unlikely). - We still need to coordinate on the ntp user (and group), unless ntpsec uses a different user (and group) too. If so, then I'm deviating from upstream naming (and years of user history with ntp). Another alternative would be for both packages to simply _not_ delete any of these things. I have wrapped the `rm -rf` with a check for ntp. Here is what I have in ntpsec.postrm now: if ! LANG=C dpkg -s ntp > /dev/null 2>&1 then rm -rf /var/lib/ntp/ rm -rf /var/log/ntpstats/ fi if ! LANG=C dpkg -s ntpsec-ntpviz 2> /dev/null | \ grep -qE "^Status: (hold|install)"; then deluser --system --quiet ntp || true fi I suggest the same for ntp.postrm, but with "ntp" changed to "ntpsec": if ! LANG=C dpkg -s ntpsec > /dev/null 2>&1 then rm -rf /var/lib/ntp/ rm -rf /var/log/ntpstats/ fi if ! LANG=C dpkg -s ntpsec-ntpviz 2> /dev/null | \ grep -qE "^Status: (hold|install)"; then deluser --system --quiet ntp || true fi Is this acceptable on the ntp side? If not, can you propose a different solution? -- Richard
Bug#891278: ntpsec-ntpviz: fails to install: install: invalid user 'ntp'
Since ntpsec-ntpviz does not Depend, much less Pre-Depend, on ntpsec, the adduser from ntpsec.postinst needs to be duplicated into ntpsec-ntpviz.postinst. I’ll take care of this in a couple days. -- Richard
Bug#890758: ntpsec: Incomplete debian/copyright?
On 02/18/2018 08:55 AM, Chris Lamb wrote: > I just ACCEPTed ntpsec from NEW but noticed it was missing > attribution in debian/copyright for at least Motorolo, autorevision.sh, > Chris Johns, etc. Motorola is not missing. The "COPYRIGHT 1991-1994 MOTOROLA INC." and similar in ntpd/refclock_oncore.c are part of a copy of text from a label on hardware, to illustrate the models of hardware the driver was tested with. I have now added this as a comment in debian/copyright. I have specifically addressed autorevision.sh and Chris Johns. I also made another pass over everything, and found a few more missing. -- Richard
Bug#884991: roundcube: Does not write changes in message state back to server.
I haven’t verified the reporter’s bug. If message caching is broken, that is a reason to disable that feature in the package, not to remove the package entirely. I am running Roundcube (not from this package yet, but I intend to switch to it) in a production ISP environment. Roundcube works great. It also ships as part of cPanel, which is used by a huge number of web hosts. We don’t use message caching, and I don’t think it is enabled by default in cPanel either. I use imapproxy on the Roundcube host for efficiency. I recently picked up maintainership of the imapproxy package in Debian. -- Richard
Bug#868150: imapproxy: fails to start
On 07/18/2017 01:28 PM, Richard Laager wrote: > Agreed on stable-proposed-updates. I plan to prepare an upload in the next > few days. I have prepared the changes and submitted the required bug for stable-proposed-updates here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871451 I assume I need to hear some sort of ACK on that bug before I (ask my sponsor to) upload. -- Richard
Bug#868150: imapproxy: fails to start
Agreed on stable-proposed-updates. I plan to prepare an upload in the next few days. -- Richard
Bug#868150: imapproxy: fails to start
With PIDFile=/run/imapproxy.pid, I get the following errors: PID file /run/imapproxy.pid not readable (yet?) after start: No such file or directory Supervising process 824 which is not our child. We'll most likely not notice when it exits. >From my first testing, it worked fine without PIDFile. Unfortunately, upon further testing, it seems to fail most of the time. Given that those errors seem harmless, I think setting PIDFile is the lesser of the two evils right now, so I'm sticking with that. I've sent the update to my sponsor. (I'm not a DD.) I should probably explore the idea of adding a command-line option to imapproxy that sets foreground_mode. Then, I can use that in the systemd unit, making this Type=simple instead of Type=forking. -- Richard
Bug#868150: imapproxy: fails to start
Is the PIDFile line actually necessary for you? Can you re-test without the PIDFile line in the service? With that line, I get additional errors/warnings. Without it, systemd is still able to detect the main PID of the process. On 07/13/2017 02:52 AM, Marc Dequènes (duck) wrote: > So better would be to change the path where the pidfile is created, but > you can do this when you have time. Sure, that's trivial. I have that change ready. > Search the word "Thanks" in /usr/share/doc/dpkg/changelog.Debian.gz for > plenty of examples. gbp-dch supports a Thanks meta tag, which has this result, so that seems like the correct answer. > Also please use "Marc Dequènes (Duck)". Noted and done. -- Richard
Bug#868150: imapproxy: fails to start
On 07/12/2017 08:00 AM, Marc Dequènes (duck) wrote: > --- imapproxy.service.orig 2017-07-12 14:57:35.0 +0200 > +++ /lib/systemd/system/imapproxy.service 2017-07-12 > 14:50:15.0 +0200 > @@ -8,3 +8,8 @@ > Type=forking > ExecStartPre=/usr/share/imapproxy/prepare-chroot > ExecStart=/usr/sbin/imapproxyd -f /etc/imapproxy.conf > +PIDFile=/run/imapproxy.pid > + > +[Install] > +WantedBy=multi-user.target > + imapproxyd actually writes the PID file to /var/run/imapproxy.pid (by default). With /var/run being a symlink to /run, these should be equivalent. It seems slightly more correct to me to use: PIDFile=/var/run/imapproxy.pid Does it still work for you with /var/run instead of /run? I'm not sure on the normal etiquette for crediting in debian/changelog. I'd like to credit you for the patch. The obvious way to do so is to mark you as the git author, but then I'm writing a commit message that has your name attached, which feels weird. So I can either do that, so this happens in debian/changelog: [ Marc Dequènes ] * Correct the service file (Closes: 868150) Or I can let the git author default to me and just credit you textually in the commit message. Do you have a preference? Are you okay with "Correct the service file" or would you like to provide your own commit message for that patch? -- Richard
Bug#828586: Building with OpenSSL 1.0.2 is sufficient for stretch
On 12/11/2016 09:43 AM, Jose Luis Tallon wrote: > On 12/11/2016 12:58 AM, Adrian Bunk wrote: >> Not a perfect solution but sufficient for stretch is the patch below to >> use OpenSSL 1.0.2 > > Thank you for the patch! > > Richard Laager has been preparing a new version, including all pending > patches. CC'ing him so that we keep synchronized. > Tony Mancill has agreed to sponsor that upload. That upload includes a patch I wrote to build imapproxy against OpenSSL 1.1 (while still supporting older OpenSSL). We should be good as soon as that is uploaded (hopefully today or tomorrow, we have one last thing to fix). -- Richard
Bug#713637: gbonds_2.0.3-2.2_i386.changes ACCEPTED into unstable
Thanks for fixing this! Linking with libm was the correct and easy fix to the immediate problem. I started on a more comprehensive fix (replacing EggRecent with GtkRecent), but I fear that's going to be more work than I had hoped. The upstream gbonds developer hasn't released any new versions in years, so I fear at some point I'm going to have to take over and do a major rewrite for GTK+ 3. In the short term, I believe I'm supposed to prepare a new version that ACKs your NMU? -- Richard signature.asc Description: This is a digitally signed message part
Bug#530780: jpegtran is NOT lossless with Exif data by default
On Wed, 2009-05-27 at 21:30 +0200, Bill Allombert wrote: > On Wed, May 27, 2009 at 02:10:00PM -0500, Richard Laager wrote: > > Hello Richard, > > > From the man page: > > NAME > >jpegtran - lossless transformation of JPEG files > > ... > >... But by the same token, jpegtran cannot perform lossy > > operations > >such as changing the image quality. > > Only when applied to JPEG files, not EXIF files with are not valid JPEG > files according to the JFIF standard. (It is not possible for a file to > be both EXIF and JFIF compliant). If you want to manipulate EXIF files, > use exif software. Issues with jpegtran aside, is using jpegexiforient to set the EXIF orientation flag the right solution, assuming my viewers all support EXIF? (That doesn't help with programs that don't read EXIF tags, of course.) Richard signature.asc Description: This is a digitally signed message part
Bug#530780: jpegtran is NOT lossless with Exif data by default
On Wed, 2009-05-27 at 21:30 +0200, Bill Allombert wrote: > On Wed, May 27, 2009 at 02:10:00PM -0500, Richard Laager wrote: > > Hello Richard, > > > From the man page: > > NAME > >jpegtran - lossless transformation of JPEG files > > ... > >... But by the same token, jpegtran cannot perform lossy > > operations > >such as changing the image quality. > > Only when applied to JPEG files, not EXIF files with are not valid JPEG > files according to the JFIF standard. (It is not possible for a file to > be both EXIF and JFIF compliant). If you want to manipulate EXIF files, > use exif software. Aside from people that work on these file formats directly, everyone lumps these together as "JPEG files" in their head and when talking about them. More to the point, jpegtran works with my "EXIF files". It properly rotates them 90 degrees as desired. If I specify "-copy all", it even properly copies my EXIF metadata. The man page refers to "EXIF" in the documentation of "-copy all". How is a user to know that this isn't "exif software" and that they should use something else? This caused me data loss (even though it was just EXIF metadata). I know there are people that care about their EXIF metadata a lot more than me, though. Are you opposed to all of my options (even #5, adding a note to the top of the man page)? I'm not necessarily asking you to do the coding either. If you want to, that's great, but I can see about generating a patch if there's a solution you like. If you'd rather, I can take this question upstream. I just prefer discussing thing in the Debian context first. Richard signature.asc Description: This is a digitally signed message part
Bug#530780: jpegtran is NOT lossless with Exif data by default
Package: libjpeg-progs Version: 6b-14 Severity: grave From the man page: NAME jpegtran - lossless transformation of JPEG files ... ... But by the same token, jpegtran cannot perform lossy operations such as changing the image quality. ... -copy comments Copy only comment markers. This setting copies comments from the source file, but discards any other inessential data. -copy all Copy all extra markers. This setting preserves miscellaneous markers found in the source file, such as Exif data, JFIF thumb‐ nails and Photoshop settings. In some files these extra markers can be sizable. The default behavior is -copy comments. As you can see, jpegtran explicitly claims to be lossless. It even further claims it "cannot perform lossy operations". (I realize now that's only talking about image data.) But, the default for extra marker copying is "-copy comment", which drops Exif data. This means that every picture I've rotated with jpegtran has lost its Exif data. Luckily, I probably don't need it that bad, but I was using this tool explicitly because it's supposedly lossless. I realize that the man page is clear about the default value of -copy, but who reads an entire man page to find the one option that makes the description under NAME untrue? I propose these possible solutions, in order of preference: 1. Add a new argument to copy that behaves like -copy all, but *updates* the JFIF thumbnail after transforming the image. Make this option the default. 2. Add a new argument to copy that behaves like -copy all, but *drops* (does not copy) the JFIF thumbnails. Make this option the default. 3. Make -copy all the default. 4. Add a new argument to copy that behaves like -copy comments, but also copies exif markers. Make this option the default. The first patch here might be useful, though I'm not sure if it also copies comments: https://bugzilla.redhat.com/show_bug.cgi?id=106060 5. Add an asterisk after lossless at the top of the man page and then add a note under it such as, '* The only extra markers copied by default are comments. This means certain data (Exif data, JFIF thumbnails, Photoshop settings, etc.) will be lost. To copy all extra markers, see the "-copy all" argument.' Severity "grave" based on the fact that this causes data loss. Richard signature.asc Description: This is a digitally signed message part
Bug#369063: aborts when sending a message
On Sat, 2006-05-27 at 10:14 +0200, Wichert Akkerman wrote: > it appears to be sound related: if I disable sound in gaim it works correctly. This is a bug in libao. For what it's worth, it's fixed in upstream SVN, where we've switched to GStreamer. So, it'll be fixed in experimental whenever we release 2.0.0beta4 or 2.0.0final and it's packaged. You might try switching your sound method from automatic to whichever one you're actually using on your system. I believe that works around the problem. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#328889: patch and nmu
If a new package was uploaded, why hasn't there been an update shown on packages.debian.org? Also, this bug is still open? Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359825: gaim: the resource field is appended to the server url. that fails google talk
On Wed, 2006-03-29 at 19:27 +0200, alex bodnaru wrote: > richard, > > i've tryed your advice, but no matter where i put talk.google.com, in > server, connect server or both, or none, i keep getting the same error. > > thanks for your help, and i'd like to be helpful. > > alex Follow the instructions in the link I sent you exactly (including gmail.com in the server box and talk.google.com in the connect server box). If that doesn't work, put googlemail.com instead of gmail.com in the server box (still using talk.google.com in the connect server box). Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359825: gaim: the resource field is appended to the server url. that fails google talk
On Wed, 2006-03-29 at 12:11 +0200, alex bodnaru wrote: > hi, > > to connect to google talk i have to set a jabber acount in gaim (i have > a working gmail acount). > > to save the jabber acount information in gaim i need to fill the > resource field, and it is been appended to the server url. in case i > leave the resource field empty, it is filled with "Gaim". > > attempting to connect to google, i receive "unknown server". remember, > the server name i receive in the pop-up is "server_name/Resource_field". > > i have to notice, that i have no problem with connecting to jabber itself. First, I'm preserving your entire reply so that it'll show up on the bug report. Please preserve the CC to the bug when replying. (Use your mailer's Reply to All functionality.) If you BCC'ed the bug or posted this information some other way, just ignore me. ;) Anyway, I doubt this is related to the resource. Google Talk supports resources just fine. Gaim 1.5.0 doesn't do SRV lookups, if I recall correctly. So, that's why Google's instructions tell you to set a server. Under "Show more options", there is a box for "Connect server". Enter "talk.google.com" there. See http://www.google.com/support/talk/bin/answer.py?answer=24073 for the entire process, including screenshots. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#359825: gaim: the resource field is appended to the server url. that fails google talk
I don't understand this bug report. You're saying Gaim doesn't connect to Google Talk? Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
