Bug#1061692: chirp fails to start with 'No module named 'chirp.stock_configs'
tag 1061692 +patch thanks I've tested it, and it seems that manually adding the path to d/install fixes the problem fine. Patch attached. Sincerely, -- Harlan Lieberman-Berg ~hlieberman From 9d9fc8e0a1b46af0c9bf13e7ff982af1b9e15c07 Mon Sep 17 00:00:00 2001 From: Harlan Lieberman-Berg Date: Sun, 28 Jan 2024 20:56:58 -0500 Subject: [PATCH] Ensure stock configs are installed (Closes: #1061692) --- debian/install | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/install b/debian/install index d2033f8..af982ac 100644 --- a/debian/install +++ b/debian/install @@ -2,3 +2,4 @@ chirp/share/chirp.png /usr/share/pixmaps chirp/share/chirp.desktop /usr/share/applications chirp/share/*.png /usr/share/chirp chirp/locale/* /usr/lib/python3/dist-packages/chirp/locale +chirp/stock_configs /usr/lib/python3/dist-packages/chirp -- 2.43.0
Bug#1061692: chirp fails to start with 'No module named 'chirp.stock_configs'
Package: chirp
Version: 1:20240122-1
Severity: grave
X-Debbugs-Cc: deb...@jouellet.net, hlieber...@debian.org
Hello Dave, all,
Thank you for updating chirp! Unfortunately, it seems that pybuild may have
failed to pick up one of the necessary directories that contains the stock
configurations. Running `chirpw` instantly crashes with the following error:
Traceback (most recent call last):
File "/usr/bin/chirpw", line 33, in
sys.exit(load_entry_point('chirp==20240122', 'console_scripts', 'chirpw')())
^^
File "/usr/lib/python3/dist-packages/chirp/wxui/__init__.py", line 178, in
chirpmain
mainwindow = main.ChirpMain(None, title='CHIRP')
^^^
File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 414, in
__init__
self.SetMenuBar(self.make_menubar())
^^^
File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 644, in
make_menubar
self.OPEN_STOCK_CONFIG_MENU = self.add_stock_menu()
^
File "/usr/lib/python3/dist-packages/chirp/wxui/main.py", line 573, in
add_stock_menu
in importlib_resources.files('chirp.stock_configs').iterdir()
File "/usr/lib/python3.11/importlib/resources/_common.py", line 22, in files
return from_package(get_package(package))
File "/usr/lib/python3.11/importlib/resources/_common.py", line 53, in
get_package
resolved = resolve(package)
File "/usr/lib/python3.11/importlib/resources/_common.py", line 44, in resolve
return cand if isinstance(cand, types.ModuleType) else
importlib.import_module(cand)
^
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1204, in _gcd_import
File "", line 1176, in _find_and_load
File "", line 1140, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'chirp.stock_configs'
Hopefully this is an easy fix! Thanks for your help maintaining this.
73,
--
Harlan Lieberman-Berg (KC1CHE)
~hlieberman
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chirp depends on:
ii python3 [python3-supported-min] 3.11.4-5+b1
ii python3-importlib-resources 6.0.1-1
ii python3-requests 2.31.0+dfsg-1
ii python3-serial 3.5-2
ii python3-six 1.16.0-4
ii python3-yattag 1.15.1-1
ii wxpython-tools 4.2.1+dfsg-3
chirp recommends no packages.
chirp suggests no packages.
-- no debconf information
Bug#1038920: python3-certbot-dns-gandi: Update from Debian 11 -> 12 leaves certificate updates broken
tag 1038920 +patch thanks On Fri, Jun 30, 2023 at 6:35 AM Norbert Preining wrote: > You could still send me the code and I give it an eye ;-) Sold! preinst file is attached. Sincerely, -- Harlan Lieberman-Berg ~hlieberman preinst Description: Binary data
Bug#1038920: python3-certbot-dns-gandi: Update from Debian 11 -> 12 leaves certificate updates broken
On Fri, Jun 23, 2023 at 6:24 AM Norbert Preining wrote: > with the update of certbot and the DNS Gandi plugin, the command line > arguments for requesting a certificate have changed. Hello Norbert, Thanks for letting me know. I've spoken with upstream about this as well, and to see what we can do in the future to ensure something like this doesn't happen again. I've written up a draft preinst script that should rewrite the config files to remove the problem. Do you still have a host that's in the buggy state, or did you fix them all with the workaround? Because it's going to be fixed in a preinst, I'd like more testing (and more eyes) on it than I normally would, just for caution's sake. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#1026537: python-certbot: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13
reassign 1026537 python-cryptography 38.0.4-1 retitle 1026537 python-cryptography fails to depend on python3-cffi affects 1026537 python-certbot thanks On Tue, Dec 20, 2022 at 12:12 Lucas Nussbaum wrote: > > I: pybuild base:240: cd > /<>/.pybuild/cpython3_3.10_certbot/build; python3.10 -m pytest > tests > > = test session starts > == > > platform linux -- Python 3.10.9, pytest-7.2.0, pluggy-1.0.0+repack > > rootdir: /<> > > collected 967 items / 1 error > > > > ERRORS > > > ___ ERROR collecting > .pybuild/cpython3_3.10_certbot/build/tests/cli_test.py > > tests/cli_test.py:21: in > > PLUGINS = disco.PluginsRegistry.find_all() > > certbot/_internal/plugins/disco.py:192: in find_all > > cls._load_entry_point(entry_point, plugins) > > certbot/_internal/plugins/disco.py:199: in _load_entry_point > > plugin_ep = PluginEntryPoint(entry_point) > > certbot/_internal/plugins/disco.py:40: in __init__ > > self.plugin_cls: Type[interfaces.Plugin] = entry_point.load() > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2470: in load > > self.require(*args, **kwargs) > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:2493: in require > > items = working_set.resolve(reqs, env, installer, extras=self.extras) > > /usr/lib/python3/dist-packages/pkg_resources/__init__.py:795: in resolve > > raise DistributionNotFound(req, requirers) > > E pkg_resources.DistributionNotFound: The 'cffi>=1.12' distribution > was not found and is required by cryptography > > === short test summary info > > > ERROR tests/cli_test.py - pkg_resources.DistributionNotFound: The > 'cffi>=1.12... > > Interrupted: 1 error during collection > > > === 1 error in 1.43s > === This error stems from the .egg-info file being shipped as part of python3-cffi, but the python3-cryptography lib only having Depends on the cffi backend lib. Morph, can you take a peek at this? Thanks! Sincerely, — Harlan Lieberman-Berg ~hlieberman > -- Harlan Lieberman-Berg ~hlieberman
Bug#1008992: xwayland: all X clients hang indefinitely waiting for /tmp/.X11-unix/X0
Package: xwayland Version: 2:22.1.1-1 Severity: grave Justification: renders package unusable X-Debbugs-Cc: hlieber...@debian.org After upgrade to 2:22.1.1-1, all X applications refuse to start. strace shows that they hang on connect(2), waiting for the /tmp/.X11-unix/X0 socket. XWayland on my system is being started by Gnome/mutter, with the following command line showing in ps: /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.A4B0J1 -listen 4 -listen 5 -displayfd 6 -initfd 7 A full strace of an xeyes session (up through ^C) is attached. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xwayland depends on: ii libc6 2.33-7 ii libdrm2 2.4.110-1 ii libepoxy0 1.5.10-1 ii libgbm1 21.3.7-1 ii libgcrypt20 1.10.1-2 ii libgl1 1.4.0-1 ii libpixman-1-0 0.40.0-1 ii libtirpc3 1.3.2-2 ii libwayland-client0 1.20.0-1 ii libxau6 1:1.0.9-1 ii libxcvt00.1.1-3 ii libxdmcp6 1:1.1.2-3 ii libxfont2 1:2.0.5-1 ii libxshmfence1 1.3-1 ii xserver-common 2:21.1.3-2 xwayland recommends no packages. xwayland suggests no packages. -- no debconf information xeyes.log.13007.gz Description: application/gzip
Bug#1005977: fwupd-signed
It looks like this is due to the migration of the efi capsule out to the virtual packages fwupd-signed and fwupd-unsigned. Installing one should fix the problem, but this bug should remain open to fix the underlying Recommends’ bug.-- Harlan Lieberman-Berg ~hlieberman
Bug#1005854: pudb contains LGPL code, potentially changing the copyright status
Source: pudb Version: 2020.1-1 Severity: serious Tags: upstream Justification: Policy 2.3 X-Debbugs-Cc: hlieber...@debian.org In debugging pudb recently, I found a notice in pudb/settings.py (L35-63) where the author has pointed out a section of code that was copied from pyxdg. Looking in pyxdg, the substantially same code is in xdg/BaseDirectory.py, dating back several years. I see three paths to fix this: 1, Simply declare the entire package licensed under LGPL. That requires no code changes and updates potential downstream users about a conflict. 2. Trace the lines of code to an author inside pyxdg and attempt to get them to agree to license that segment under MIT. 3. Replace the code with an equivalent clean-room implementation. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1
On Sun, Mar 21, 2021 at 7:04 PM Don Armstrong wrote: > Hrm. It was maintained by you, but there's a non-zero chance I installed it > directly from source. If it's never been uploaded, that's probably what > happened. Iiiinteresting. The plover repo that I've been working out of has 3.1.1 as the earliest version (Mon Nov 18 23:01:12 2019 -0500), but I do remember vaguely trying to decide if I was going to split the common out into its own repo. I think the 3.0.0 might be dated back to when we were waiting on the relicensing to solve the fact that it was undistributable (GPLv2 only / GPLv3 only) and I was trying to figure out the packaging in preparation. Sorry about that! -- Harlan Lieberman-Berg ~hlieberman
Bug#985675: plover 4.0.0~dev8~66~g685bd33-2 is missing Conflicts/Replaces plover-common 3.0.0-1
tag 985675 +moreinfo thanks On Sun, Mar 21, 2021 at 3:39 PM Don Armstrong wrote: > plover-common 3.0.0-1 and plover 4.0.0~dev8~66~g685bd33-2 both ship > /usr/share/plover/assets/american_english_words.txt, but the latter is > missing the appropriate Conflicts/Replaces. Hi Don, Where have you installed plover-common from? That's not a package I recognize in the archive. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#973837: evdi module fails to compile on Linux 5.9.0
Package: evdi-dkms Version: 1.7.0+dfsg-1 Severity: grave Hello maintainer, Looking at #960391, it looks like we've seen another kernel regression for evdi. Even on the evdi-dkms from experimental, the module FTBFS with 5.9.0. The compile log is attached. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evdi-dkms depends on: ii dkms 2.8.3-4 Versions of packages evdi-dkms recommends: ii libevdi0 1.7.0+dfsg-1 evdi-dkms suggests no packages. -- no debconf information DKMS make.log for evdi-1.7.0+dfsg for kernel 5.9.0-1-amd64 (x86_64) Thu 05 Nov 2020 03:49:36 PM EST make: Entering directory '/usr/src/linux-headers-5.9.0-1-amd64' AR /var/lib/dkms/evdi/1.7.0+dfsg/build/built-in.a CC [M] /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.o CC [M] /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.o CC [M] /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_connector.o CC [M] /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_encoder.o /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:92:3: error: ‘struct drm_driver’ has no member named ‘gem_free_object’; did you mean ‘gem_open_object’? 92 | .gem_free_object = evdi_gem_free_object, | ^~~ | gem_open_object /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:92:21: error: initialization of ‘void (*)(struct drm_device *)’ from incompatible pointer type ‘void (*)(struct drm_gem_object *)’ [-Werror=incompatible-pointer-types] 92 | .gem_free_object = evdi_gem_free_object, | ^~~~ /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:92:21: note: (near initialization for ‘driver.lastclose’) /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c: In function ‘evdi_platform_probe’: /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.c:173:20: error: ‘struct dev_archdata’ has no member named ‘iommu’ 173 | pdev->dev.archdata.iommu = INTEL_IOMMU_DUMMY_DOMAIN; |^ /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.c: In function ‘evdi_crtc_cursor_set’: /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.c:133:2: error: implicit declaration of function ‘drm_gem_object_put_unlocked’; did you mean ‘drm_gem_object_put_locked’? [-Werror=implicit-function-declaration] 133 | drm_gem_object_put_unlocked(obj); | ^~~ | drm_gem_object_put_locked cc1: some warnings being treated as errors make[2]: *** [/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288: /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_drv.o] Error 1 make[2]: *** Waiting for unfinished jobs cc1: some warnings being treated as errors make[2]: *** [/usr/src/linux-headers-5.9.0-1-common/scripts/Makefile.build:288: /var/lib/dkms/evdi/1.7.0+dfsg/build/evdi_modeset.o] Error 1 make[1]: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:1796: /var/lib/dkms/evdi/1.7.0+dfsg/build] Error 2 make: *** [/usr/src/linux-headers-5.9.0-1-common/Makefile:185: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-headers-5.9.0-1-amd64'
Bug#966085: gitlab contains git bundles with non-free code, unlisted code
Source: gitlab
Severity: serious
Hello maintainer,
The source package contains copies of various project templates
(vendor/project_templates) that contain copyleft code which needs to
be mentioned in d/copyright.
For example, the git bundle ("./project.bundle") inside
vendor/project_templates/hexo.tar.gz contains the FontAwesome
webfonts, licensed under SIL OFL 1.1.
Additionally, some code contained in these bundles is non-DFSG free.
For example, in the same bundle as previously mentioned, in
landscape/source/fancybox there are files which are licensed under CC
BY-NC 3.0.
Please search the contents of the project templates git bundles for
files and incorporate it into the d/copyright file, or ensure they are
excluded from all distributed binaires.
Sincerely,
Bug#964242: bsdmainutils: depends on non-existing version of bsdextrautils
affects 964242 debootstrap thanks On Sun, 5 Jul 2020 12:52:54 +0200 Michael Meskes wrote: > On Sat, Jul 04, 2020 at 10:52:04AM +0200, Rene Engelhard wrote: > > But that bsdextrautils (>= 2.35.2-7) doesn't exist: > > Yes, as already communicated we had to wait with the next util-linux upload > until bsdmainutils made it out of NEW. Now that it has, Chris will upload as > soon as he finds the time. Because debootstrap follows Recommends and bsdmainutils is Recommended by bsdutils in Priority: required, this bug means debootstrap can't currently create sid bases. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#963583: sysdig: sysdig segfaults on start
On Tue, 23 Jun 2020 18:59:25 -0700 Dima Kogan wrote: > $ sudo sysdig ... > sysdig: symbol lookup error: sysdig: undefined symbol: > _ZN9grpc_impl23CreateCustomChannelImplERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt10shared_ptrINS_18ChannelCredentialsEERKNS_16ChannelArgumentsE > > This sounds like #955279, but even if it is, there should be a > Conflicts, or something, to prevent me from getting into that state. In > any case, I just Updating the gprc library was probably the thing that fixed it; there was a bad libgrpc version. AFAIK you shouldn't need the libgrpc++-dev package to run sysdig. > And now it segfaults again: > > $ sudo sysdig > zsh: segmentation fault sudo sysdig Hm, this is strange. I've tested this a couple of different ways, including on a clean sid box and a sid box with libc downgraded to the same version as on your machine, but I can't recreate the error. Would it be possible for you to use rr to capture a dump of the segfault for me? Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#947816: GeoLite2 databases are now non-free
Nope; that’s what I get for filing bugs while sleep deprived. Sorry for the spam! On Tue, Dec 31, 2019 at 04:10 Faidon Liambotis wrote: > On Mon, Dec 30, 2019 at 11:37:52PM -0500, Harlan Lieberman-Berg wrote: > > > > > > Based on this license change, it seems to me that geoipupdate can no > > longer be in main. Contrib may be a suitable home, however? > > geoipupdate is already in contrib (it has always been that way). Did you > perhaps miss that, or did I misunderstood your question? > > Regards, > Faidon > -- Harlan Lieberman-Berg ~hlieberman
Bug#947816: GeoLite2 databases are now non-free
Package: geoipupdate Severity: serious Hello maintainer, Unfortunately, it seems that MaxMind have changed their policies on GeoLite2 databases such that they now require a license key. In addition (and more critically), they are no longer licensed under a Creative Commons BY-SA license, and now are under a custom EULA. I reviewed the EULA (https://www.maxmind.com/en/geolite2/eula) and, while I am neither an attorney nor a debian-legal faux-counsel, the agreement seems to violate the DFSG in several regards. First, it places restrictions on fields of endeavor -- specifically, that you may not use the data for Fair Credit Reporting Act purposes, including determining whether a person may be granted credit, eligible for insurance, for employment purposes, or any other purpose governed by the FCRA. Second, you are no longer permitted to redistribute the data except by binding them to the EULA. Third, you are required to check in with MaxMind regularly and destroy old versions of the dataset within 30 days. This seems to violate several long-standing interpretations of the DFSG including the desert island test and the tentacles of evil test. Based on this license change, it seems to me that geoipupdate can no longer be in main. Contrib may be a suitable home, however? Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#934843: parsedatetime: FTBFS in stretch
tag 934843 +unreproducible thanks On Thu, 15 Aug 2019 19:12:49 + Santiago Vila wrote: > I tried to build this package in stretch but it failed: Hello! This is quite strange. I've tried rebuilding it several times in my stretch sbuild, and it worked every time without error. I also re-triggered the build on reproducible-builds, and it's now clean there as well. One possibility that comes to mind is locales -- what locales are you compiling under? It's possible there's a bug in one of the locale-specific parsers that's not getting exercised on my sbuild, through, I admit to not being sure how reproducible-builds could have been affected by the same thing. Otherwise, maybe a difference in one of the deps that was fixed in the last... day? Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#935211: python-acme: Please port to Python 3 and/or drop Python 2 package
Yup; I’m targeting it for tomorrow evening when I have some time to do Debian work. On Tue, Oct 1, 2019 at 14:29 Sunil Mohan Adapa wrote: > Hello, > > The python-acme package and consequently, all of certbot and FreedomBox, > are set to be autoremoved from Debian testing in just a few days from > now on Sunday, the 6th of October, 2019. Since the fix seems to be > straight forward, can some please look into this and upload the package > without Python2 and python3-ndg-httpsclient? > > Gianfranco Costamagna, the patch you have attached seems to be incorrect > and meant for another unrelated package. > > Thank you, > > -- > Sunil > > -- Harlan Lieberman-Berg ~hlieberman
Bug#928452: POST-as-GET support needed in Buster
Source: python-certbot Version: 0.31.0-1 Severity: serious Tags: upstream Because of changes to the ACME v2 standard, unauthenticated GET requests to ACME compatible APIs must be performed as special POST-as-GET requests to be valid. The primary ACME API, Let's Encrypt, has deprecated support for unauthenticated GET requests as of October 2018, and plans on removing support for them entirely on November 1, 2019. To prevent the version being frozen into buster from becoming RC-buggy on November 1, a backport is being prepared to add this functionality before buster is released in coordination with upstream. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#905929: marked as done (sysdig FTBFS on arm64/mips*/alpha/riscv64: syscall_table.c fails to compile)
reopen 905929 notfixed 905929 0.24.1-2 thanks Unfortunately, the patch was missing an #ifdef. Correcting with -3
Bug#926541: src:lexicon: Build-Depends on python-softlayer which will be removed
On Mon, 8 Apr 2019 16:50:31 +0100 ana wrote: > Thanks for the update on this. It would be a shame to drop the package > entirely from Debian. Have had a look at the packaging on salsa and I'm > happy to take over. I would need DM permissions on it to make uploads. Hi Ana! Happy to sponsor you for uploading on it if you'll take it over. Ping me on the original removal bug when you have the upload prepared that names you as a maintainer and closes the O. -Harlan
Bug#922031: Timer Disabling on Package Update? (is: #922031)
On Sun, Mar 10, 2019 at 1:19 PM Michael Biebl wrote: > Let's bump this to serious. I think you should consider making another > stable upload for this. > As users have pointed out, systems which aren't rebooted regularly are > otherwise up for a nasty experience. > You might consider asking the security team to distribute the update > with stable-security more quickly and not wait for the next stable upload. I agree; this needs an update. I'll open a ticket with the SRMs and see what they think about it going to -security. > You have a couple of options to fix this: > 1/ Switch the compat level back to what 0.10 was using I think this is the most reasonable approach, since newer versions aren't using dh_installsystemd anyway. The bigger question for me is... what do we do about users who have already upgraded? If my understanding is correct, if we switch back to compat level 9, they'll all be forcibly started again by the postinst, correct? Or do we need to explicitly start it again? -- Harlan Lieberman-Berg ~hlieberman
Bug#921423: /var/log/letsencrypt gets wiped on transitional package purge
On Tue, Feb 5, 2019 at 10:57 PM Mattia Rizzolo wrote: > Sure, of course that's the cause, but your suggested fix would instead > introduce the other bug that "purge does not delete related logs", which > is what everybody is expecting "purge" to do. Hi Mattia, The bug here is that the transitional dummy package purges the directory that the main package which provides it uses. Both certbot and letsencrypt use `/var/log/letsencrypt` for their log storage, but the letsencrypt package has been hollowed out and made into a dummy. The directory will still be deleted if you purge certbot, which is the new and correct owner of that path. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#912103: python-certbot-dns-route53 FTBFS: ConnectionRefusedError: [Errno 111] Connection refused
", line 152, in
> _send_output
> self.send(msg)
> File "/usr/lib/python3/dist-packages/botocore/awsrequest.py", line 236, in
> send
> return super(AWSConnection, self).send(str)
> File "/usr/lib/python3.6/http/client.py", line 964, in send
> self.connect()
> File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 166, in
> connect
> conn = self._new_conn()
> File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 150, in
> _new_conn
> self, "Failed to establish a new connection: %s" % e)
> urllib3.exceptions.ProxyError: ('Cannot connect to proxy.',
> NewConnectionError(' 0x7fe256361358>: Failed to establish a new connection: [Errno 111] Connection
> refused',))
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File
> "/build/1st/python-certbot-dns-route53-0.23.0/certbot_dns_route53/dns_route53_test.py",
> line 23, in setUp
> self.auth = Authenticator(self.config, "route53")
> File
> "/build/1st/python-certbot-dns-route53-0.23.0/certbot_dns_route53/dns_route53.py",
> line 36, in __init__
> self.r53 = boto3.client("route53")
> File "/usr/lib/python3/dist-packages/boto3/__init__.py", line 91, in client
> return _get_default_session().client(*args, **kwargs)
> File "/usr/lib/python3/dist-packages/boto3/session.py", line 263, in client
> aws_session_token=aws_session_token, config=config)
> File "/usr/lib/python3/dist-packages/botocore/session.py", line 878, in
> create_client
> credentials = self.get_credentials()
> File "/usr/lib/python3/dist-packages/botocore/session.py", line 479, in
> get_credentials
> 'credential_provider').load_credentials()
> File "/usr/lib/python3/dist-packages/botocore/credentials.py", line 1663,
> in load_credentials
> creds = provider.load()
> File "/usr/lib/python3/dist-packages/botocore/credentials.py", line 842, in
> load
> metadata = fetcher.retrieve_iam_role_credentials()
> File "/usr/lib/python3/dist-packages/botocore/utils.py", line 291, in
> retrieve_iam_role_credentials
> r = self._get_request(url, timeout, num_attempts)
> File "/usr/lib/python3/dist-packages/botocore/utils.py", line 276, in
> _get_request
> response = self._session.send(request.prepare())
> File "/usr/lib/python3/dist-packages/botocore/httpsession.py", line 264, in
> send
> raise ProxyConnectionError(proxy_url=proxy_url, error=e)
> botocore.exceptions.ProxyConnectionError: Failed to connect to proxy URL:
> "http://127.0.0.1:9/;
> ...
> Ran 17 tests in 0.061s
>
> FAILED (errors=17)
> Test failed:
> error: Test failed: failures=0>
> E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1:
> python3.6 setup.py test
> dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
> make: *** [debian/rules:6: build] Error 25
>
--
Harlan Lieberman-Berg
~hlieberman
Bug#902620: certbot.service should not use root privileges
forcemerge 819107 902620 810216 severity 902620 normal thanks Hello Roland, We definitely want to move to using a more "Debian standard" approach to the certbot user -- especially for the keys it writes out --, but it's a complicated problem. For example, many of the certbot plugins add or alter webserver configuration, which means that the certbot user would need permission to access those directories, or some method of gaining higher privileges for certain operations. This is something we've talked about with upstream in the past, but we don't currently have a plan to implement. I'd personally like to see us switch to use a more Debian approach for the key storage before we do anything else -- something I'd like to see go into buster. Thanks for reporting this! -- Harlan Lieberman-Berg ~hlieberman
Bug#898433: FTBFS: README.md -> README.rst
Oh, I see what's happening. Lee, can you do a -2 and make sure to merge against git on salsa? On Fri, May 18, 2018 at 2:49 PM, Harlan Lieberman-Berg <hlieber...@setec.io> wrote: > Hi Daniel, > > I'm a bit confused as well. I didn't upload any debs at all; I did a > source-only upload. The buildd's successfully built -2 against the > original tarball that was uploaded with -1... and I just rebuilt it > again. > > Can you verify your source matches the sha256sum of > 5e817a3e077565bc1ff294d5a4748fbd8d78435fa721ebf617945568e45d603a? You > can retrieve the original source with pristine-tar against the git > repository on salsa. > > On Fri, May 18, 2018 at 1:20 PM, Daniel Baumann > <daniel.baum...@progress-linux.org> wrote: >> reopen 898433 >> found 898433 2.5.3+dfsg-1 >> thanks >> >> Hi, >> >> thanks for fixing it, however, your last upload unfortunaly re-imports >> the problem. >> >> I'm a bit confused on how the package could have been built at all. The >> source package FTBFS'es, but you could upload the *_all.debs. Do you >> build from different sources than what is included in the source package? >> >> Regards, >> Daniel > > > > -- > Harlan Lieberman-Berg > ~hlieberman -- Harlan Lieberman-Berg ~hlieberman
Bug#898433: FTBFS: README.md -> README.rst
Hi Daniel, I'm a bit confused as well. I didn't upload any debs at all; I did a source-only upload. The buildd's successfully built -2 against the original tarball that was uploaded with -1... and I just rebuilt it again. Can you verify your source matches the sha256sum of 5e817a3e077565bc1ff294d5a4748fbd8d78435fa721ebf617945568e45d603a? You can retrieve the original source with pristine-tar against the git repository on salsa. On Fri, May 18, 2018 at 1:20 PM, Daniel Baumann <daniel.baum...@progress-linux.org> wrote: > reopen 898433 > found 898433 2.5.3+dfsg-1 > thanks > > Hi, > > thanks for fixing it, however, your last upload unfortunaly re-imports > the problem. > > I'm a bit confused on how the package could have been built at all. The > source package FTBFS'es, but you could upload the *_all.debs. Do you > build from different sources than what is included in the source package? > > Regards, > Daniel -- Harlan Lieberman-Berg ~hlieberman
Bug#894025: python-certbot-dns-cloudflare: Fails to build from source
Hm, so, we've never shipped the testdata. All the way back to the first tag (0.0.0.dev20151104-1), we've removed the testdata. It's only for the test cases, so we don't ship it out in the debs. An update to the python version caused the way that it was being deleted to break a while ago, it looks like. A user reported it to me recently because it was causing chkrootkit to trip on their systems, so I fixed the removal in 8bb2938. I'm not sure what we should do here. Shipping the testdata isn't a huge amount of resources for the end user, though it's a bit annoying that it's causing some security stuff to complain. We could create an intermediary package that just ships the testdata that we could B-D on, but that seems potentially unnecessary for the additional load on the ftpmasters and the archive. We could also ask upstream to ship the testdata that each package needs with each package. Thoughts? On Sun, Mar 25, 2018 at 10:45 AM, Andrew Starr-Bochicchio <a...@debian.org> wrote: > On Sun, Mar 25, 2018 at 9:47 AM, Jeremy Bicha <jbi...@debian.org> wrote: >> >> error: [Errno 2] No such file or directory: >> '/usr/lib/python3/dist-packages/certbot/tests/testdata/rsa512_key.pem' >> >> Full build log at >> https://launchpad.net/ubuntu/+source/python-certbot-dns-clou >> dflare/0.22.0-1/+build/14491162 >> > > Looks like this was caused by this change in the main certbot package: > > https://salsa.debian.org/letsencrypt-team/certbot/certbot/commit/ > 8bb2938afb15594cb79f8661d951724323f0e754 > > Harlan, any more context on that or concerns about reverting? > > Thanks, > > -- Andrew Starr-Bochicchio > >Debian Developer <http://qa.debian.org/developer.php?login=asb> >Ubuntu Developer <https://launchpad.net/~andrewsomething> >PGP/GPG Key ID: 3B56E2BBD53FDCB1 > > -- Harlan Lieberman-Berg ~hlieberman
Bug#880246: magic-wormhole: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
tag 880246 +pending thanks Hi Antoine, I talked with the Privacy Tools team, and they've taken the patch. 0.10.3-1 now builds successfully and works fine! It's waiting for your upload. Sincerely, On Sat, Jan 6, 2018 at 7:30 PM, Harlan Lieberman-Berg <hlieber...@debian.org> wrote: > On Sat, Jan 6, 2018 at 12:45 PM, Antoine Beaupré > <anar...@orangeseeds.org> wrote: >> I'm fine with you pushing to collab-maint - this is what it's for after >> all. :) > > Still, didn't want you to get surprised if you were working on it at > the same time! > >> So even after this you still FTBFS? Did you report that issue upstream >> as well? > > Right now, it's FTBFS because of an inappropriate dependency in the > setuptools config of one of the libraries, txtorcon. They've merged > my PR, but they haven't cut a new release yet. If you want, I can > open a bug over with the Privacy Tools team and see if they'd be > willing to take the patch out of the release cycle. > > Sincerely, > -- > Harlan Lieberman-Berg > ~hlieberman -- Harlan Lieberman-Berg ~hlieberman
Bug#886581: do not transition; errors in the dependency chain
Package: certbot Version: 0.20.0-1 Severity: grave A placeholder to ensure that the new version doesn't transition out of unstable due to dependency problems. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages certbot depends on: ii init-system-helpers 1.51 ii python 2.7.14-4 pn python-certbot certbot recommends no packages. Versions of packages certbot suggests: pn python-certbot-apache pn python-certbot-doc
Bug#880246: magic-wormhole: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
On Sat, Jan 6, 2018 at 12:45 PM, Antoine Beaupré <anar...@orangeseeds.org> wrote: > I'm fine with you pushing to collab-maint - this is what it's for after > all. :) Still, didn't want you to get surprised if you were working on it at the same time! > So even after this you still FTBFS? Did you report that issue upstream > as well? Right now, it's FTBFS because of an inappropriate dependency in the setuptools config of one of the libraries, txtorcon. They've merged my PR, but they haven't cut a new release yet. If you want, I can open a bug over with the Privacy Tools team and see if they'd be willing to take the patch out of the release cycle. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#874191: might be a duplicate
Hm. Looking more, you may be right. What's odd is that some binaries
that are (presumably) being launched by Gnome are being correctly
given the right context; for example, gdm and X are running as
system_u:system_r:xdm_t:s0-s0:c0.c1023. evolution-calendar, though,
is system_u:system_r:init_t:s0. And yet other things that are
probably also part of my user session are
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023.
Suffice it to say, I'm quite confused!
(Attached a copy of my pstree.)
On Mon, Sep 4, 2017 at 1:26 AM, Russell Coker <russ...@coker.com.au> wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874201
>
> Yesterday I was investigating an issue that might be related and I just filed
> the above bug report. Please investigate whether that might be the cause.
>
> # ps axZ|grep sddm
> system_u:system_r:xdm_t:s0-s0:c0.c1023 963 ? Ssl0:00 /usr/bin/sddm
>
> Run "ps axZ|grep gdm3" to see the context, the output should be something like
> the above if all goes well (xdm_t is the relevant part).
>
> # ls -lZ /usr/bin/sddm
> -rwxr-xr-x. 1 root root system_u:object_r:xdm_exec_t:s0 475968 Mar 14 19:50 /
> usr/bin/sddm
>
> Also run "ls -lZ" on the binary to see if it has the right context, the output
> should be something like the above, xdm_exec_t is the relevant part.
>
> If those checks pass then run the systemctl command suggested in #874201 and
> restart gdm3 to see if it gets the right context.
>
> PS I gave up on gdm3 last time due to some other issues. Is there a gdm3
> specific feature you really need? If you want to improve Debian then
> debugging this is a good thing to do, if you just want a working system then
> sddm might be a better choice.
>
> --
> My Main Blog http://etbe.coker.com.au/
> My Documents Bloghttp://doc.coker.com.au/
>
--
Harlan Lieberman-Berg
~hlieberman
agartha 福 ~
10003 ◯ : pstree -pZ
systemd(1,`system_u:system_r:init_t:s0')
├─ModemManager(1551,`system_u:system_r:modemmanager_t:s0')
│ ├─{ModemManager}(1588,`system_u:system_r:modemmanager_t:s0')
│ └─{ModemManager}(1592,`system_u:system_r:modemmanager_t:s0')
├─NetworkManager(1547,`system_u:system_r:NetworkManager_t:s0')
│ ├─dhclient(3009,`system_u:system_r:dhcpc_t:s0')
│ ├─{NetworkManager}(1633,`system_u:system_r:NetworkManager_t:s0')
│ └─{NetworkManager}(1647,`system_u:system_r:NetworkManager_t:s0')
├─accounts-daemon(1561,`system_u:system_r:accountsd_t:s0')
│ ├─{accounts-daemon}(1576,`system_u:system_r:accountsd_t:s0')
│ └─{accounts-daemon}(1580,`system_u:system_r:accountsd_t:s0')
├─acpid(1521,`system_u:system_r:apmd_t:s0')
├─apt-cacher-ng(1859,`system_u:system_r:initrc_t:s0')
├─atd(1554,`system_u:system_r:crond_t:s0-s0:c0.c1023')
├─auditd(1221,`system_u:system_r:auditd_t:s0')
│ └─{auditd}(1222,`system_u:system_r:auditd_t:s0')
├─avahi-daemon(1568,`system_u:system_r:avahi_t:s0')
│ └─avahi-daemon(1591,`system_u:system_r:avahi_t:s0')
├─bluetoothd(1541,`system_u:system_r:init_t:s0')
├─colord(1825,`system_u:system_r:colord_t:s0')
│ ├─{colord}(1955,`system_u:system_r:colord_t:s0')
│ └─{colord}(1970,`system_u:system_r:colord_t:s0')
├─console-kit-dae(3572,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3573,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3575,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3576,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3577,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3578,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3579,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3580,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3581,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3582,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3583,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3584,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3585,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3586,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3587,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3588,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3589,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3590,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3591,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3592,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3593,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3594,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3595,`system_u:system_r:consolekit_t:s0')
│ ├─{console-kit-dae}(3596,`system_u:syste
Bug#874191: gdm3 started users start in wrong context
Package: selinux-policy-default Version: 2:2.20161023.1-9 Severity: serious Hello maintainers, It seems that shells started via Gnome start with the wrong context. Logging in from a console shell gives me an id of unconfined_u:unconfined_r:unconfined_t:s0-s0, whereas terminals opened inside Gnome give me a context of system_u:system_r:initrc_t:s0. Sincerely, -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages selinux-policy-default depends on: ii libselinux1 2.6-3+b2 ii libsemanage1 2.6-2+b1 ii libsepol12.6-2 ii policycoreutils 2.6-3 ii selinux-utils2.6-3+b2 Versions of packages selinux-policy-default recommends: ii checkpolicy 2.6-2 ii setools 4.0.1-6+b1 Versions of packages selinux-policy-default suggests: pn logcheck pn syslog-summary -- no debconf information
Bug#866663: python3-cairo: breaks apt upgrades due to conflict with debconf
fixed 83 1.10.0+dfsg-5+b3 thanks This looks like an instance of #866572 that was fixed with the next build. -- Harlan Lieberman-Berg ~hlieberman
Bug#860839: Uploading logs
tag 860839 -moreinfo thanks [hlieberm@crete ~]$ qmake -query qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory [hlieberm@crete ~]$ qmake -qt5 -query qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt5/bin/qmake': No such file or directory [hlieberm@crete ~]$ qmake -qt4 -query qmake: could not exec '/usr/lib/x86_64-linux-gnu/qt4/bin/qmake': No such file or directory [hlieberm@crete ~]$ After installing qt5-qmake: [hlieberm@crete ~]$ qmake -qt5 -query QT_SYSROOT: QT_INSTALL_PREFIX:/usr QT_INSTALL_ARCHDATA:/usr/lib/x86_64-linux-gnu/qt5 QT_INSTALL_DATA:/usr/share/qt5 QT_INSTALL_DOCS:/usr/share/qt5/doc QT_INSTALL_HEADERS:/usr/include/x86_64-linux-gnu/qt5 QT_INSTALL_LIBS:/usr/lib/x86_64-linux-gnu QT_INSTALL_LIBEXECS:/usr/lib/x86_64-linux-gnu/qt5/libexec QT_INSTALL_BINS:/usr/lib/x86_64-linux-gnu/qt5/bin QT_INSTALL_TESTS:/usr/tests QT_INSTALL_PLUGINS:/usr/lib/x86_64-linux-gnu/qt5/plugins QT_INSTALL_IMPORTS:/usr/lib/x86_64-linux-gnu/qt5/imports QT_INSTALL_QML:/usr/lib/x86_64-linux-gnu/qt5/qml QT_INSTALL_TRANSLATIONS:/usr/share/qt5/translations QT_INSTALL_CONFIGURATION:/etc/xdg QT_INSTALL_EXAMPLES:/usr/lib/x86_64-linux-gnu/qt5/examples QT_INSTALL_DEMOS:/usr/lib/x86_64-linux-gnu/qt5/examples QT_HOST_PREFIX:/usr QT_HOST_DATA:/usr/lib/x86_64-linux-gnu/qt5 QT_HOST_BINS:/usr/lib/x86_64-linux-gnu/qt5/bin QT_HOST_LIBS:/usr/lib/x86_64-linux-gnu QMAKE_SPEC:linux-g++-64 QMAKE_XSPEC:linux-g++-64 QMAKE_VERSION:3.0 QT_VERSION:5.7.1 VLC still errors: [hlieberm@crete ~]$ QT_DEBUG_PLUGINS=1 vlc VLC media player 2.2.5 Weatherwax (revision 2.2.5-0-g9275f0fefa) [56310dca2148] core libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. QFactoryLoader::QFactoryLoader() checking directory path "/usr/bin/platforms" ... This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". Reinstalling the application may fix this problem. zsh: abort QT_DEBUG_PLUGINS=1 vlc
Bug#860839: vlc fails to start due to missing QT platform plugin xcb
Package: src:vlc Version: 2.2.5-1 Severity: grave Justification: renders package unusable Hello maintainer, For vlc installed on stretch freshly after a `apt install vlc`, it refuses to open while complaining about a failure to find the xcb Qt module. Attached `vlc -vvv`. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages vlc depends on: ii dpkg 1.18.23 ii vlc-bin 2.2.5-1 ii vlc-l10n 2.2.5-1 ii vlc-plugin-base 2.2.5-1 ii vlc-plugin-qt2.2.5-1 ii vlc-plugin-video-output 2.2.5-1 Versions of packages vlc recommends: ii vlc-plugin-notify 2.2.5-1 ii vlc-plugin-samba 2.2.5-1 ii vlc-plugin-skins2 2.2.5-1 ii vlc-plugin-video-splitter 2.2.5-1 ii vlc-plugin-visualization 2.2.5-1 vlc suggests no packages. Versions of packages libvlc-bin depends on: ii libc62.24-9 ii libvlc5 2.2.5-1 Versions of packages libvlc5 depends on: ii dpkg 1.18.23 ii libc62.24-9 ii libvlccore8 2.2.5-1 Versions of packages libvlc5 recommends: ii libvlc-bin 2.2.5-1 Versions of packages libvlccore8 depends on: ii dpkg 1.18.23 ii libc62.24-9 ii libdbus-1-3 1.10.18-1 ii libidn11 1.33-1 Versions of packages libvlccore8 recommends: ii libproxy-tools 0.4.14-2 Versions of packages vlc-bin depends on: ii libc6 2.24-9 ii libvlc-bin 2.2.5-1 ii libvlc5 2.2.5-1 Versions of packages vlc-plugin-base depends on: ii liba52-0.7.4 0.7.4-19 ii libasound2 1.1.3-5 ii libass51:0.13.4-2 ii libavahi-client3 0.6.32-2 ii libavahi-common3 0.6.32-2 ii libavc1394-0 0.5.4-4+b1 ii libbasicusageenvironment1 2016.11.28-1 ii libbluray1 1:0.9.3-3 ii libbz2-1.0 1.0.6-8.1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libcddb2 1.3.2-5 ii libcdio13 0.83-4.3+b1 ii libchromaprint11.4.2-1 ii libcrystalhd3 1:0.0~git20110715.fdd2f19-12 ii libdbus-1-31.10.18-1 ii libdc1394-22 2.2.5-1 ii libdca00.0.5-10 ii libdirectfb-1.2-9 1.2.10.0-8 ii libdvbpsi101.3.0-5 ii libdvdnav4 5.0.3-3 ii libdvdread45.0.3-2 ii libebml4v5 1.3.4-1 ii libfaad2 2.8.0~cvs20161113-1 ii libflac8 1.3.2-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.1 ii libfribidi00.19.7-1+b1 ii libgcc11:6.3.0-12 ii libgcrypt201.7.6-1 ii libglib2.0-0 2.50.3-2 ii libgme00.6.0-4 ii libgnutls303.5.8-5 ii libgpg-error0 1.26-2 ii libgroupsock8 2016.11.28-1 ii libgsm11.0.13-4+b2 ii libjpeg62-turbo1:1.5.1-2 ii libkate1 0.4.1-7+b1 ii liblirc-client00.9.4c-9 ii liblivemedia57 2016.11.28-1 ii liblua5.2-05.2.4-1.1+b2 ii liblzma5 5.2.2-1.2+b1 ii libmad00.15.1b-8 ii libmatroska6v5 1.4.5-2 ii libmp3lame03.99.5+repack1-9+b2 ii libmpcdec6 2:0.1~r495-1+b1 ii libmpeg2-4 0.5.1-7+b2 ii libmtp91.1.12-1+b1 ii libncursesw5 6.0+20161126-1 ii libogg01.3.2-1 ii libopenmpt-modplug10.2.7386~beta20.3-3 ii libopus0 1.2~alpha2-1 ii libpng16-161.6.28-1 ii libpulse0 10.0-1 ii libraw1394-11 2.1.2-1+b1 ii libresid-builder0c2a 2.1.1-15 ii librsvg2-2 2.40.16-1+b1 ii librtmp1 2.4+20151223.gitfa8646d.1-1+b1 ii libsamplerate0 0.1.8-8+b2 ii libsdl-image1.21.2.12-5+b8 ii libsdl1.2debian1.2.15+dfsg1-4 ii libshine3 3.1.0-5 ii libshout3 2.3.1-3 ii libsidplay22.1.1-15 ii libsnappy1v5 1.1.3-3 ii libsndio6.11.1.0-3 ii libspeex1 1.2~rc1.2-1+b2 ii libspeexdsp1 1.2~rc1.2-1+b2 ii libssh-gcrypt-40.7.3-2 ii libssh2-1 1.7.0-1 ii libstdc++6 6.3.0-12 ii libtag1v5 1.11.1+dfsg.1-0.1 ii libtheora0 1.1.1+dfsg.1-14+b1 ii libtinfo5 6.0+20161126-1 ii libtwolame00.3.13-2 ii libudev1 232-22 ii libupnp6
Bug#858802: [Letsencrypt-devel] Bug#858802: AttributeError: 'module' object has no attribute 'DependencyError'
Patrick Lam <prof@gmail.com> writes:
> plam@patricklam:~$ apt-cache policy $(apt-rdepends -p certbot 2>|
> /dev/null|awk '/Depends/ {print $2}'|sort -u)|awk '/^[^ ]/ {
> package=$0 } / Installed/ { print package " " $2 }'
Interesting. Did you ever use the certbot-auto or letsencrypt-auto
installers? This looks kind of like you've got a mismatched version of
one of the certbot libs lying around somewhere.
Can you upload the output of `python -v /usr/bin/certbot` for me? It's
going to be a large block of output, so you should probably put it in an
attachment.
Sincerely,
--
Harlan Lieberman-Berg
~hlieberman
Bug#858802: [Letsencrypt-devel] Bug#858802: AttributeError: 'module' object has no attribute 'DependencyError'
Patrick Lam <prof@gmail.com> writes: > I get a similar error on an upgraded stretch box: That's perplexing. I just ran an upgrade from jessie to stretch on a clean box, installed certbot -- works fine. I can't replicate this at all. What architecture are you running on? > The output of the command is empty. My guess is you're missing apt-rdepends. Can you install it and rerun the command please? Thanks, -- Harlan Lieberman-Berg ~hlieberman
Bug#858802: [Letsencrypt-devel] Bug#858802: AttributeError: 'module' object has no attribute '_init_cffi_1_0_external_module'
package certbot
tag 858802 +unreproducible +moreinfo
thanks
Tom Maneiro <tom...@tsdx.net.ve> writes:
> Trying to run certbot on a fresh install on my Stretch box leads me to the
> following stackdump:
Hi Tom,
Interesting. I've tried replicating this on a clean Stretch box, but I
don't get this error at all. A couple of questions for you:
1. Is this a fresh install of Stretch, or an upgrade?
2. Can you attach the output of this command? (You may need to install
apt-rdepends if you don't already have it installed.)
apt-cache policy $(apt-rdepends -p certbot 2>| /dev/null|awk '/Depends/ {print
$2}'|sort -u)|awk '/^[^ ]/ { package=$0 } / Installed/ { print package " " $2
}'
Sincerely,
--
Harlan Lieberman-Berg
~hlieberman
Bug#856625: Accidentally duplicated work
Brian May <b...@debian.org> writes: > Maybe this is as a result of a rebase - a rebase won't preserve merge > commits. If you type in "git-dpm status" you can clearly see it is not > happy. Yeah, it's probably because of the rebase. There was definitely a merge commit from upstream/2.3 when I was ready to commit things. I did the rebase afterwards, so it probably got wiped out. SOrry about that. > So, unfortunately, I am inclined to remmend reverting all changes on the > master branch since debian/2.1-3 for now. If you want, I can do > this. Makes sense. Sorry about that! -- Harlan Lieberman-Berg ~hlieberman
Bug#856625: Accidentally duplicated work
Hi Brian, I was following #856625 and accidentally duplicated some work of yours. I saw that the RC bug was fixed in the latest upstream release, so I packaged 2.3 and shoved it into the git before I saw you had started working on cherry-picking the patch in. I've rebased my work and pushed it up as UNRELEASED, just in case it is helpful for the future. The changes are a bit more aggressive -- switching to use upstream's new test methodology -- so I'm not sure if you want to include it in the unblock request. Either way, I'm not going to upload it since I don't want to mess up what you're doing with the unblock. Sorry for accidentally putting my foot into your work! Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#856698: Dropping severity, tagging
tag 856698 +moreinfo severity 856698 important thanks Dropping the severity down; this is most likely a problem which affects only people with a very large number of certs. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#856698: More Information Needed
--- Begin Message --- What is the command that is running when certbot consumes a lot of memory? Can you provide the contents of /etc/cron.d/certbot, and /var/log/letsencrypt.log from a run where certbot consumed a lot of memory? If you're using the Nginx or Apache configurators, can you provide your Nginx or Apache configs? ___ Letsencrypt-devel mailing list letsencrypt-de...@lists.alioth.debian.org https://lists.alioth.debian.org/mailman/listinfo/letsencrypt-devel --- End Message --- -- Harlan Lieberman-Berg ~hlieberman
Bug#851619: new upstream release fixes a bag of CVEs
package ansible tag 851619 -security -upstream severity 851619 wishlist retitle 851619 New ansible upstream version thanks Toni Mueller <t...@debian.org> writes: > there is a new Ansible release, 2.2.1, which was published on 2017-01-11 > on releases.ansible.com, which fixes a bag of security holes, for which > CVEs should already exist. Please take a look at Hi Toni! Happy to report that these have already been fixed through cherry-picks over the last five days or so. 2.2.1 has no security fixes not present in 2.2.0.0-4. We'll probably merge in 2.2.1 in the next couple of days to get the other bugfixes that are in there. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#850846: Additional patches required; reopen
found 850846 2.2.0.0-2 reopen 850846 thanks Ansible had to release 2.2.1.0-0.4-rc4 with more security fixes. Seems the patch from earlier missed a couple of corner cases. I'll need to update, but also shouldn't be doing a release at 0200. Will get to it ASAP tomorrow. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#846658: Acknowledgement (rpi: rpl causes crashes in unrelated software when using pkg_resources)
reassign 846658 rpl thanks Whoops, somehow submitted this to the wrong package. CC'ing you, Kevin, since the initial bugmail went to the unknown-package list. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#846658: rpi: rpl causes crashes in unrelated software when using pkg_resources
Package: rpi Severity: critical Version: 1.5.5-1 Dear Maintainer, The .egg-info shipped with rpl 1.5.5-1 contains an invalid unicode byte in the author field that causes pkg_resources to crash on load. I've attached a copy of the crash that results. Sincerely, -- Harlan Lieberman-Berg ~hlieberman crash.log Description: Binary data
Bug#844233: Fixed upstream
tag 844233 -upstream, +fixed-upstream thanks According to the maintainer, this has been fixed in the 1.7.0 release. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#844944: [Letsencrypt-devel] Bug#844944: python-acme: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
tag 844944 +upstream forwarded 844944 https://github.com/certbot/certbot/issues/3817 thanks This looks related to the openssl version bump. Sending upstream for them to take a look. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#834833: marked as done (javassist: FTBFS too much often (failing tests))
On September 2, 2016 7:27:11 PM EDT, ow...@bugs.debian.org wrote: >Your message dated Fri, 02 Sep 2016 23:25:14 + >with message-id <e1bfxpi-00019n...@franck.debian.org> >and subject line Bug#834833: fixed in python-certbot 0.8.1-3 >has caused the Debian Bug report #834833, >regarding javassist: FTBFS too much often (failing tests) >to be marked as done. > >This means that you claim that the problem has been dealt with. >If this is not the case it is now your responsibility to reopen the >Bug report if necessary, and/or fix the problem forthwith. > >(NB: If you are a system administrator and have no idea what this >message is talking about, this may indicate a serious mail system >misconfiguration somewhere. Please contact ow...@bugs.debian.org >immediately.) reopen 834833 notfixed 834833 0.8.1-3 thanks Whoops, looks like I got the bug number wrong. Sorry about that. -- Harlan Lieberman-Berg ~hlieberman
Bug#829275: Ubuntu
severity 829275 normal thanks After a conversation with the reporter, we believe this bug is only present in certain versions of Ubuntu -- potentially as a result of the (Debian experimental) 2.x series of python-mock. Further testing is required; will coordinate with the reporter and our counterparts downstream. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#827925: python-cryptography: missing dependency on python-cffi
Package: python-cryptography Version: 1.3.4-1 Severity: grave Justification: renders package unusable Hello, The latest build of python-cryptography is missing a Depends on python-cffi which holds the .egg-info. As a result, setuptools is unable to determine that python-cffi-backend is actually installed, and produces errors. Sincerely, -- Harlan Lieberman-Berg ~hlieberman -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-cryptography depends on: ii libc62.22-11 ii libssl1.0.2 1.0.2h-1 ii python 2.7.11-2 pn python-cffi-backend-api-max pn python-cffi-backend-api-min ii python-enum341.1.5-1 ii python-idna 2.1-1 ii python-ipaddress 1.0.16-1 ii python-pyasn10.1.9-1 ii python-setuptools20.10.1-1 ii python-six 1.10.0-3 pn python:any python-cryptography recommends no packages. Versions of packages python-cryptography suggests: pn python-cryptography-doc pn python-cryptography-vectors -- no debconf information
Bug#820721: #820721 - won't install
block 820721 by 820569 block 818667 by 820569 block 818696 by 820569 thanks Hi James, Jan, Thanks for your report. Right now, Let's Encrypt in sid is broken due to a partial upload of the newer version of Let's Encrypt. Unfortunately, the versions of python-cryptography and python-openssl currently in sid cause all programs depending on both of them to FTBFS. Jan, your problem seems unrelated; it seems like you're trying to install the jessie-backports package from backports, but trying to pull its dependencies from jessie itself. Maybe try installing with aptitude and see if it can resolve the dependencies better? (Or, perhaps, apt-get install -t jessie-backports letsencrypt?) Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#819676: (no subject)
Uploaded -2 to unstable with both the patches applied. Thanks for the report, Salvatore, and awesome catch, Evgeni! Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#818667: [Letsencrypt-devel] Bug#818667: Fails to build twice - clean does not clean enough
clone 818667 -1 reassign -1 python-letsencrypt-apache tags 818667 -1 +patch +confirmed thanks Ben Hutchings <b...@decadent.org.uk> writes: > The clean rule doesn't remove .pyc files, the .pybuild directory, or > files under letsencrypt.egg-info that are modified during the build. > So running 'dpkg-buildpackage -uc -us' twice fails the second time. Hi Ben, Good catch. Looks like this one will affect python-letsencrypt-apache too, because we used the same construction there. Will make sure this gets fixed in the next release. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#803320: TestGoldenFiles fails with Go 1.5
found 803320 0.0~git20150610-2 tags 803320 +confirmed forwarded 803320 https://github.com/jacobsa/ogletest/issues/28 thanks Confirmed and pre-existing upstream bug referenced. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#799454: golang-git2go: FTBFS: could not determine kind of name for C.GIT_CHECKOUT_SAFE_CREATE
tags 799454 +confirmed forwarded 799454 https://github.com/libgit2/git2go/issues/281 thanks Per upstream, git2go master branch is not safe to track unless you are also tracking libgit2 master. This package will need to be downgraded to the code on the upstream v23 branch, and will likely not receive updates from upstream. (Last commit activity on the v23 branch was the end of August '15). Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#809131: [Letsencrypt-devel] Bug#809131: python-acme: FTBFS: No local packages or download links found for urllib3==1.12
> Searching for urllib3==1.12 This should only happen in the condition that urllib3 isn't installed in the system Python paths; it is a dependency of python-requests, which is a dependency of python-acme. Can you please upload the complete build log, including dependency calculation and installation? Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#809131: [Letsencrypt-devel] Bug#809131: python-acme: FTBFS: No local packages or download links found for urllib3==1.12
Chris Lamb <la...@debian.org> writes: > This is actually #809031, which has now been fixed. I am therefore closing > this bug in bcc. Whoops, there we go. Sorry about that; should have checked python-requests. >> Can you please upload the complete build log > > Was one not attached, out of interest? :) dpkg-buildpackage was, but not the actual dependency resolution that you get out of pbuilder or sbuilder or whatever is calling d-bp. Unless you're building it directly, of course, in which case... Thanks for your help, lamby. I know the version in testing right now fails reproducability; if the version in unstable does when it migrates, I'll file the appropriate bugs upstream to get that fixed. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#808361: [Letsencrypt-devel] Bug#808361: FTBFS due to too loose build-depends
Tags: +confirmed Yeah, we were worried about something like this happening. Alright, so, we're going to have to solve this with a larger hammer. Tomorrow I'll convert python-letsencrypt and python-letsencrypt-apache to use a control.in file and to dynamically generate the dependency based on the current version being built. We'll have to use a hook to make sure that file gets run before build -- probably will use gitpkg's prebuild-target functionality. -- Harlan Lieberman-Berg ~hlieberman
Bug#805207: (no subject)
Control: tags -1 +fixed +pending I've prepared a team upload for this package that resolves this issue. It should be picked up by a team DD for upload out of PET soon. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#799628: python-cryptography: python-cffi is not properly pulled in as a dependency
Severity: serious Package: python-cryptography Version: 1.2.1-1 When installing python-cryptography, python-cffi-backend can be installed without python-cffi being installed. As a result, python packages that do their own dependency resolution will believe that python-cffi is not installed, even though the backend package is. -- Harlan Lieberman-Berg ~hlieberman
Bug#788967: xul-ext-gnome-keyring: Incompatible with iceweasel 38.0.1
Package: xul-ext-gnome-keyring Version: 0.6.11-3 Severity: grave Justification: renders package unusable The extension appears disabled in about:addons, with an incompatibility warning. There doesn't appear to be any more information provided. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages xul-ext-gnome-keyring depends on: ii iceweasel 38.0.1-5 ii libc6 2.19-18 ii libgcc11:5.1.1-9 ii libglib2.0-0 2.44.1-1 ii libgnome-keyring0 3.12.0-1+b1 ii libnspr4 2:4.10.8-2 ii libstdc++6 5.1.1-9 xul-ext-gnome-keyring recommends no packages. xul-ext-gnome-keyring suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759129: nanomsg tests fail on sparc
Hello mentors, porters, I'm having some trouble debugging why the nanomsg tests are failing - reliably, at least - on sparc. Because of the way the test suite works, I don't end up getting a lot of information about why the failure occurs, other than just a general bus error. I don't have access to the sparc porterboxes, or any real experience with sparc itself, so debugging is difficult for me. Time to send up red flares to see if any of you can give me a hand. The FTBFS on sparc is holding nanomsg out of testing (#759129), and with the freeze approaching, I'm worried it won't make it in before the freeze. Please feel free to reach out to me by IRC (hlieberman on OFTC, Freenode) if you want more real-time conversation. Thanks, everyone. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#759129: nanomsg tests fail on sparc
On Thu, Oct 23, 2014 at 2:03 PM, Jakub Wilk jw...@debian.org wrote: I'll try to reproduce the FTBFS on a porterbox later today. Awesome. Let me know if there's anything I can do to help. Well, not quite. Sparc is not a release architecture. And even if it was, this package has never build on sparc, so the missing build wouldn't stop testing migration. Oh, that's news to me. In that case, I will correct the priority. It still needs to be solved, though, and I appreciate your taking a look at it. ...which says something about FTBFS on i386. Either the bug should be closed, or the subject should be corrected to reflect reality. Yeah, the subject is dated, which I will correct ASAP. Thanks, Jakub! Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#736066: Allow encfs into jessie?
On Thu, 2014-09-11 at 19:33 +0200, Eduard Bloch wrote: I though Jan has just described one. For example, taking a 10 year old CD with backups from your safe and trying to get the data back. Another option would be to take the same approach that TrueCrypt did under (potentially) the same circumstances, and allow encfs into jessie - but only for read-only containers. That way, people can recover their data easily, but there's no risk of perpetuating a completely broken encryption layer. That'd be the best of both worlds, in my opinion. -- Harlan Lieberman-Berg ~hlieberman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759129:
Control: reopen -1 Control: tag -1 +upstream Control: thanks It seems that the test suite failures are intermittent, and that the test suite itself is indicating of some fairly reliable build failures across a few arches. After talking to upstream, I'm going to open tickets there to track these FTBFS'. Sincerely, -- Harlan Lieberman-Berg ~hlieberman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756350:
tags 756350 + confirmed patch thanks After a lot of debugging involving all sorts of pain and suffering and ignoring valgrind much to my detriment, olasd and I managed to isolate this to a bug in the XS code. A patch will be sent upstream and is currently applied in git. Unfortunately, there is still an error (I believe a separate one) with the threads test failing intermittently due to a mishandling of read() in the underlying nanomsg library, so I can't do a release to correct this issue yet. I will open bugs in Debian and upstream to track that issue as well. Sorry for the delay on the fix; this one was wy over my head. Sincerely, -- Harlan Lieberman-Berg ~hlieberman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759129: nanomsg ftbfs in current unstable (i386, and other architectures)
On Sun, 24 Aug 2014 18:34:17 +0200 Matthias Klose d...@debian.org wrote: PASS: tests/iovec ./test-driver: line 107: 14170 Aborted $@ $log_file 21 FAIL: tests/msg PASS: tests/inproc_shutdown Yeah, unfortunately, upstream's test suite is really buggy. I've already had to disable one of the tests because it has a really severe race condition in it that causes it to FTBFS about 50% of the time. It doesn't surprise me that there are transient failures in some of the other tests. That one I haven't seen, but. As a temporary solution, I'll disable this problematic test. If we still see problems in other places, we'll have to disable the tests altogether. It's not something that I particularly like doing, but if the problems with the test suite run that deep, I don't see much of a choice. Sincerely, -- Harlan Lieberman-Berg ~hlieberman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759129: nanomsg ftbfs in current unstable (i386, and other architectures)
On Mon, 2014-08-25 at 01:09 +0200, Matthias Klose wrote: then it's better to run these but ignore the test results (or just ignore the test failures of these which don't succeed). Definitely. I'll set that up if we still have more problems. I just submitted -2 to solve this issue and pushed the new code up to collab-maint, if you want to take a try at rebuilding. Sincerely, -- Harlan Lieberman-Berg ~hlieberman -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758558:
forwarded 758558 https://issues.apache.org/jira/browse/COUCHDB-2296 thanks The upstream devs say that the file will be removed in the 2.0 release of CouchDB, but that they are trying to contact the author to clarify the terms for us. Sincerely, -- Harlan Lieberman-Berg ~hlieberman
Bug#758558: Includes file with unclear license
Package: couchdb Version: 1.2.0-5 Severity: serious Tags: upstream The file share/www/script/base64.js is licensed under the terms: This library is free. You can redistribute it and/or modify it. Though it is clear that upstream's intent was to open source this file to some extent, this license is too vague to qualify for DFSG standards and should be removed or replaced. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
