Bug#911514: davmail: fails to install: wrong update-rc.d usage
On 2018-10-30 09:52, Alexandre Rossi wrote: > Hi Geert, > >> I've prepared updates for the davmail backport and its libhtmlcleaner >> dependency : >> https://sml.zincube.net/~niol/tmp/ >> >> Those are awaiting sponsorship (the process for granting me upload >> rights also to backports is ongoing). > > Granting me upload rights to the backports archive does not seem to > move forward. If you have some time to sponsor those uploads, please > go on. building the libhtmlcleaner-java backport in stretch fails: [INFO] Building HtmlCleaner 2.21 [INFO] [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ htmlcleaner --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /build/libhtmlcleaner-java-2.21/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ htmlcleaner --- [INFO] Nothing to compile - all classes are up to date [INFO] [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ htmlcleaner --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 64 resources [INFO] [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ htmlcleaner --- [INFO] Nothing to compile - all classes are up to date [INFO] [INFO] --- maven-surefire-plugin:2.17:test (default-test) @ htmlcleaner --- [INFO] Surefire report directory: /build/libhtmlcleaner-java-2.21/target/surefire-reports --- T E S T S --- Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 4.729 s [INFO] Finished at: 2018-12-01T07:49:40+00:00 [INFO] Final Memory: 12M/365M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project htmlcleaner: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: The forked VM terminated without properly saying goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd /build/libhtmlcleaner-java-2.21 && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -jar /build/libhtmlcleaner-java-2.21/target/surefire/surefirebooter8827901967415424500.jar /build/libhtmlcleaner-java-2.21/target/surefire/surefire969640660163927236tmp /build/libhtmlcleaner-java-2.21/target/surefire/surefire_02387711883238815967tmp [ERROR] -> [Help 1] You may also want to update the devmail backport to the version in testing. Andreas
Bug#915150: gzip FTBFS: ../../lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."
Control: clone -1 -2 Control: reassign -2 src:m4 On Sat, Dec 01, 2018 at 08:07:23AM +0100, Helmut Grohne wrote: > gzip fails to build from source in unstable (since the glibc upgrade to > 2.28): m4 has another copy of the bug. Helmut
Bug#915125: libasound2-data: Stretch Regression: alsa.conf.d not provided and breaks crouton audio build
* Mike Fedyk [2018-11-30 12:44 -0600]: > Package: libasound2-data > Version: 1.1.7-1 > Severity: normal > > Hi, > > I can install crouton with audio with stretch by running: > > $ sudo bash ~/Downloads/crouton -r stretch -t audio > > But it fails when I try with testing/buster: > > $ sudo bash ~/Downloads/crouton -r buster -t audio > > Looking into it, it fails on this line: > > https://github.com/dnschneid/crouton/blob/master/targets/audio#L200 > which writes to /usr/share/alsa/alsa.conf.d/10-cras.conf, but that > directory doesn't exist. What tells: $ dpkg -l | egrep "(libasou|alsa)" ? Elimar -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche signature.asc Description: PGP signature
Bug#915150: gzip FTBFS: ../../lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."
Source: gzip Version: 1.9-2.1 Severity: serious Tags: ftbfs User: helm...@debian.org Usertags: rebootstrap Control: clone -1 -2 Control: reassign -2 gnulib Control: found -2 gnulib/20140202+stable-3 Control: retitle -2 gnulib does not work with glibc/2.28 Control: affects -2 + src:lbzip2 gzip fails to build from source in unstable (since the glibc upgrade to 2.28): | CC fseeko.o | ../../lib/fseeko.c: In function 'rpl_fseeko': | ../../lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." |#error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib." | ^ | make[4]: *** [Makefile:1775: fseeko.o] Error 1 | make[4]: Leaving directory '/<>/builddir/lib' | make[3]: *** [Makefile:1580: all] Error 2 | make[3]: Leaving directory '/<>/builddir/lib' | make[2]: *** [Makefile:1746: all-recursive] Error 1 | make[2]: Leaving directory '/<>/builddir' | make[1]: *** [Makefile:1527: all] Error 2 | make[1]: Leaving directory '/<>/builddir' | make: *** [debian/rules:96: build-stamp] Error 2 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 gnulib likes to use this construct to detect glibc: | #if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */ Unfortunately, _IO_ftrylockfile got removed from glibc/2.28 and __GNU_LIBRARY__ is 6, so glibc is not a GNU libc. gnulib has a history of breaking packages frequently. What makes matters worse is that gnulib gets embedded rather than used like any other component. So fixing this bug in gnulib does not fix gzip. I therefore cloned a separate instance as it still breaks e.g. lbzip2. Helmut
Bug#914814: spades: FTBFS with jemalloc/experimental
Control: tags -1 help Hi Adam, On Tue, Nov 27, 2018 at 05:15:48PM +0100, Adam Borowski wrote: > I'm afraid that your package fails to build with jemalloc 5.1.0-1 (currently > in experimental). Transitioning to jemalloc 5 is long overdue, and some > packages currently carry private copies of jemalloc which does not make the > security and release teams happy. Thanks for working on jemalloc update and checking its rdepends. > Your package is the only RB-Dep that fails to build. Spades is originally carrying a code copy. I'm afraid upstream will give the advise to use the code they are shipping which we want to avoid. Could you possibly provide some patch which I could use and provide to upstream once tested? Unfortunately I have no idea about jemalloc. Thanks again Andreas. -- http://fam-tille.de
Bug#915149: figtree: autopkgtest always fails
Source: figtree Version: 1.4.4-1 User: debian...@lists.debian.org Usertags: issue Hi Maintainer The figtree package includes an autopkgtest, but it seems to have always failed [1] with the following error: autopkgtest [18:35:07]: test run-unit-test: [--- /usr/bin/figtree: 3: /usr/bin/figtree: java: not found autopkgtest [18:35:07]: test run-unit-test: ---] autopkgtest [18:35:07]: test run-unit-test: - - - - - - - - - - results - - - - - - - - - - run-unit-testFAIL non-zero exit status 127 To me, it seems that the figtree package itself (and not its test dependencies) is missing a dependency on at least default-jre. Regards Graham [1] https://ci.debian.net/packages/f/figtree/testing/amd64/
Bug#915148: cmake: regression in ros-ros-comm build
control: affects -1 ros-ros-comm control: notfound -1 3.12.3-3 fixing tags. G.
Bug#914688: Default defines discrepancy
Hello, >I don't know how I can help here. Performous only fails on powerpc >architectures which looks like a Boost bug to me. This only happened >recently when we switched to 1.67, so maybe forward upstream and let's >find out what the upstream developers think about that? the boost patch is now part of the archive, and upstream codebase.I requested a give-back of the package, so it should build with no source changes now. G.
Bug#911492: [Debian-med-packaging] Bug#911492: htslib breaks python-pysam autopkgtest
Control: severity -1 serious Python-pysam in unstable is passing its autopkgtests against htslib 1.9, so all that might be needed here is for libhts2 to declare the following breaks (or similar): Breaks: python-pysam (<< 0.15~), python3-pysam (<< 0.15~)
Bug#915079: Potential Fix for Bug
I created a new install of Debian testing in a VM on Virtualbox. I
installed the Gnome desktop and Audacity, and I installed the source
package for alsa-lib (1.1.7-1).
I then configure the build tools and applied the patch from the ALSA
project against the source and built the binary packages. After
installation, I opened pavucontrol and Audacity and confirmed that
recording and playback options had Pulse available, and Audacity
displayed in pavucontrol with the ALSA plugin as it had in 1.1.6 and prior.
I recorded audio in Audacity and played it back successfully.
The patch I applied was this:
diff --git a/src/pcm/interval_inline.h b/src/pcm/interval_inline.h
index a68e292..d9a30b2 100644 (file)
--- a/src/pcm/interval_inline.h
+++ b/src/pcm/interval_inline.h
@@ -51,12 +51,14 @@ INTERVAL_INLINE int snd_interval_single(const
snd_interval_t *i)
{
assert(!snd_interval_empty(i));
return (i->min == i->max ||
- (i->min + 1 == i->max && i->openmax));
+ (i->min + 1 == i->max && (i->openmin || i->openmax)));
}
INTERVAL_INLINE int snd_interval_value(const snd_interval_t *i)
{
assert(snd_interval_single(i));
+ if (i->openmin && !i->openmax)
+ return i->max;
return i->min;
}
Rob Gibson
On Fri, 30 Nov 2018 22:05:15 -0500 Rob Gibson wrote:
> I have rolled back to 1.1.6-1 on my install of testing, but I would
> prefer to upgrade.
>
> A colleague running Arch filed a bug report over there that appears to
> now be fixed in 1.1.7.
>
> https://bugs.archlinux.org/task/60591 - Original Issue
> https://bugs.archlinux.org/task/60579 - Detailed Issue Report
> http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=b420056604f06117c967b65d43d01536c5ffcbc9
> - Referenced patch from upstream repository
>
> I'm not a developer, and I've not attempted to participate in Debian
> package development, but I am willing to try, unless someone else is
> able to perform this testing with more experience than I.
>
> Rob Gibson
>
>
Bug#915088: multipath-tools: installing multipath-tools will force dracut to be removed while it shouldn't.
Hi Olivier, I am not denying any of what you have said below. Dracut may be a great tool. But unfortunately, it does not have the uptake in Debian, that initramfs-tools has. Just look at the popcon stats. multipath-tools needs tight integration with the plumbing layer to ensure you have a stackable storage. For Debian, the work so far has been done integrating it with initramfs-tools. I am not opposed to adding dracut as an option. It is just that I have never worked on it. Nor have any users/developers ever reported about its integration here. If dracut can serve as a drop-in replacement, I don't have any problem adding it as an OR dependency in `sg3-utils-udev` package. On Fri, 2018-11-30 at 16:13 +, LAHAYE Olivier wrote: > Dracut is the only tool to create initramfs on many distros and it > works fine with multipath so far. Dracut is to initramfs-tools what > systemd is to basic initscripts. > Dracut is modular and event driven while initramfs-tools is > monolithic and linear static. > > If you look at /usr/lib/dracut/modules.d you'll notice that a module > already exists for multipathd. (/usr/lib/dracut/modules.d/90multipath > and /usr/lib/dracut/modules.d/90multipath-hostonly) > > man dracut > man dracut.modules > man dracut.cmdline > > See also the module-setup.sh in both 90multipath and 90multipath- > hostonly modules > > Dracut is really a wonderful piece of code that is really easy to > understand and that can create really powerful ramfs images. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#840388: fusedav non-functional
Carsten Leonhardt wrote: > Control: severity -1 grave > > This software appears to be non-functional. A tcpdump confirms that no > network traffic between the client and the server is being generated. Fwiw, I have filed many bugfixes against this package years ago but the maintainer is not responsive. All my fixes are at, and I still use it daily (: git clone https://bogomips.org/fusedav.git AFAIK, there was one unresolved corner-case with readdirplus support I never got around to fixing[1], but it works for common cases with "ls" [1] https://marc.info/?i=20140609094046.ga1...@dcvr.yhbt.net
Bug#840388: fusedav non-functional
Eric Wong wrote: > AFAIK, there was one unresolved corner-case with readdirplus > support I never got around to fixing[1], but it works for common > cases with "ls" [1] Sorry, correct URL is: https://marc.info/?i=CAJfpeguWVhpPkUoTxGrW=kc43rrksjtwoq0ysczl0_oc9jl...@mail.gmail.com for Miklos's response to my attempted patch.
Bug#915079: Potential Fix for Bug
I have rolled back to 1.1.6-1 on my install of testing, but I would prefer to upgrade. A colleague running Arch filed a bug report over there that appears to now be fixed in 1.1.7. https://bugs.archlinux.org/task/60591 - Original Issue https://bugs.archlinux.org/task/60579 - Detailed Issue Report http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=b420056604f06117c967b65d43d01536c5ffcbc9 - Referenced patch from upstream repository I'm not a developer, and I've not attempted to participate in Debian package development, but I am willing to try, unless someone else is able to perform this testing with more experience than I. Rob Gibson
Bug#915147: strongswan-charon: apparmor profile should allow writing to /etc/resolv.conf
Package: strongswan-charon
Version: 5.7.1-1
Severity: important
Tags: patch
Dear Maintainer,
If the VPN one is connecting to wants to add additional DNS servers, charon
needs
write access to /etc/resolv.conf. Otherwise we get an error like the following:
# ipsec up XXX
[..]
IKE_SA XXX{X} established between XXX...YYY
adding DNS server failed
adding DNS server failed
handling INTERNAL_IP4_DNS attribute failed
installing new virtual IP XXX
[..]
And in dmesg logs:
audit: type=1400 audit(NNN): apparmor="DENIED" operation="open"
profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ comm="charon"
requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
audit: type=1400 audit(NNN): apparmor="DENIED" operation="unlink"
profile="/usr/lib/ipsec/charon" name="/etc/resolv.conf" pid=ZZZ comm="charon"
requested_mask="d" denied_mask="d" fsuid=0 ouid=0
Note that the "#include " that already exists in
charon's profile, is only for *read* access to /etc/resolv.conf, but charon
really does need write access.
A patch that worked for me was:
--- /etc/apparmor.d/usr.lib.ipsec.charon2018-11-30 19:02:12.585715570
-0800
+++ /etc/apparmor.d/usr.lib.ipsec.charon2018-11-30 18:50:39.850426475
-0800
@@ -68,6 +68,8 @@
/var/lib/strongswan/* r,
+ /etc/resolv.conf w,
+
# Site-specific additions and overrides. See local/README for details.
#include
}
X
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (500, 'stable'), (300, 'unstable'), (100, 'experimental'),
(1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages strongswan-charon depends on:
ii debconf [debconf-2.0] 1.5.69
ii iproute2 4.18.0-2
ii libc6 2.27-8
pn libstrongswan
pn strongswan-libcharon
pn strongswan-starter
strongswan-charon recommends no packages.
strongswan-charon suggests no packages.
Bug#737921: WE HAVE REAL PROVIDER OF BG, SBLC, MT103, POF, SKR, DISCOUNTING AND LOANS FOR YOUR PROJECTS.
Sir, We Lloyds Bank Uk provide Loans,BG,SBLC,MTN,POF,LC,SKR Discounting,Project Funding,Letter of credit, and lots more for client all over the world. Equally,we are ready to work with Brokers and financial consultants/consulting firms in their respective countries. we are equally ready to pay commission to those Brokers and financial consultants/consulting firms. For more information/detail contact us via E-mail:evans.co...@lloydsbankplc-london.co.uk Awaiting for your response. Best Regards. Advert Team. Lloyds Bank Plc. 25 Gresham Street, London EC2V 7HN United Kingdom.
Bug#915146: ioprocess: FTBFS with ld --as-needed
Package: ioprocess Version: 0.15.1-3 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu disco ubuntu-patch Dear Maintainer, ioprocess fails to build from source when the ld linker is configured to use the --as-needed option, which requires that libraries be in a certain order. This is the default in Ubuntu. While this isn't strictly necessary in Debian, it puts the libraries in the right place and will let us avoid having to maintain a delta. In Ubuntu, the attached patch was applied to achieve the following: * Merge from Debian unstable. Remaining changes: - Use LDADD instead of LDFLAGS to fix FTBFS with ld --as-needed. Thanks for considering the patch. Logan -- System Information: Debian Release: buster/sid APT prefers cosmic-updates APT policy: (500, 'cosmic-updates'), (500, 'cosmic-security'), (500, 'cosmic'), (400, 'cosmic-proposed'), (100, 'cosmic-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-11-generic (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) LSM: AppArmor: enabled diff -Nru ioprocess-0.15.1/debian/patches/ld-as-needed.patch ioprocess-0.15.1/debian/patches/ld-as-needed.patch --- ioprocess-0.15.1/debian/patches/ld-as-needed.patch 1969-12-31 19:00:00.0 -0500 +++ ioprocess-0.15.1/debian/patches/ld-as-needed.patch 2016-01-31 23:54:06.0 -0500 @@ -0,0 +1,17 @@ +Description: use LDADD instead of LDFLAGS to fix FTBFS with ld --as-needed +Author: Logan Rosen +Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1304958 +Last-Update: 2016-02-05 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/src/Makefile.am b/src/Makefile.am +@@ -14,7 +14,7 @@ + $(IOPROCESS_CFLAGS) \ + $(AM_CFLAGS) \ + $(NULL) +-ioprocess_LDFLAGS = $(GLIB2_LIBS) \ ++ioprocess_LDADD = $(GLIB2_LIBS) \ + $(GTHREAD2_LIBS) \ + $(YAJL_LIBS) \ + $(AM_LDFLAGS) \ diff -Nru ioprocess-0.15.1/debian/patches/series ioprocess-0.15.1/debian/patches/series --- ioprocess-0.15.1/debian/patches/series 2016-01-18 10:37:22.0 -0500 +++ ioprocess-0.15.1/debian/patches/series 2018-07-11 12:57:55.0 -0400 @@ -1 +1,2 @@ paths.patch +ld-as-needed.patch
Bug#914495: linux-image-4.18.0-3-amd64: The system hangs even before the screen font gets smaller. There's just a black screen.
Package: src:linux Version: 4.18.20-2 Followup-For: Bug #914495 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Booting into linux-image-4.18.0-3-amd64. * What exactly did you do (or not do) that was effective (or ineffective)? I crashed the system by switching off the power and then booted into linux-image-4.18.0-2-amd64. * What was the outcome of this action? It works as before. * What outcome did you expect instead? I expected it to work. *** End of the template - remove these template lines *** -- Package-specific info: ** Kernel log: boot messages should be attached I'll attach /var/log/kern.log if I can find out how to. -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages linux-image-4.18.0-3-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.132 ii kmod25-2 ii linux-base 4.5 Versions of packages linux-image-4.18.0-3-amd64 recommends: ii apparmor 2.13.1-3+b1 ii firmware-linux-free 3.4 ii irqbalance 1.5.0-0.1 Versions of packages linux-image-4.18.0-3-amd64 suggests: ii debian-kernel-handbook 1.0.19 ii grub-pc 2.02+dfsg1-8 pn linux-doc-4.18 Versions of packages linux-image-4.18.0-3-amd64 is related to: ii firmware-amd-graphics 20180825+dfsg-1 ii firmware-atheros 20180825+dfsg-1 pn firmware-bnx2 pn firmware-bnx2x pn firmware-brcm80211 pn firmware-cavium pn firmware-intel-sound pn firmware-intelwimax pn firmware-ipw2x00 pn firmware-ivtv ii firmware-iwlwifi 20180825+dfsg-1 pn firmware-libertas ii firmware-linux-nonfree20180825+dfsg-1 ii firmware-misc-nonfree 20180825+dfsg-1 pn firmware-myricom pn firmware-netxen pn firmware-qlogic ii firmware-realtek 20180825+dfsg-1 pn firmware-samsung pn firmware-siano pn firmware-ti-connectivity pn xen-hypervisor -- no debconf information
Bug#717563:
I managed to fix this (at least for the get_bugs case) but it required
changes
to python-debianbts package.
I have included two patches for feedback. There are some caveats:
* Other method calls need to be patched in reportbug/debbugs.py.
* pysimplesoap will use alternatve http transport libraries if httplib2 is
unavailable, and proxy support is unavailable for some of the other
transports such as urllib2.
* reportbug uses urllib2 over httplib2, and pysimplesoap uses httplib2 over
urllib2, but i don't think httplib2 is a dependency of reportbug -
therefore, that must changed also or pysimplesoap wont pick it up.
diff --git a/reportbug/checkversions.py b/reportbug/checkversions.py
index d94bf76..c37399d 100644
--- a/reportbug/checkversions.py
+++ b/reportbug/checkversions.py
@@ -84,7 +84,7 @@ def get_versions_available(package, timeout, dists=None,
http_proxy=None, arch='
# or to binary packages available on the current arch
url += '&a=source,all,' + arch
try:
-page = open_url(url)
+page = open_url(url, http_proxy, timeout)
except NoNetwork:
return {}
except urllib.error.HTTPError as x:
diff --git a/reportbug/debbugs.py b/reportbug/debbugs.py
index 92db224..c6bd6d0 100644
--- a/reportbug/debbugs.py
+++ b/reportbug/debbugs.py
@@ -1069,6 +1069,13 @@ def get_reports(package, timeout, system='debian',
mirrors=None, version=None,
pkg_filter = 'src'
else:
pkg_filter = 'package'
+if http_proxy:
+from urllib.parse import urlparse
+parsed_url = urlparse(http_proxy)
+# Probably ought to use more info for the proxy, if applicable.
+debianbts.set_soap_proxy(dict(proxy_host=parsed_url.hostname,
+ proxy_port=parsed_url.port))
+
bugs = debianbts.get_bugs(pkg_filter, package)
else:
bugs = list(map(int, package))
diff --git a/reportbug/urlutils.py b/reportbug/urlutils.py
index c16e48c..a3f2e20 100644
--- a/reportbug/urlutils.py
+++ b/reportbug/urlutils.py
@@ -146,6 +146,7 @@ def open_url(url, http_proxy=None, timeout=60):
proxies = urllib.request.getproxies()
if http_proxy:
proxies['http'] = http_proxy
+proxies['https'] = http_proxy
try:
page = urlopen(url, proxies, timeout)
debian-bts.patch
Description: Binary data
Bug#915144: Restrict Tar to at least 1.29b for `--verbatim-files-from`
Package: pristine-tar Version: 1.45 Severity: normal I was checking out the tarball on Debian/kFreeBSD and got the following error: ``` seamlik@debian:~/Documents/debian/android-platform-system-core$ pristine-tar checkout ../android-platform-system-core_8.1.0+r23.orig.tar.xz tar: unrecognized option '--verbatim-files-from' Try 'tar --help' or 'tar --usage' for more information. pristine-tar: command failed: tar cf /tmp/pristine-tar.nwyer_kTay/recreatetarball --owner 0 --group 0 --numeric-owner -C /tmp/pristine-tar.nwyer_kTay/workdir --no-recursion --mode 0644 --verbatim-files-from --files-from /tmp/pristine-tar.nwyer_kTay/manifest pristine-tar: failed to generate tarball ``` And on kFreeBSD Tar is only in 1.28 which does not support `--verbatime-files-from`. signature.asc Description: OpenPGP digital signature
Bug#911443: raspi3-firmware | Add board-specific firmware files for RPi 3B+ WiFi (!1)
Hi Matthias, > Matthias Luescher hat am 30. November 2018 um 22:20 > geschrieben: > > > Hi Stefan > > > Which RPi 3 variant do you use (B or B+)? > > Today I have tested on the Raspberry Pi 3 B with arm64. i want to play safe. Could you please check the Rev of your 3 B board? You can find it on the upside of the PCB below the GPIO pin header (e.g. i have Rev 1.2). > > I was able to reproduce it also with kernel 4.19.5. wlan0 remains absent > with this newer kernel version. > Based on 4.19.5 I reverted commit b1b8f45b3130dbd8704e5ea0d82b49b1d929498e > and then wlan0 was back. Btw the intention of this patch was to enable Wifi. Could you please provide a complete dmesg in case wlan0 is absent? > > > Could you please provide a reduced kernel config? > > Here is more information: > > Kernel configuration: > https://drive.google.com/open?id=1ZI3MeGB2fkYMsEjzGQYXUk2wqr0h9h7R Interesting SDHCI and BRCMFMAC are compiled as a module. Maybe this causes the issue. I tested today 4.20rc-1 with arm64/defconfig and wlan0 is always there. Could you please change your config to: CONFIG_MMC_SDHCI_IPROC=y and on the other side i will test your config. Regards Stefan > > linux-image-4.19.5-v8_4.19.5-v8-1_arm64.deb (wlan0 is absent): > https://drive.google.com/open?id=1QCNZcpxeeCBGNb0dsZBBZD9i2Y1kCeib > > dtb with b1b8f45b3130dbd8704e5ea0d82b49b1d929498e reverted (wlan0 is back): > https://drive.google.com/open?id=11O0c-StAUvV7IXFIs1UBlzeu-CTP3KVt > > > Is armhf (32 bit) affected, too? > > I think so - but I did not test it yet. > > Best regards > Matthias
Bug#604078: Project Email
Did you receive the project I sent you ?
Bug#915094: Additional information.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >Can you tell what version of the kernel you are using? 4.19.0-trunk-amd64. I guess that I am not getting any semblance of support with an experimental kernel. However, when I upgrade from 4.19.0-rc7 to 4.19.0-trunk, the problem is still there, so it does not look like a kernel problem. >How/when did you enable this feature? Just me poking around options in the man page. I assume that I can save some space with small files. >It looks like you were trying to upgrade some packages when you ran into this >issue. It happened to random processes. It happened to "mandb", "perl" and "chromium" most frequently. Sometimes it happens to very basic processes like "ls" or "rm" (happened once when I try to remove Chromium's cache folder). Also, if a process is stuck, the processes will be stuck again if I invoke that program again. -- "And in the naked light, I saw ten thousand people, maybe m\ ore. People talking without speaking, people hearing withou\ t listening. People writing songs that voices never shared,\ no one dared disturb the sound of silence." -BEGIN PGP SIGNATURE- Version: ProtonMail Comment: https://protonmail.com wsBcBAEBCAAQBQJcAdSQCRDYtWA5RV10HwAAi6QH/0wsTVCyYWSHzeegbkiz pKLva43dlXwvd62AbB2CYyzSdytUacGyvk4LOSvAg9FtD0PsK1eayTJ3cQgV VyIUc7zCLgWA9HXm36HiUoi8hTlkeqa+8Vy/AG0X4pTVIaZPLPyGiUu3yQyM PCyfGTv9so26v244RQ+FJNQVYdOtE6ajM//570HXHTmb4/GykmHMGIk1iwIH YDQa+4FlZFNPDo+Gi3Az2IKj+hDYQyZ+spJTs53GWuwu3W02lH3bno2HXYNJ ciP+jo+l/PIj+8zqIUL4ddUOrBWglj+fJGAVN3YVxs+iKz3VD+IFOFv29eHw t1NgJ3BV02yAjQNWWo+eOdQ= =HkKt -END PGP SIGNATURE- publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc Description: application/pgp-keys publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig Description: PGP signature
Bug#915142: Kicad does not install default plugins
Package: kicad Version: 5.0.1+dfsg1-3~bpo9+1 Severity: normal Dear Maintainer, Kicad is not installing default plugins that are included in original source package, e.g. eeschema/plugins/xsl_scripts/bom2csv.xsl -> /usr/lib/kicad/plugins/bom2csv.xsl. This is not the case with stable version 4.x. This way users do not have default BOM plugin, which is referred in many examples and tutorials. Additionally, some of the automated tools would also fail. Note: this report was initially generated from the inside docker container. ls -alh /usr/lib/kicad/_ _cvpcb.kiface _eeschema.kiface_gerbview.kiface _pcb_calculator.kiface _pcbnew.kiface _pl_editor.kiface root@9f514b0ac861:~# ls -alh /usr/lib/kicad/ total 49M drwxr-xr-x 2 root root 4.0K Nov 13 19:07 . drwxr-xr-x 1 root root 4.0K Dec 1 00:01 .. -rw-r--r-- 1 root root 8.7M Nov 11 17:54 _cvpcb.kiface -rw-r--r-- 1 root root 7.8M Nov 11 17:54 _eeschema.kiface -rw-r--r-- 1 root root 7.1M Nov 11 17:54 _gerbview.kiface -rw-r--r-- 1 root root 1.8M Nov 11 17:54 _pcb_calculator.kiface -rw-r--r-- 1 root root 21M Nov 11 17:54 _pcbnew.kiface -rw-r--r-- 1 root root 2.4M Nov 11 17:54 _pl_editor.kiface -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.93-linuxkit-aufs (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages kicad depends on: ii libc6 2.24-11+deb9u3 ii libcairo2 1.14.8-1 ii libcurl3 7.52.1-5+deb9u8 ii libfreeimage3 3.17.0+ds1-5 ii libfreetype6 2.6.3-3.2 ii libgcc1 1:6.3.0-18+deb9u1 ii libgl1-mesa-glx [libgl1] 13.0.6-1+b2 ii libglew2.02.0.0-3+b1 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libngspice0 29-1~bpo9+1 ii liboce-foundation10 0.17.2-2 ii liboce-modeling10 0.17.2-2 ii liboce-ocaf-lite100.17.2-2 ii liboce-ocaf10 0.17.2-2 ii liboce-visualization100.17.2-2 ii libpixman-1-0 0.34.0-1 ii libpython2.7 2.7.13-2+deb9u3 ii libssl1.1 1.1.0f-3+deb9u2 ii libstdc++66.3.0-18+deb9u1 ii libwxbase3.0-0v5 3.0.4+dfsg-4~bpo9+1 ii libwxgtk3.0-0v5 3.0.4+dfsg-4~bpo9+1 ii libx11-6 2:1.6.4-3+deb9u1 ii libxext6 2:1.3.3-1+b2 ii python2.7.13-2 ii python-wxgtk3.0 3.0.2.0+dfsg-4 Versions of packages kicad recommends: pn kicad-demos ii kicad-libraries 5.0.1+dfsg1-3~bpo9+1 pn xsltproc Versions of packages kicad suggests: pn extra-xdg-menus pn kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-doc-es | kicad-d pn kicad-packages3d -- Tomasz 'Zen' Napierala http://napierala.org JID: tomasz[@]napierala[.]org
Bug#910917: RFA: apache2 -- Apache HTTP Server
Hello everybody! I would like help on maintain apache2. I have some experience on packaging (python projects) but I want to participate on a more complicate package. I send request to join to the team. Could you please add me? Thanks! Regards! -- Arias Emmanuel http://eamanu.com Github/Gitlab; @eamanu Debian: @eamanu-guest
Bug#906977: parley: diff for NMU version 4:17.08.3-1.1
Control: tags 906977 + pending
Dear maintainer,
I've prepared an NMU for parley (versioned as 4:17.08.3-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
diff -Nru parley-17.08.3/debian/changelog parley-17.08.3/debian/changelog
--- parley-17.08.3/debian/changelog 2017-12-02 09:33:57.0 +0100
+++ parley-17.08.3/debian/changelog 2018-12-01 00:38:45.0 +0100
@@ -1,3 +1,12 @@
+parley (4:17.08.3-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "FTBFS in buster/sid ('QItemSelection' does not name a type)":
+add patch from upstream Git repo to fix build with Qt 5.11.
+(Closes: #906977)
+
+ -- gregor herrmann Sat, 01 Dec 2018 00:38:45 +0100
+
parley (4:17.08.3-1) unstable; urgency=medium
* Team upload.
diff -Nru parley-17.08.3/debian/patches/qt_5.11.patch parley-17.08.3/debian/patches/qt_5.11.patch
--- parley-17.08.3/debian/patches/qt_5.11.patch 1970-01-01 01:00:00.0 +0100
+++ parley-17.08.3/debian/patches/qt_5.11.patch 2018-12-01 00:38:28.0 +0100
@@ -0,0 +1,70 @@
+From f57328e2ba2074bd9e53794525984447d426c38b Mon Sep 17 00:00:00 2001
+From: Andreas Sturmlechner
+Date: Sat, 17 Mar 2018 20:18:04 +0100
+Subject: Fix build with Qt 5.11 (missing headers)
+
+Reviewers: #kde_edu, aacid
+
+Reviewed By: aacid
+
+Tags: #kde_edu
+
+Differential Revision: https://phabricator.kde.org/D11428
+---
+ src/dashboard/buttondelegate.cpp | 1 +
+ src/editor/latexwidget.h | 1 +
+ src/practice/multiplechoicemodewidget.cpp | 1 +
+ src/statistics/statisticsmainwindow.cpp | 1 +
+ 4 files changed, 4 insertions(+)
+
+diff --git a/src/dashboard/buttondelegate.cpp b/src/dashboard/buttondelegate.cpp
+index a99dcc3..315f069 100644
+--- a/src/dashboard/buttondelegate.cpp
b/src/dashboard/buttondelegate.cpp
+@@ -19,6 +19,7 @@
+ #include
+ #include
+ #include
++#include
+ #include
+ #include
+ #include
+diff --git a/src/editor/latexwidget.h b/src/editor/latexwidget.h
+index 0424e43..e3156b0 100644
+--- a/src/editor/latexwidget.h
b/src/editor/latexwidget.h
+@@ -16,6 +16,7 @@
+ #include "ui_latexwidget.h"
+
+ #include
++#include
+ #include
+
+ class QDataWidgetMapper;
+diff --git a/src/practice/multiplechoicemodewidget.cpp b/src/practice/multiplechoicemodewidget.cpp
+index a4eff53..67bd6b5 100644
+--- a/src/practice/multiplechoicemodewidget.cpp
b/src/practice/multiplechoicemodewidget.cpp
+@@ -18,6 +18,7 @@
+
+ #include "ui_practice_widget_multiplechoice.h"
+
++#include
+ #include
+ #include
+ #include
+diff --git a/src/statistics/statisticsmainwindow.cpp b/src/statistics/statisticsmainwindow.cpp
+index 834091c..fe59460 100644
+--- a/src/statistics/statisticsmainwindow.cpp
b/src/statistics/statisticsmainwindow.cpp
+@@ -16,6 +16,7 @@
+
+ #include "statisticsmainwindow.h"
+
++#include
+ #include
+
+ #include
+--
+cgit v0.11.2
+
diff -Nru parley-17.08.3/debian/patches/series parley-17.08.3/debian/patches/series
--- parley-17.08.3/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ parley-17.08.3/debian/patches/series 2018-12-01 00:38:28.0 +0100
@@ -0,0 +1 @@
+qt_5.11.patch
signature.asc
Description: Digital Signature
Bug#915141: RFS: rtags/2.21-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rtags" * Package name: rtags Version : 2.21-1 Upstream Author : Anders Bakken * URL : https://github.com/Andersbakken/rtags * License : GPL-3+ Section : devel It builds those binary packages: elpa-ac-rtags - auto-complete back-end for RTags elpa-company-rtags - company back-end for RTags elpa-flycheck-rtags - flycheck integration for RTags elpa-helm-rtags - helm interface for RTags elpa-ivy-rtags - ivy back-end for RTags elpa-rtags - emacs front-end for RTags rtags - C/C++ client/server indexer with integration for Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rtags Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rtags/rtags_2.21-1.dsc Changes since the last upload: * New upstream version 2.21 * rebase patches * rename rc and rdm binaries (Closes: #914805) Regards, Denis Danilov
Bug#906187: facter: diff for NMU version 3.11.0-1.1
Control: tags 906187 + patch
Control: tags 906187 + pending
Dear maintainer,
I've prepared an NMU for facter (versioned as 3.11.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog 2018-03-29 12:13:41.0 +0200
+++ facter-3.11.0/debian/changelog 2018-12-01 00:19:32.0 +0100
@@ -1,3 +1,12 @@
+facter (3.11.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix "missing Depends: libfacter3.11.0 (= ${binary:Version})":
+add the Depends, as suggested by Andreas Beckmann.
+(Closes: #906187)
+
+ -- gregor herrmann Sat, 01 Dec 2018 00:19:32 +0100
+
facter (3.11.0-1) unstable; urgency=medium
* New upstream release
diff -Nru facter-3.11.0/debian/control facter-3.11.0/debian/control
--- facter-3.11.0/debian/control 2018-03-29 12:13:41.0 +0200
+++ facter-3.11.0/debian/control 2018-12-01 00:16:40.0 +0100
@@ -72,7 +72,7 @@
Package: facter-dev
Architecture: any
Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, libfacter3.11.0 (= ${binary:Version})
Description: collect and display facts about the system -- development files
Facter is Puppet’s cross-platform system profiling library. It discovers and
reports per-node facts, which are collected by the Puppet agent and are made
signature.asc
Description: Digital Signature
Bug#914051: python-freecontact FTBFS with boost 1.67
Control: tags -1 help On Sun, Nov 18, 2018 at 10:42:22PM +0200, Adrian Bunk wrote: > /usr/bin/ld: cannot find -lboost_python-py27 It seems libboost_python-py*.so is not provided by libboost > 1.63 since these do not provide any libboost-python package any more. I have no idea how to work around this. Kind regards Andreas. -- http://fam-tille.de
Bug#915140: brightd: does not start on pinebook/arm64
Package: brightd Version: 0.4.1-2 Severity: normal brightd appears to fail to start with the default configuration on Pinebook (an arm64 laptop). Trying to start it manually, brightd just displays the help text and exits: $ brightd -v -w 5 brightd 0.4.1 A X11-daemon for iBook-like brightness management Copyright (c) 2006-2008, Phillip Berndt Options: -vBe verbose -dDaemonize -P Create pid file -u n Drop privileges to this user (Defaults to nobody) -w n Wait n seconds before reducing brightness (Defaults to 3) -b n The brightness setting for the dark screen (Defaults zu 0) -fReduce brightness even if on the highest brightness level Specify twice to also do so when on AC -e n Filter event sources using regexp n (on /dev/input/by-path -c n Set the backlight class to use (defaults to the first subnode of /sys/class/backlight) -xDon't query X11 Xss extension -r n Create a FIFO, into which acpid may write the new level when the user changed display brightness The exit code returned to the shell is 0, so it claims to have worked correctly. I've also tried running it as root with the same results, as this said to be required in /usr/share/doc/brightd/README, though if that's true, /etc/X11/Xsession.d/90brightd wouldn't possibly work. /sys/class/backlight/backlight/brightness is writeable by the "video" group, and the user is present in the "video" group. The /sys/class/power_supply/AC doesn't exist, but fromt the attached strace log, it doesn't appear to try to access it. I also built a locally recompiled version patched hardcoding a different path for the AC online status, but it behaved the same. My hunch is some sort of missing assumed dependencies; this device doesn't have ACPI for example. live well, vagrant brightd.strace.log Description: Binary data -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (120, 'unstable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 4.19.0-trunk-arm64 (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 /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages brightd depends on: ii libc6 2.27-8 ii libx11-6 2:1.6.7-1 ii libxss1 1:1.2.3-1 brightd recommends no packages. brightd suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#909383: xemacs21 stale
I think the main problem is that xemacs21 is quite stale, latest upstream release dating back to 2013. Thus it doesn't support (string-to-syntax) Regards Racke -- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible.
Bug#914049: progressivemauve FTBFS with boost 1.67
Control: tags -1 help
On Sun, Nov 18, 2018 at 10:36:52PM +0200, Adrian Bunk wrote:
> /usr/include/c++/8/bits/stl_vector.h:1074:7: note: candidate: 'void
> std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp =
> boost::tuples::tuple std::allocator >, std::vector std::allocator > >; _Alloc =
> std::allocator int, std::allocator >, std::vector std::allocator > > >; std::vector<_Tp, _Alloc>::value_type
> = boost::tuples::tuple std::allocator >, std::vector std::allocator > >]'
>push_back(const value_type& __x)
>^
> /usr/include/c++/8/bits/stl_vector.h:1074:7: note: no known conversion for
> argument 1 from 'GappedMatchRecord*' to 'const value_type&' {aka 'const
> boost::tuples::tuple std::allocator >, std::vector std::allocator > >&'}
> /usr/include/c++/8/bits/stl_vector.h:1090:7: note: candidate: 'void
> std::vector<_Tp, _Alloc>::push_back(std::vector<_Tp, _Alloc>::value_type&&)
> [with _Tp = boost::tuples::tuple std::allocator >, std::vector std::allocator > >; _Alloc =
> std::allocator int, std::allocator >, std::vector std::allocator > > >; std::vector<_Tp, _Alloc>::value_type
> = boost::tuples::tuple std::allocator >, std::vector std::allocator > >]'
>push_back(value_type&& __x)
>^
Any idea how to replace push_back?
Kind regards
Andreas.
--
http://fam-tille.de
Bug#909383: Fails to install
This even happens on a normal system - looks like it enters an infinite loop: Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Loading 20apel... Loading 50flim... Loading 50w3m-el... Regards from BSP in Bern Racke -- Ecommerce and Linux consulting + Perl and web application programming. Debian and Sympa administration. Provisioning with Ansible.
Bug#914914: debhelper: Consider setting common full-path variables to prevent reproducible build issues wrt usrmerge
Hello Niels, Thanks for your quick followup. On Thu, Nov 29, 2018 at 07:31:00AM +, Niels Thykier wrote: > Hi Andreas, > > Thanks for filing the bug. Please feel free to wontfix/close this if you feel like it. [...] > This seems to still be a "whack-a-mole" strategy; we are just > centralizing it to debhelper (which does have some merit). There will for sure always be cases where we need to massage the package to make it reproducible on usrmerge vs non-merged. My thought was simply to cat a few cases before they even get introduced. if possible (and worth it). [...] > Honestly, I am conflicted on this. On one hand, I do not want to > maintain such a list forever - which I would have if usrmerge will > remain optional forever. On the other hand, I can see how this would be > useful in deflating the current (and future) d-d mail threads about > usrmerge. > > I will be considering it for now. I've looked over the 32 (+ 1) cases and my unconfirmed view on them is that if debhelper passed the following variables to configure: PS alone fixes 2 GREP alone fixes 1,5 (positively effects 1 more) CAT alone fixes 1 (positively effects 1 more) TRUE alone fixes 1 GZIP alone fixes 1 (positively effects 1 more) SED alone fixes 1 (positively effects 3 more) ECHO alone fixes 1 MKTEMP alone fixes 1 (positively effects 1 more) above (MKTEMP SED) plus BASH fixes 1 more above (GREP SED) plus MKDIR_P fixes 1 more above (GZIP CAT) plus SH fixes 1 more Please note: All affected cases seems to either use autoconf or Makefile.PL build system. I have no idea about perl so only autoconf are part of above summary. Makefile.PL should be rare enough that it shouldn't affect things much. (The GREP -> 1,5 comes from that it fixes 2 but there's another comment in one of them that is still causes unreproducibility, but that is fixed by SED so could have said 2...). I'm not sure what conclusions to draw from this exactly. I'm also not sure what the reproducible build system staying on 32(+1) found for a while now means. Has it tested all packages in archive yet or not? If this is it, then I guess it's absolutely not worth bothering to do anything in debhelper to handle this Regards, Andreas Henriksson
Bug#910882: cups-browsed: The default for UseCUPSGeneratePPDs should be "Yes"
I have fixed the disappearing queue problem upstream in commit dd862c9b. What happened is that one cannot reliably determine the temporary nature of a CUPS queue via printer-is-temporary. So I check whether the queue is shared instead and as any shared queue is permanent I do the procedure of setting and unsetting the shared bit on any unshared queue as it can be temporary. So with this I am sure that my queue is permanent and I do not interrupt the shared status of a shared queue. Till
Bug#915139: linux-image-4.18.0-2-amd64: Please set CONFIG_MEMCG_SWAP_ENABLED
Package: src:linux Version: 4.18.10-2+b1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Maintainer, Some processes in my system need to be limited when it comes to memory consumption. I wanted to use cgroup v1 along with tools from the cgroup-tools package to achieve the goal. Everything works well, but the limits can be applied to RAM only. My machine has also a SWAP partition, and in such case, when the limit is reached, kernel starts to use SWAP, and it does that without any control. For instance, if I've set a limit of 1GiB of memory for firefox, after reaching this limit, all the data would go to SWAP and fill it up slowing also the system down. There's an option that could prevent this from happening: CONFIG_MEMCG_SWAP_ENABLED , but it's not set and all the memory.memsw.* files under /sys/fs/cgroup/memory/ don't exist. Could you set this option? -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwBsqkACgkQzQRoEHcb ZSB7JQ/9EY0WKSPpGpnoWhXSOEsKHZHFPHl9Pf8b9OqVyuopFQSHZZ2IidiqUfWO qgXkU72ZJAwNTQVZPC10HScYuM6y7Us1Q4fLjk6FeLu5E+kttJmvxZt6D0DAM5zi t4TttDwWIeybT7KF8ST6OcCzs3fq/EqzeL3WINq+QE/1PcMnWgI+4Rp3tj5pYbZH owdXdN9+d065qIypdrIJHhxJ/ZfCbUonslQPh8En+8ml+tPBNWslpCkx5AFWp/Cw cdrmqqmY3nEXeQAgy6MfSHhGytD01Fki/BmX9mIE+cAodNTVSz8/1oc+vk2sQRVh yBnv5uuDmCgh2Fr81/Iz8yOJ5bcf9XTT9oAdHbdQ5FsHgLfdthOC7Y73hNLtoTXH 95gNO9D/iHSzH2U8isq2R57VD9G/TSX79y8jIp3eUmAEXJfJ75qNN7Q4T3R89Z1q Yq1Qo1WWduy/8nlQNNcay4bAaHuD0qdBqqeQ1BGNhO7VIcVtgxfcd2y0fHx4CpOx Y2xE3qOlatl2G9GwKHRoDZaciMUfmfc32c/25FstGsys4x9QpsUtNnZc5LISAT36 jiibihHLUA5pj0xbeWet0/ao8JW/hSxyOtiezv8WKwubOd0SO6NG2iAUEHRfei7I j0ZPF+yGr8MEf24AgHAXYHl/nxwFfJLvmata2eTTlJWcamBjCtU= =WmNH -END PGP SIGNATURE-
Bug#914951: 4.19.5 fails to boot as Xen dom0
On 11/29/18 2:38 AM, Hans van Kranenburg wrote: > On 11/29/18 1:20 AM, Hans van Kranenburg wrote: >> Package: src:linux >> Version: 4.19.5-1~exp1 >> Severity: normal >> >> Hi, >> >> Latest 4.19 upload fails to boot as Xen dom0. > > Copy at > https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html > > [...] A fix has been written and tested: https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03570.html I tested it on top of 4.19.5-1~exp1. I expect the first of those two patches (the actual fix) to show up in a later 4.19. Hans
Bug#915099: RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) Raspberry PI Minecraft API
Petter Reinholdtsen writes: > There is an alternative fork of the module on > https://github.com/sprintingkiwi/pycraft_mod >. It has seen more > development the last few years. Perhaps it is a better alternative? I made draft packaging of this package available as https://salsa.debian.org/games-team/unfinished/minetest-mod-pycraft >. Had to fetch upstream HEAD from git. Hopefully they will start tagging releases. Also, the d/copyright file need more love and care. The build rules provide one minetest module, and the python library to talk to the minetest server, alongside many example python scripts to create and run various features. The clock.py one was particularly nice. :) -- Happy hacking Petter Reinholdtsen
Bug#915138: gimp: complains that "SVG file does not specify a size!"
Package: gimp Version: 2.10.8-1 Severity: normal Here is the header of an SVG file that: (1) displays correctly in programs like inkscape and eog (2) used to open without problem in earlier versions of Gimp http://purl.org/dc/elements/1.1/"; xmlns:cc="http://creativecommons.org/ns#"; xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; xmlns:svg="http://www.w3.org/2000/svg"; xmlns="http://www.w3.org/2000/svg"; id="svg9" preserveAspectRatio="xMidYMid meet" viewBox="0 0 920.0001 161.99292" height="202.49115" width="1150.0001" version="1.0"> Created by potrace 1.8, written by Peter Selinger 2001-2007 image/svg+xml http://purl.org/dc/dcmitype/StillImage"; /> [...] Gimp no longer recognizes the size. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-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 /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gimp depends on: ii gimp-data2.10.8-1 ii libaa1 1.4p5-44+b2 ii libbabl-0.1-00.1.60-1 ii libbz2-1.0 1.0.6-9 ii libc62.27-8 ii libcairo21.16.0-1 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.2.0-9 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-6 ii libgegl-0.4-00.4.12-1 ii libgexiv2-2 0.10.8-1 ii libgimp2.0 2.10.8-1 ii libglib2.0-0 2.58.1-2 ii libgs9 9.26~dfsg-1 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.1.1-1+b1 ii libheif1 1.3.2-1+b1 ii libilmbase23 2.2.1-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3 ii liblzma5 5.2.2-1.3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2 ii libopenexr23 2.2.1-4 ii libopenjp2-7 2.3.0-1 ii libpango-1.0-0 1.42.4-4 ii libpangocairo-1.0-0 1.42.4-4 ii libpangoft2-1.0-01.42.4-4 ii libpng16-16 1.6.34-2 ii libpoppler-glib8 0.69.0-2 ii librsvg2-2 2.44.9-1 ii libstdc++6 8.2.0-9 ii libtiff5 4.0.10-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libwmf0.2-7 0.2.8.4-14 ii libx11-6 2:1.6.7-1 ii libxcursor1 1:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages gimp recommends: ii ghostscript 9.26~dfsg-1 Versions of packages gimp suggests: pn gimp-data-extras pn gimp-help-en | gimp-help pn gimp-python pn gvfs-backends ii libasound21.1.7-1+b1 -- no debconf information
Bug#518254: ganglia-webfrontend: missing README.Debian
Package: ganglia-webfrontend Followup-For: Bug #518254 Dear Maintainer, in the current stable distribution we have: # dpkg -L ganglia-webfrontend | grep README.Debian /usr/share/doc/ganglia-webfrontend/README.Debian I suggest closing this bug. Jochen -- System Information: Debian Release: 9.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ganglia-webfrontend depends on: ii apache2 [httpd-cgi] 2.4.25-3+deb9u6 ii debconf 1.5.61 ii libapache2-mod-php 1:7.0+49 ii libapache2-mod-php7.0 [libapache2-mod-php] 7.0.30-0+deb9u1 ii php 1:7.0+49 ii php-xml 1:7.0+49 ii php7.0 [php]7.0.30-0+deb9u1 ii php7.0-xml [php-xml]7.0.30-0+deb9u1 ii rrdtool 1.6.0-1+b2 Versions of packages ganglia-webfrontend recommends: ii gmetad 3.6.0-7+b1 ii php-gd 1:7.0+49 ii php7.0-gd [php-gd] 7.0.30-0+deb9u1 ganglia-webfrontend suggests no packages. -- debconf information excluded
Bug#865795: radvd blocks when started over ssh
Eversince I opened this bug, I used my own patched package. Only now I just tried 1:2.17-1~bpo9+1 and can confirm that the bug is no longer present. Thanks Daniel signature.asc Description: OpenPGP digital signature
Bug#911443: raspi3-firmware | Add board-specific firmware files for RPi 3B+ WiFi (!1)
Hi Stefan > Which RPi 3 variant do you use (B or B+)? Today I have tested on the Raspberry Pi 3 B with arm64. I was able to reproduce it also with kernel 4.19.5. wlan0 remains absent with this newer kernel version. Based on 4.19.5 I reverted commit b1b8f45b3130dbd8704e5ea0d82b49b1d929498e and then wlan0 was back. > Could you please provide a reduced kernel config? Here is more information: Kernel configuration: https://drive.google.com/open?id=1ZI3MeGB2fkYMsEjzGQYXUk2wqr0h9h7R linux-image-4.19.5-v8_4.19.5-v8-1_arm64.deb (wlan0 is absent): https://drive.google.com/open?id=1QCNZcpxeeCBGNb0dsZBBZD9i2Y1kCeib dtb with b1b8f45b3130dbd8704e5ea0d82b49b1d929498e reverted (wlan0 is back): https://drive.google.com/open?id=11O0c-StAUvV7IXFIs1UBlzeu-CTP3KVt > Is armhf (32 bit) affected, too? I think so - but I did not test it yet. Best regards Matthias
Bug#915136: Push is also not working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm testing about this bug if a new commit resolve the problem. But commit && push does not work on the affected repository (i haven't checked other repositories). The message on the GIT client are: BloudFire: maqui$ git push Enumerando objetos: 17, listo. Contando objetos: 100% (17/17), listo. Compresi'on delta usando hasta 8 hilos Comprimiendo objetos: 100% (9/9), listo. Escribiendo objetos: 100% (9/9), 858 bytes | 858.00 KiB/s, listo. Total 9 (delta 8), reusado 0 (delta 0) remote: GitLab: API is not accessible To git.example.com:Group/Project.git ! [remote rejected] master -> master (pre-receive hook declined) error: fall'o el push de algunas referencias a 'git...@git.example.com: Group/Project.git' Error message at production.log are: GRPC::DeadlineExceeded (4:Deadline Exceeded): /usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:31:in `check_status' /usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:181:in `attach_status_results_and_complete_call' /usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:170:in `receive_and_check_status' /usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0/gems/grpc-1.16.0/src/ruby/lib/grpc/generic/active_call.rb:338:in `each_remote_read_then_finish' /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:107:in `each' /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:107:in `flat_map' /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:107:in `map_lfs_pointers' /usr/share/gitlab/lib/gitlab/gitaly_client/blob_service.rb:90:in `get_new_lfs_pointers' /usr/share/gitlab/lib/gitlab/git/lfs_changes.rb:10:in `new_pointers' /usr/share/gitlab/lib/gitlab/checks/lfs_integrity.rb:13:in `objects_missing?' /usr/share/gitlab/lib/gitlab/checks/change_access.rb:197:in `lfs_objects_exist_check' /usr/share/gitlab/lib/gitlab/checks/change_access.rb:41:in `exec' /usr/share/gitlab/lib/gitlab/git_access.rb:277:in `check_single_change_access' /usr/share/gitlab/lib/gitlab/git_access.rb:265:in `block in check_change_access!' /usr/share/gitlab/lib/gitlab/git_access.rb:260:in `each' /usr/share/gitlab/lib/gitlab/git_access.rb:260:in `with_index' /usr/share/gitlab/lib/gitlab/git_access.rb:260:in `check_change_access!' /usr/share/gitlab/lib/gitlab/git_access.rb:250:in `check_push_access!' /usr/share/gitlab/lib/gitlab/git_access.rb:69:in `check' /usr/share/gitlab/lib/api/internal.rb:60:in `block (2 levels) in ' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:57:in `call' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:57:in `block (2 levels) in generate_api_method' /usr/lib/ruby/vendor_ruby/active_support/notifications.rb:166:in `instrument' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:56:in `block in generate_api_method' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:262:in `block in run' /usr/lib/ruby/vendor_ruby/active_support/notifications.rb:166:in `instrument' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:243:in `run' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:313:in `block in build_stack' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:31:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:31:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call' /usr/share/rubygems-integration/all/gems/rack-oauth2-1.9.2/lib/rack/oauth2/server/resource.rb:20:in `_call' /usr/share/rubygems-integration/all/gems/rack-oauth2-1.9.2/lib/rack/oauth2/server/resource/bearer.rb:8:in `_call' /usr/share/rubygems-integration/all/gems/rack-oauth2-1.9.2/lib/rack/oauth2/server/abstract/handler.rb:17:in `call' /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:38:in `block in call!' /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:37:in `catch' /usr/lib/ruby/vendor_ruby/grape/middleware/error.rb:37:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call' /usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:60:in `block in call!' /usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:58:in `catch' /usr/lib/ruby/vendor_ruby/grape_logging/middleware/request_logger.rb:58:in `call!' /usr/lib/ruby/vendor_ruby/grape/middleware/base.rb:24:in `call' /usr/lib/ruby/vendor_ruby/rack/head.rb:13:in `call' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:227:in `call!' /usr/lib/ruby/vendor_ruby/grape/endpoint.rb:221:in `call' /usr/lib/ruby/vendor_ruby/grape/router/route.rb:72:in `exec' /usr/lib/ruby/vendor_ruby/grape/router.rb:121:in `process_route' /usr/lib/ruby/vendor_ruby/grape/router.rb:74:in `block in identity' /usr/lib/ruby/vendor_ruby/grape/router.rb:93:in `transaction' /usr/lib/ruby/vendor_ruby/grape/router.rb:72:in `identity' /usr/lib/ruby/vendor_ruby/grape/route
Bug#844321: unison: Please update to latest upstream version
Hi, can we please get the latest upstream version into Buster? I do realize, there's been a 2.48.4-1 release since I opened this bug. However, that release is over a year old and upstream has included some bugfixes since. The current upstream version is 2.48.15. Thanks, Daniel signature.asc Description: OpenPGP digital signature
Bug#914742: zeroc-ice ftbfs in unstable with Python 3.7
That is already fixed upstream in https://github.com/zeroc-ice/ice/commit/4aea9fc787892842af17d119332a7f6fef2f35c4 I will upload a patch On Mon, Nov 26, 2018 at 10:15 PM Matthias Klose wrote: > Package: src:zeroc-ice > Version: 3.7.1-5 > Severity: serious > Tags: sid buster patch > > zeroc-ice ftbfs in unstable with Python 3.7 > > x86_64-linux-gnu-g++ -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -MT > modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.o -MMD -MP -MF > modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.Td -Wall -Wdeprecated > -Werror -pthread -DNDEBUG -Imodules/IcePy -I../cpp/include > -I../cpp/include/generated -I../cpp/src -I/usr/include/python3.7m > -I/usr/include/python3.7m -Wno-unused-result -Wsign-compare -g > -fdebug-prefix-map=/build/python3.7-0HyDJv/python3.7-3.7.1=. > -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector -Wformat > -Werror=format-security -DNDEBUG -g -fwrapv -O3 -Wall -fPIC > -fvisibility=hidden > -Wdate-time -D_FORTIFY_SOURCE=2 -c modules/IcePy/Proxy.cpp -o > modules/IcePy/build/x86_64-linux-gnu/shared/pic/Proxy.o > modules/IcePy/Communicator.cpp: In function ‘PyObject* > communicatorWaitForShutdown(IcePy::CommunicatorObject*, PyObject*)’: > modules/IcePy/Communicator.cpp:475:36: error: comparison of integer > expressions > of different signedness: ‘long unsigned int’ and ‘long int’ > [-Werror=sign-compare] > if(PyThread_get_thread_ident() == _mainThreadId) > ^~~~ > cc1plus: all warnings being treated as errors > make[2]: *** [Makefile:41: > modules/IcePy/build/x86_64-linux-gnu/shared/pic/Communicator.o] Error 1 > make[2]: *** Waiting for unfinished jobs > > > work around patch available at > https://patches.ubuntu.com/z/zeroc-ice/zeroc-ice_3.7.1-5ubuntu1.patch > -- José Gutiérrez de la Concha ZeroC, Inc.
Bug#915137: mupdf: CVE-2018-19777
Source: mupdf Version: 1.14.0+ds1-2 Severity: important Tags: security upstream Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=700301 Hi, The following vulnerability was published for mupdf. CVE-2018-19777[0]: | In Artifex MuPDF 1.14.0, there is an infinite loop in the function | svg_dev_end_tile in fitz/svg-device.c, as demonstrated by mutool. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-19777 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19777 [1] https://bugs.ghostscript.com/show_bug.cgi?id=700301 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
Bug#915136: Gitlab: Error 503 loading some projects
Package: gitlab
Version: 11.3.10+dfsg-2
Severity: important
Hi,
I'm working with Gitlab 11.3.10, and after a commit & push, I cannot see one of
my projects.
The error message are:
Started GET "/Group/Project/commits/master" for x.x.x.x at 2018-11-30 21:30:02
+0100
Processing by Projects::CommitsController#show as HTML
Parameters: {"namespace_id"=>"Group", "project_id"=>"Project", "id"=>"master"}
Gitlab::Git::CommandError (14:all SubConns are in TransientFailure):
lib/gitlab/git/repository.rb:1010:in `rescue in wrapped_gitaly_errors'
lib/gitlab/git/repository.rb:1003:in `wrapped_gitaly_errors'
lib/gitlab/git/repository.rb:364:in `log'
lib/gitlab/git/commit.rb:41:in `where'
app/models/repository.rb:145:in `commits'
app/controllers/projects/commits_controller.rb:63:in `set_commits'
lib/gitlab/i18n.rb:53:in `with_locale'
lib/gitlab/i18n.rb:59:in `with_user_locale'
app/controllers/application_controller.rb:405:in `set_locale'
lib/gitlab/middleware/multipart.rb:101:in `call'
lib/gitlab/request_profiler/middleware.rb:14:in `call'
lib/gitlab/middleware/go.rb:17:in `call'
lib/gitlab/etag_caching/middleware.rb:11:in `call'
lib/gitlab/middleware/read_only/controller.rb:38:in `call'
lib/gitlab/middleware/read_only.rb:16:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:18:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
lib/gitlab/middleware/release_env.rb:10:in `call'
Completed 503 Service Unavailable in 600ms (Views: 277.3ms | ActiveRecord:
12.2ms)
Same problem appears loading:
- Project -> Details.
- Repository -> Files.
- Repository -> Commits.
- Repository -> Branches.
- Repository -> Tags.
- Repository -> Contributos.
- Repository -> Graph (with Error 2).
- Repository -> Charts.
Repository has been working without any problem until a last commit. The commit
are here:
commit 9827dcf92b7eccdac395697b650bc1ff0f3fadc7 (HEAD -> master, origin/master,
origin/HEAD)
Merge: a6a31bdea f2a6999a9
Author: author2
Date: Fri Nov 30 15:04:56 2018 +0100
Merge branch 'master' of git.example.com:Group/Project
commit a6a31bdea50006b4853b73e61c61bf971fc435b5
Author: author2
Date: Fri Nov 30 15:04:19 2018 +0100
Actualizados los plugins segun el repo
Git commands are working without problem. rake gitlab:check does not report any
problem. I've triggered repository check from admin interface, and none
improvement.
Upgrading to gitlab 11.3.11 does not resolve the problem.
Error 2:
Gitlab::Git::CommandError (14:all SubConns are in TransientFailure):
lib/gitlab/git/repository.rb:1010:in `rescue in wrapped_gitaly_errors'
lib/gitlab/git/repository.rb:1003:in `wrapped_gitaly_errors'
lib/gitlab/git/repository.rb:210:in `tags'
lib/gitlab/git/repository.rb:481:in `refs_hash'
app/models/repository.rb:486:in `method_missing'
lib/gitlab/git/commit.rb:398:in `refs'
lib/gitlab/git/commit.rb:294:in `ref_names'
app/models/network/commit.rb:17:in `method_missing'
app/models/network/graph.rb:134:in `include_ref?'
app/models/network/graph.rb:123:in `block in commits_sort_by_ref'
app/models/network/graph.rb:122:in `sort'
app/models/network/graph.rb:122:in `commits_sort_by_ref'
app/models/network/graph.rb:66:in `index_commits'
app/models/network/graph.rb:19:in `initialize'
app/controllers/projects/network_controller.rb:23:in `new'
app/controllers/projects/network_controller.rb:23:in `block (2 levels) in
show'
app/controllers/projects/network_controller.rb:15:in `show'
lib/gitlab/i18n.rb:53:in `with_locale'
lib/gitlab/i18n.rb:59:in `with_user_locale'
app/controllers/application_controller.rb:405:in `set_locale'
lib/gitlab/middleware/multipart.rb:101:in `call'
lib/gitlab/request_profiler/middleware.rb:14:in `call'
lib/gitlab/middleware/go.rb:17:in `call'
lib/gitlab/etag_caching/middleware.rb:11:in `call'
lib/gitlab/middleware/read_only/controller.rb:38:in `call'
lib/gitlab/middleware/read_only.rb:16:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:18:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:27:in `call'
lib/gitlab/middleware/release_env.rb:10:in `call'
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.23--grs-ipv6-64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gitlab depends on:
ii asciidoctor1.5.8-1
ii bc 1.07.1-2+b1
ii bundler1.16.1-3
ii bzip2 1.0.6-9
ii dbconfig-pgsql 2.0.10
ii debconf [debconf-2.0]
Bug#909682: Bug #909682: Memory leak with gst_tag_list_add_id3_image
So, as promised, I've been playing that album again, and it's again leaking memory. I tried a few things to get it to free the memory. Putting tracks from a different album in the middle didn't do it. Neither did deleting the rest of the album from the playlist and playing something else (in fact, it continued to leak — just <1MB at a time, presumably due to the new album having a single smaller picture). Maybe it's also really noticeable because there are 29 large pictures attached to each track. I got a better backtrack from gdb: Thread 23 "task116" hit Breakpoint 1, 0x7f89dd9fe320 in gst_tag_list_add_id3_image () from /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 (gdb) bt #0 0x7f89dd9fe320 in gst_tag_list_add_id3_image () at /usr/lib/x86_64-linux-gnu/libgsttag-1.0.so.0 #1 0x7f8998013b00 in gst_flac_parse_handle_picture (buffer=0x7f88d814bce0, flacparse=0x7f891e1c3690 [GstFlacParse]) at /usr/include/gstreamer-1.0/gst/base/gstbytereader.h:651 #2 0x7f8998013b00 in gst_flac_parse_handle_block_type (sbuffer=0x7f88d814bce0, type=6, flacparse=0x7f891e1c3690 [GstFlacParse]) at gstflacparse.c:1520 #3 0x7f8998013b00 in gst_flac_parse_parse_frame (frame=0x7f89250505e0, frame=0x7f89250505e0, size=301495, parse=0x7f891e1c3690 [GstFlacParse]) at gstflacparse.c:1574 #4 0x7f8998013b00 in gst_flac_parse_handle_frame (parse=0x7f891e1c3690 [GstFlacParse], frame=0x7f89250505e0, skipsize=) at gstflacparse.c:870 #5 0x7f89dcce46b2 in gst_base_parse_handle_buffer (parse=parse@entry=0x7f891e1c3690 [GstFlacParse], buffer=, skip=skip@entry=0x7f895fffe75c, flushed=flushed@entry=0x7f895fffe758) at gstbaseparse.c:2160 #6 0x7f89dcce4d8f in gst_base_parse_scan_frame (parse=parse@entry=0x7f891e1c3690 [GstFlacParse], klass=) at gstbaseparse.c:3464 #7 0x7f89dcce8302 in gst_base_parse_loop (pad=) at gstbaseparse.c:3543 #8 0x7f89dcc30f41 in gst_task_func (task=0x7f897c237050 [GstTask]) at gsttask.c:332 #9 0x7f89dcdb0ad3 in g_thread_pool_thread_proxy (data=) at ../../../../glib/gthreadpool.c:307 #10 0x7f89dcdb0135 in g_thread_proxy (data=0x7f8924ffb0f0) at ../../../../glib/gthread.c:784 #11 0x7f89dd154f2a in start_thread (arg=0x7f895700) at pthread_create.c:463 #12 0x7f89db094edf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 (gdb) c Continuing. Looks like its some threaded workpool... I later added a breakpoint on pthread_create to try and see where the thread is coming from, and it looks like the threads are creating more threads and maybe never exiting? This appears to happen every track (the task number goes up by two each time; I didn't add the breakpoint on pthread_create in time to catch 116 creating 118, probably. Here is 118 creating 120, which then goes on to cal gst_tag_list_add_id3_image): Thread 26 "task118" hit Breakpoint 2, __pthread_create_2_1 (newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610, start_routine=start_routine@entry=0x7f89dcdb00e0 , arg=arg@entry=0x7f8900433770) at pthread_create.c:610 610 in pthread_create.c (gdb) bt #0 0x7f89dd155210 in __pthread_create_2_1 (newthread=newthread@entry=0x7f89004337a0, attr=attr@entry=0x7f89717f5610, start_routine=start_routine@entry=0x7f89dcdb00e0 , arg=arg@entry=0x7f8900433770) at pthread_create.c:610 #1 0x7f89dcdce2e0 in g_system_thread_new (thread_func=thread_func@entry=0x7f89dcdb00e0 , stack_size=stack_size@entry=0, error=error@entry=0x7f89717f56e0) at ../../../../glib/gthread-posix.c:1177 #2 0x7f89dcdb043f in g_thread_new_internal (name=0x7f89dcde27c2 "pool", proxy=0x7f89dcdb00e0 , func=0x7f89dcdb0a60 , data=0x7f89b0050780, stack_size=0, error=0x7f89717f56e0) at ../../../../glib/gthread.c:874 #3 0x7f89dcdb07ad in g_thread_pool_start_thread (pool=pool@entry=0x7f89b0050780, error=error@entry=0x7f89717f56e0) at ../../../../glib/gthreadpool.c:407 #4 0x7f89dcdb0da3 in g_thread_pool_start_thread (error=0x7f89717f56e0, pool=0x7f89b0050780) at ../../../../glib/gthreadpool.c:552 #5 0x7f89dcdb0da3 in g_thread_pool_push (pool=0x7f89b0050780, data=data@entry=0x7f8959f45f20, error=error@entry=0x7f89717f5750) at ../../../../glib/gthreadpool.c:563 #6 0x7f89dcc31f6a in default_push (pool=0x7f89b0043920 [GstTaskPool], func=0x7f89dcc30dc0 , user_data=, error=0x7f89717f5750) at gsttaskpool.c:106 #7 0x7f89dcc31b26 in start_task (task=0x7f88e1746710 [GstTask]) at gsttask.c:652 #8 0x7f89dcc31b26 in gst_task_set_state (task=task@entry=0x7f88e1746710 [GstTask], state=state@entry=GST_TASK_STARTED) at gsttask.c:704 #9 0x7f89dcc061bb in gst_pad_start_task (pad=0x7f890f81ac90 [GstPad], func=0x7f897056cd80 , user_data=0x7f890f81ac90, notify=0x0) at gstpad.c:6169 #10 0x7f89dcc003e6 in gst_pad_set_active (pad=pad@entry=0x7f890f81ac90 [GstPad], active=1) at gstpad.c:1107 #11 0x7f89dcbde0ad in activate_pads (vpad=, ret=0x7f89717f58a0, active=0x7f89717f58fc) at
Bug#915135: exiv2: CVE-2018-19535
Source: exiv2 Version: 0.25-4 Severity: important Tags: patch security upstream Forwarded: https://github.com/Exiv2/exiv2/issues/428 Hi, The following vulnerability was published for exiv2. CVE-2018-19535[0]: | In Exiv2 0.26 and previous versions, PngChunk::readRawProfile in | pngchunk_int.cpp may cause a denial of service (application crash due | to a heap-based buffer over-read) via a crafted PNG file. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-19535 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19535 [1] https://github.com/Exiv2/exiv2/issues/428 [2] https://github.com/Exiv2/exiv2/pull/430 Please adjust the affected versions in the BTS as needed. The vulnerable code is at least already present in 0.25-4 but I guess even in stretch version (but not checked). Regards, Salvatore
Bug#915007: opensaml2 FTBFS with xmltooling 3
Don't wait for me on shibboleth-resolver or moonshot-gss-eap to file the removal requests. They are both basically broken in unstable, so there's no reason to block.
Bug#849513: d/control: Conflicts can be removed
Hi, On Mon, 19 Nov 2018 21:40:46 +0100 Mathieu Malaterre wrote: While the binary name is a long story, I believe it does not make sense to continue keeping: $ cat d/control ... Conflicts: ninja Indeed, I'll remove it with the next upload. With regard to renaming the package: I really don't think it's worth the trouble of going through NEW, doing the transitional package dance and having all reverse (build-)dependencies updated. The upstream domain is ninja-build.org, other distros also call it ninja-build so it's not really a surprising name that is hard to find. Felix
Bug#914948: [Pkg-utopia-maintainers] Bug#914948: Might be a kernel bug
You could try with a kernel from stretch-backports Am 30. November 2018 19:56:33 MEZ schrieb EP : >Hello! > >https://bugzilla.redhat.com/show_bug.cgi?id=1579046 > >This bug report and some posts in debianforum.de make me think that it >is an already fixed kernel bug (fixed in newer kernel versions). > >Best wishes > >___ >Pkg-utopia-maintainers mailing list >pkg-utopia-maintain...@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
On Fri, 2018-11-30 at 19:40 +0100, Didier 'OdyX' Raboud wrote: > Dear Hideki, dear src:debootstrap maintainers, > > tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by > default now, or are you OK letting the TC decide on this subject? There were discussions about enabling this by default years ago, I don't think minor issues should be a reason to delay this change. Note that it has been delayed for after the stretch release as there were major issues back then (it was enabled by default for a short time in stretch). It took >5 months for someone to find a problem this time which is pretty good for any change. Ansgar
Bug#915134: exiv2: CVE-2018-19607
Source: exiv2 Version: 0.26-1 Severity: grave Tags: patch security upstream Justification: user security hole Forwarded: https://github.com/Exiv2/exiv2/issues/561 Hi, The following vulnerability was published for exiv2, it only affects experimental (thus filling as RC severity so does not enter unstable) CVE-2018-19607[0]: | Exiv2::isoSpeed in easyaccess.cpp in Exiv2 v0.27-RC2 allows remote | attackers to cause a denial of service (NULL pointer dereference and | application crash) via a crafted file. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-19607 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19607 [1] https://github.com/Exiv2/exiv2/issues/561 Regards, Salvatore
Bug#914355: [Pkg-electronics-devel] Bug#914355: gnucap-python: FTBFS (dh_auto_configure fails)
On Thu, Nov 22, 2018 at 04:35:20PM +, Santiago Vila wrote: > Package: src:gnucap-python > Version: 0.0.0-1 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package but it failed: Thank you. there's a new package for the 0.0.1 release [1]. the build issue caused by incomplete python dependencies is fixed. this was one reason for 914355. i checked with cowbuilder for amd64 and i386. on i386, only the tests fail due to numerical noise. please advise if that can wait until 0.0.2, ETA unknown. (i don't think there is a use case for gnucap on i386..) regards felix [1] https://salsa.debian.org/electronics-team/Gnucap/gnucap-python
Bug#914948: Might be a kernel bug
Hello! https://bugzilla.redhat.com/show_bug.cgi?id=1579046 This bug report and some posts in debianforum.de make me think that it is an already fixed kernel bug (fixed in newer kernel versions). Best wishes
Bug#915122: extra-cmake-modules: FindQHelpGenerator does not work for cross compilation
Hi Helmut!
On Fri, Nov 30, 2018 at 07:23:20PM +0100, Helmut Grohne wrote:
> kconfig fails to cross build from source, because it fails to find
> qhelpgenerator using extra-cmake-modules. The failure is due to a
> combination of assumptions that don't add up. It's not entirely clear
> which of them is wrong so I'm filing the bug with extra-cmake-modules
> now even though it might need a fix elsewhere.
>
> kconfig uses FindQHelpGenerator. FindQHelpGenerator looks up Qt5::qmake.
> Since fixing #913499, qtbase-5-dev supplies
> /usr/lib/$DEB_HOST_MULTIARCH/qt5/bin/qmake, which is a symbolic link to
> /usr/bin/$DEB_HOST_GNU_TYPE-qmake, which is our cross wrapper for qmake.
> Now FindQHelpGenerator.cmake uses the directory part of Qt5::qmake and
> expects to find a qhelpgenerator inside that directory. Unfortunately,
> it doesn't find one. qhelpgenerator is only located in /usr/bin,
> /usr/lib/qt5/bin and /usr/lib/$DEB_BUILD_GNU_TYPE/qt5/bin.
>
> The assumption of FindQHelpGenerator.cmake that the directory of
> Qt5::qmake contains qhelpgenerator is not presently a valid one. I
> cannot tell whether it should be valid or not.
This is fixed upstream in [1]. With that change, FindQHelpGenerator
uses Qt5HelpConfigExtras.cmake which has the correct path:
set(imported_location "${_qt5Help_install_prefix}/lib/qt5/bin/qhelpgenerator")
However as Qt5HelpConfigExtras.cmake is in qttools5-dev, the affected
packages will need to build-depend on it in order for the fix to work.
That commit will be in 5.53.0 release, to be released on December 8th.
[1]: https://cgit.kde.org/extra-cmake-modules.git/commit/?id=96d169b87292d935
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Bug#888747: keepalived: ip_vs not loading on initial startup
severity 888747 wishlist thanks On Mon, 29 Jan 2018, Thomas Baetzler wrote: > Package: keepalived > Version: 1:1.3.2-1 > Severity: important > > Dear Maintainer, > > the required module ip_vs is not automatically loaded on startup which > prevents keepalived from working after a reboot. > > The service works as expected after a manual "systemctl restart keepalived". > > A workaround is to add the following line to the service definition: ip_vs is not required to run keepalived. It is perfectly valid to just use the VRRP part instead of ipvs (in fact most of my customer setups don't use ipvs). I therefore think its not the best idea to enforce loading of ipvs, that would lead to problems on systems without ipvs (in the past at least the debian system admins ran such systems). Alex
Bug#915127: cloud.debian.org: Please add AWS image for new ARM instances
Noah Meyerhans wrote: It's on its way. Glad to hear it, many thanks!
Bug#915133: python-coverage: autopkgtest needs update for new version of python3-defaults
Source: python-coverage Version: 4.5.1+dfsg.1-1 User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:python3-defaults [X-Debbugs-CC: debian...@lists.debian.org, python3-defau...@packages.debian.org ] Dear maintainers, With a recent upload of python3-defaults (that switched the default python3 from 3.6 to 3.7) the autopkgtest of python-coverage fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.7.1-2 python-coveragefrom testing4.5.1+dfsg.1-1 all others from testingfrom testing I copied some of the output at the bottom of this report. The error points at the situation where python3.6-minimal is installed, but not python3.6. However, your autopkgtest uses $(py3versions -i) and assumes that the zipfile module is installed, while it doesn't make sure that it is. Your autopkgtest should have a dependency on python3-all if you want to test all installed python3 versions (py3versions tells which python3.*-minimal versions are installed). More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-coverage/1408602/log.gz autopkgtest [16:09:48]: test smoke-python3: [--- Python command: python3.6 Traceback (most recent call last): File "debian/tests/smoke_test.py", line 24, in import pkg_resources File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 26, in import zipfile ModuleNotFoundError: No module named 'zipfile' autopkgtest [16:09:49]: test smoke-python3: ---] signature.asc Description: OpenPGP digital signature
Bug#915132: pybitcointools: autopkgtest needs update for new version of python3-defaults
Source: pybitcointools Version: 1.1.42-1 User: debian...@lists.debian.org Usertags: needs-update Control: affects -1 src:python3-defaults [X-Debbugs-CC: debian...@lists.debian.org, python3-defau...@packages.debian.org ] Dear maintainers, With a recent upload of python3-defaults (that switched the default python3 from 3.6 to 3.7) the autopkgtest of pybitcointools fails in testing when that autopkgtest is run with the binary packages of python3-defaults from unstable. It passes when run with only packages from testing. In tabular form: passfail python3-defaults from testing3.7.1-2 pybitcointools from testing1.1.42-1 all others from testingfrom testing I copied some of the output at the bottom of this report. The error points at the situation where python3.6-minimal is installed, but not python3.6. However, your autopkgtest uses $(py3versions -i) and assumes that the zipfile module is installed, while it doesn't make sure that it is. Your autopkgtest should have a dependency on python3-all if you want to test all installed python3 versions (py3versions tells which python3.*-minimal versions are installed). More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=python3-defaults https://ci.debian.net/data/autopkgtest/testing/amd64/p/pybitcointools/1408619/log.gz autopkgtest [16:17:09]: test smoke-python3: [--- Python command: python3.6 Traceback (most recent call last): File "debian/tests/smoke_test.py", line 26, in import pkg_resources File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 26, in import zipfile ModuleNotFoundError: No module named 'zipfile' autopkgtest [16:17:10]: test smoke-python3: ---] signature.asc Description: OpenPGP digital signature
Bug#890641: udev: fragile handling of uevent actions breaks with kernel 4.12+
Hi, there is some discussion going on upstream atm at https://github.com/systemd/systemd/issues/8221 and https://github.com/systemd/systemd/issues/7587 Your ticket has been closed as not a bug in systemd. https://github.com/systemd/systemd/issues/8221#issuecomment-443159165 Thought I'd let you know in case you want to chime in and provide your feedback to the upstream discussion. I didn't have the time yet to digest this particular information in those upstream bug reports, but the prospect of declaring all udev rules files using "positive" add or change events buggy, seems kinda meh. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#915131: python3-ruamel.yaml: DeprecationWarning: Using or importing the ABCs from 'collections'
Package: python3-ruamel.yaml Version: 0.15.34-1+b1 Tags: fixed-upstream Control: forwarded -1 https://bitbucket.org/ruamel/yaml/issues/210 I get the following warning: $ python3 -Wd -c 'import ruamel.yaml' /usr/lib/python3/dist-packages/ruamel/yaml/comments.py:14: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working from collections import MutableSet, Sized, Set I believe this was fixed upstream in 0.15.46. -- System Information: Architecture: i386 Versions of packages python3-ruamel.yaml depends on: ii python3 3.7.1-2 ii libc62.28-1 -- Jakub Wilk
Bug#915130: Further information
I'd like to add the following instructions on how to reproduce the problem: $ apt purge maria* # if mariadb was installed previously. also select "remove all mariadb databases" during purging $ debconf-set-selections <<< "mariadb-server-10.1 mysql-server/root_password password hello" $ debconf-set-selections <<< "mariadb-server-10.1 mysql-server/root_password_again password hello" $ debconf-get-selections |grep maria mariadb-server-10.1 mysql-server/root_password password hello mariadb-server-10.1 mysql-server/root_password_again password hello $ apt install -y mariadb-server-10.1 $mysql mysql <<< "select Host,User,Password,plugin from user;" Host User Password plugin localhost root unix_socket Also, the password remains in the debconf database, which is a security issue: $ debconf-get-selections |grep maria mariadb-server-10.1 mysql-server/root_password password hello mariadb-server-10.1 mysql-server/root_password_again password hello mariadb-server-10.1 mariadb-server-10.1/postrm_remove_databases boolean false mariadb-server-10.1 mariadb-server-10.1/old_data_directory_saved note mariadb-server-10.1 mariadb-server-10.1/nis_warning note The same is valid when using mariadb-server-10.1/root_password as key: $ debconf-get-selections |grep maria mariadb-server-10.1 mariadb-server-10.1/root_password password hello mariadb-server-10.1 mariadb-server-10.1/root_password_again password hello mariadb-server-10.1 mariadb-server-10.1/nis_warning note mariadb-server-10.1 mariadb-server-10.1/postrm_remove_databases boolean false mariadb-server-10.1 mariadb-server-10.1/old_data_directory_saved note
Bug#915127: cloud.debian.org: Please add AWS image for new ARM instances
It's on its way. A newer ENA driver is required for working network, so that's kind of a blocker. On November 30, 2018 10:17:06 AM PST, Phil Endecott wrote: >Package: cloud.debian.org >Severity: wishlist > >Dear Maintainer, > >AWS have recently announced new instance types that use the 64-bit ARM >(aka aarch64) architecture. Machine images are currently available for > >"Amazon Linux 2", RHEL, Ubuntu and Fedora. It would be great to also >have official Debian images. > > >Many thanks, Phil. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#915130: mariadb-server-10.1: mariadb ignores debconf value root_password
Package: mariadb-server-10.1 Version: 10.1.37-0+deb9u1 Severity: normal Dear Maintainer, it used to be possible to specify a root password pre-installation by setting the debconf value root_password and root_password again like this: debconf-set-selections <<< "mysql-server mysql-server/root_password password secret" debconf-set-selections <<< "mysql-server mysql-server/root_password_again password secret" However, the password is not being set: +---+--+--+-+ | Host | User | Password | plugin | +---+--+--+-+ | localhost | root | | unix_socket | +---+--+--+-+ I have purged all mariadb packages (including mysql database files) before trying this. Using debconf-set-selections <<< "maria-db-10.1 mysql-server/root_password password secret" debconf-set-selections <<< "maria-db-10.1 mysql-server/root_password_again password secret" does not work either (same results as above). Instructions regarding the root_password debconf value are still present in the package control/postinst file, however I have not found out yet why this functionality is broken in this version. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-10.1 depends on: ii adduser 3.115 ii debconf [debconf-2.0] 1.5.61 ii galera-3 25.3.19-2 ii gawk 1:4.1.4+dfsg-1 ii init-system-helpers 1.48 ii iproute2 4.9.0-1+deb9u1 ii libaio1 0.3.110-3 ii libc6 2.24-11+deb9u3 ii libdbi-perl 1.636-1+b1 ii libpam0g 1.1.8-3.6 ii libstdc++66.3.0-18+deb9u1 ii libsystemd0 232-25+deb9u6 ii lsb-base 9.20161125 ii lsof 4.89+dfsg-0.1 ii mariadb-client-10.1 10.1.37-0+deb9u1 ii mariadb-common10.1.37-0+deb9u1 ii mariadb-server-core-10.1 10.1.37-0+deb9u1 ii passwd1:4.4-4.1 ii perl 5.24.1-3+deb9u5 ii psmisc22.21-2.1+b2 ii rsync 3.1.2-1+deb9u1 ii socat 1.7.3.1-2+deb9u1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages mariadb-server-10.1 recommends: ii libhtml-template-perl 2.95-2 -- debconf information: mariadb-server-10.1/nis_warning: mariadb-server-10.1/old_data_directory_saved: mariadb-server-10.1/postrm_remove_databases: false
Bug#897926: Update
It seems like the newest version of Nginx has been compiled with `--with-compat`. Just wanted to confirm this, and then if that's the case, this bug can probably be closed. Thanks! -- Andrew M. Brown
Bug#915129: Stop using swftools
Source: jquery-jplayer Severity: serious jquery-jplayer currently depends on swftools for Flash support. swftools however is orphaned, has frequent security issues, is dead upstream (as is Flash). Also, per the package description Flash is entirely a fallback for browsers which don't support HTML5 video (but those are the norm today). Cheers, Moritz
Bug#915128: Dont't include in buster
Source: swftools Severity: serious swftools is orphaned for a year, dead upstream and has frequent security issues. Also, Flash is a thing of the past, so let's drop it from buster (initially filing this bug to out it out of testing, will also sort out the removal, which will take longer). One one rev dep is left in testing (jquery-jplayer), I'll file a separate bug against it. Cheers, Moritz
Bug#907060: linux: ratelimiting hides warnings about uninitialized crng usage
Control: found 907060 4.18.20-2 On Thu 2018-08-23 12:31:29 -0400, Daniel Kahn Gillmor wrote: > root@test:~# cat /proc/cmdline > BOOT_IMAGE=/boot/vmlinuz-4.17.0-3-amd64 > root=UUID=44659876-4a68-4a3a-b3fa-0403eeb0c6ca > ro console=ttyS0,115200n8 > root@test:~# dmesg | tail -n 3 > [2.880287] [drm] Initialized bochs-drm 1.0.0 20130925 for :00:02.0 on > minor 0 > [ 107.680402] random: crng init done > [ 107.681132] random: 7 urandom warning(s) missed due to ratelimiting > root@test:~# I'm continuing to see this problem on 4.18.20-2 (on multiple platforms, actually, incluing 4.18.0-3-powerpc-smp, so it's likely to be generic) i don't understand why the ratelimiting would be hide these useful messages. --dkg
Bug#915127: cloud.debian.org: Please add AWS image for new ARM instances
Package: cloud.debian.org Severity: wishlist Dear Maintainer, AWS have recently announced new instance types that use the 64-bit ARM (aka aarch64) architecture. Machine images are currently available for "Amazon Linux 2", RHEL, Ubuntu and Fedora. It would be great to also have official Debian images. Many thanks, Phil.
Bug#915126: please update treestyletab to Ver.2.6.8 for Mozilla Firefox
Package: webext-treestyletab Version: 2.5.4-2 Severity: normal Dear Maintainer, Please update to Ver.2.6.8 or at the very least 2.6.0 for mozilla firefox. Upstream has released updates at https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled webext-treestyletab depends on no packages. Versions of packages webext-treestyletab recommends: ii firefox-esr 60.3.0esr-1 webext-treestyletab suggests no packages. -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#915125: libasound2-data: Stretch Regression: alsa.conf.d not provided and breaks crouton audio build
Package: libasound2-data Version: 1.1.7-1 Severity: normal Hi, I can install crouton with audio with stretch by running: $ sudo bash ~/Downloads/crouton -r stretch -t audio But it fails when I try with testing/buster: $ sudo bash ~/Downloads/crouton -r buster -t audio Looking into it, it fails on this line: https://github.com/dnschneid/crouton/blob/master/targets/audio#L200 which writes to /usr/share/alsa/alsa.conf.d/10-cras.conf, but that directory doesn't exist. https://github.com/dnschneid/crouton/blob/master/targets/audio#L84 shows that it is installing a minimal set of packages including libasound2 and libasound2-dev. Because libasound2-data doesn't provide /usr/share/alsa/alsa.conf.d/ anymore, the write to 10-cras.conf fails there and the crouton install fails there because of the error. Bug 912680 makes libasound2-plugins provide that directory, but its dependencies are not required to build CRAS, the Crouton Audio Server, and in the interest of minimal installs, I think libasound2-data should provide /usr/share/alsa/alsa.conf.d/ as well, or instead. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: armhf (armv7l) Kernel: Linux 3.8.11 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: unable to detect libasound2-data depends on no packages. libasound2-data recommends no packages. Versions of packages libasound2-data suggests: ii alsa-utils 1.1.7-1 -- no debconf information
Bug#914897: #914897: debootstrap, buster: Please disabled merged /usr by default
Dear Hideki, dear src:debootstrap maintainers, tl;dr: debootstrap maintainers; can you agree to disable "merged /usr" by default now, or are you OK letting the TC decide on this subject? Longer version: As you might be aware, #914897 (initially filed on src:debootstrap) has now been reassigned to the Technical Committee. As, formally, the Maintainer of src:debootstrap is "debian-boot@l.d.o and the current Uploaders", I would like to make sure that the TC is not going to overrule unnecessarily. Hideki, if I read the debootstrap history correctly, you enabled "merged /usr" by default in debootstrap 1.0.102. Given the recent discussion in debian- devel@ (starting at [0]) and on #914897, could you (or anyone speaking as with a "debootstrap maintainer" hat on) state if, either of: * you would be willing to toggle the "merged /usr" default in debootstrap in a subsequent upload; * you maintain that the "merged /usr" default (to yes) is here to stay. Many thanks in advance for your consideration, OdyX [0] https://lists.debian.org/debian-devel/2018/11/msg00354.html P.S. I'm aware that this might sound formal, or dismissive of Julien's statements. I just _really_ don't want the TC to eventually overrule "the debootstrap maintainers" without need.
Bug#915124: xfsprogs: frequent misdetection of atari partition type
Package: xfsprogs Version: 4.9.0+nmu1 Severity: minor Dear Maintainer, I am currently in the process of changing the underlying encryption on many devices. This involves copying data off, changing encryption parameters, copying data back. Changing the underlying encryption (e.g. from aes-cbc-essiv:sha256 to aes-xts-plain64) should pretty much randomly scramble the existing data, and looking at the first blocks, this seems to be the case. However, mkfs.xfs has roughly a 30% chance here of misdetecting random data as "atari partition table format" (this seems to increase with the size of the device, the smallest device I used was 8TB): mkfs.xfs: /dev/mapper/nls112-11 appears to contain a partition table (atari). Which of course is somewhat unsettling :) Looking at http://drac030.krap.pl/APT_spec.pdf, the block doesn't resemble an atari partition at all (no APT magic string and so on). Given the high chance of msidetecting random data for a valid partition, I think the atari partition table detection code should either be improved or disabled by default, as it surely generates many more false positives and true detections. I haven't investigated this in more detail, but it is possible that the code only checks wether a partition fits into the disk, and this would be 100% the case with devices >2TB. Indeed, I can easily reproduce this by running this multiple times: lvcreate -n tempbig -L 4.5t vg_nlsb112 # once only of course :) dd if=/dev/urandom of=/dev/vg_nlsb112/tempbig bs=4096 count=512 mkfs.xfs /dev/vg_nlsb112/tempbig I get a roughly one in seven chance of getting an atari partition table. -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 4.18.20-041820-generic (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/bash Init: systemd (via /run/systemd/system) Versions of packages xfsprogs depends on: ii libblkid1 2.29.2-1+deb9u1 ii libc6 2.27-8 ii libreadline5 5.2+dfsg-3+b1 ii libuuid1 2.29.2-1+deb9u1 xfsprogs recommends no packages. Versions of packages xfsprogs suggests: ii acl 2.2.52-3+b1 ii attr 1:2.4.47-2+b2 pn quota ii xfsdump 3.1.6+nmu2+b1 -- no debconf information
Bug#825970: status?
i see the last commit was back in august. is this stable yet? can it be used or is active work still being done?
Bug#915123: goaccess: New upstream release 1.3 available
Package: goaccess Version: 1:1.2-4 Severity: wishlist Tags: patch Hi, There is a new upstreame release of goaccess (1.3). Since I wanted to test it, I made an updated package myself. Please check https://salsa.debian.org/debian/goaccess/merge_requests/1 on salsa, review, merge, and upload if it's OK :) Cheers, nodens -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages goaccess depends on: ii libbz2-1.01.0.6-9 ii libc6 2.28-1 ii libgeoip1 1.6.12-1 ii libncurses6 6.1+20181013-1 ii libtinfo6 6.1+20181013-1 ii libtokyocabinet9 1.4.48-12 ii zlib1g1:1.2.11.dfsg-1 Versions of packages goaccess recommends: ii geoip-database20181108-1 ii geoip-database-extra 20181108-1 goaccess suggests no packages. -- no debconf information
Bug#915122: extra-cmake-modules: FindQHelpGenerator does not work for cross compilation
Package: extra-cmake-modules Version: 5.51.0-1 File: /usr/share/ECM/find-modules/FindQHelpGenerator.cmake Control: affects -1 + src:kconfig User: helm...@debian.org Usertags: rebootstrap kconfig fails to cross build from source, because it fails to find qhelpgenerator using extra-cmake-modules. The failure is due to a combination of assumptions that don't add up. It's not entirely clear which of them is wrong so I'm filing the bug with extra-cmake-modules now even though it might need a fix elsewhere. kconfig uses FindQHelpGenerator. FindQHelpGenerator looks up Qt5::qmake. Since fixing #913499, qtbase-5-dev supplies /usr/lib/$DEB_HOST_MULTIARCH/qt5/bin/qmake, which is a symbolic link to /usr/bin/$DEB_HOST_GNU_TYPE-qmake, which is our cross wrapper for qmake. Now FindQHelpGenerator.cmake uses the directory part of Qt5::qmake and expects to find a qhelpgenerator inside that directory. Unfortunately, it doesn't find one. qhelpgenerator is only located in /usr/bin, /usr/lib/qt5/bin and /usr/lib/$DEB_BUILD_GNU_TYPE/qt5/bin. The assumption of FindQHelpGenerator.cmake that the directory of Qt5::qmake contains qhelpgenerator is not presently a valid one. I cannot tell whether it should be valid or not. If it should be valid, then some qt package should provide an additional symlink for qhelpgenerator. Otherwise FindQHelpGenerator should use a different way for finding qhelpgenerator. I've Cced Dmitry and Lisandro and hope that they'll weigh in on how this is supposed to work. Then we can figure out where this needs to be fixed and how. Thanks for your help Helmut
Bug#903665: boost1.62: merge request for #903665
control: retitle -1 boost1.67: bali-phy FTBFS on ppc64* control: reassign -1 src:boost1.67 1.67.0-11 Il 13/11/18 18:34, Frédéric Bonnard ha scritto: > Hi Giovanni, > no worries. Thanks for the details, I appreciate your feedback. Ow, I just uploaded boost1.67, but I forgot about this patch. I am applying it now to the repository, so that I do not forget next time. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature
Bug#915109: closed by David Kalnischkies (Re: Bug#915109: apt upgrade needs limit or date cap)
This is not satisfactory. The bug/lacking feature IS DEFINITELY IN APT. From: Debian Bug Tracking System Sent: Friday, November 30, 2018 11:33:06 AM To: Roland Hughes Subject: Bug#915109 closed by David Kalnischkies (Re: Bug#915109: apt upgrade needs limit or date cap) This is an automatic notification regarding your Bug report which was filed against the apt package: #915109: apt upgrade needs limit or date cap It has been closed by David Kalnischkies . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact David Kalnischkies by replying to this email. -- 915109: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915109 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems Disclaimer The information in this email and any attachments may contain proprietary and confidential information that is intended for the addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, retention or use of the contents of this information is prohibited. When addressed to our clients or vendors, any information contained in this e-mail or any attachments is subject to the terms and conditions in any governing contract. If you have received this e-mail in error, please immediately contact the sender and delete the e-mail.
Bug#914332: Debian Bug report logs #914377 - python3: syntax error in rtupdate hook prevents configuration
Pyzo is not compatible with Python-3.7 because using of the reserved word 'async. See also Pyzo on github: https://github.com/pyzo/pyzo/issues/529 Seems to be fixed in Pyzo 4.6.0 and 4.6.1. This bug should be linked to https://bugs.debian.org/914332 Jean-Marc https://6jf.be/keys/ED863AD1.txt pgptjrKz6jaHa.pgp Description: PGP signature
Bug#915099: RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) Raspberry PI Minecraft API
There is an alternative fork of the module on https://github.com/sprintingkiwi/pycraft_mod >. It has seen more development the last few years. Perhaps it is a better alternative? I tested it, and it work great. :) -- Happy hacking Petter Reinholdtsen
Bug#910764: openjfx: segmentation fault in GtkNativeMainLoopThread
Am 30.11.18 um 18:21 schrieb Hans Georg Colle: > Hello Markus, > could you run your application using xorg instead of the xwayland > server (i. e. choose "Gnome unter Xorg" in the gdm3 greeter settings > before logging in), please, and report the result? > I got the same issue running a JavaFX-UI application with xwayland, > too, and its doing fine under Gnome/Xorg. So I believe its rather a > problem concerning xwayland-server than OpenJFX. > Greetings, Georg Hello Georg, I can confirm this issue only happens under Wayland. Upstream tracks the bug at https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8210411 Regards, Markus signature.asc Description: OpenPGP digital signature
Bug#839591: Update keytab-lilo to work on modern Debian systems
Hi,
Here is a refreshed patch (in Git format) to be applied on version 1:24.2-4.
Since it adds a quilt patch, the warnings about white space errors from
git am are normal.
Regards,
--
Raphaël Halimi
From 1854cbba093384d44bb670eb8237ece85f52d6e9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?=
Date: Sun, 2 Oct 2016 16:14:04 +0200
Subject: [PATCH 1/2] Add patch to fix keytab-lilo.pl
---
debian/patches/10_fix-keytab-lilo.patch | 45 +
debian/patches/series | 1 +
2 files changed, 46 insertions(+)
create mode 100644 debian/patches/10_fix-keytab-lilo.patch
diff --git a/debian/patches/10_fix-keytab-lilo.patch b/debian/patches/10_fix-keytab-lilo.patch
new file mode 100644
index 000..343e7b5
--- /dev/null
+++ b/debian/patches/10_fix-keytab-lilo.patch
@@ -0,0 +1,45 @@
+Description: Various fixes for keytab-lilo
+ This patch updates keytab-lilo to work on modern Debian systems:
+ - Support for kbd 2.0.3 format (from Olivier Brunel, see
+ http://www.syslinux.org/archives/2015-December/024690.html)
+ - Use new keymaps ".kmap" extension (from syslinux upstream)
+ - Add headers (from syslinux upstream)
+Author: Raphaël Halimi
+Origin: other
+Last-Update: 2016-10-02
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/keytab-lilo.pl
b/keytab-lilo.pl
+@@ -1,4 +1,8 @@
+ #!/usr/bin/perl
++
++eval { use bytes; };
++eval { binmode STDOUT; };
++
+ $DEFAULT_MAP = "us";
+ $DEFAULT_EXT = ".kmap";
+
+@@ -6,8 +10,8 @@
+ {
+ print STDERR
+ "usage: $0 [ -p old_code=new_code ] ...\n".
+- (" "x(8+length $0))."[path]default_layout[.map] ] ".
+- "[path]kbd_layout[.map]\n";
++ (" "x(8+length $0))."[path]default_layout[.kmap] ] ".
++ "[path]kbd_layout[.kmap]\n";
+ exit 1;
+ }
+
+@@ -44,9 +48,9 @@
+ $empty = 1;
+ while () {
+ chop;
+- if (/^(static\s+)?u_short\s+(\S+)_map\[\S*\]\s+=\s+{\s*$/) {
++ if (/^(static\s+)?(u_|unsigned )short\s+(\S+)_map\[\S*\]\s+=\s+{\s*$/) {
+ die "active at beginning of map" if defined $current;
+- $current = $pfx.":".$2;
++ $current = $pfx.":".$3;
+ next;
+ }
+ undef $current if /^};\s*$/;
diff --git a/debian/patches/series b/debian/patches/series
index 69f49c8..39129ad 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@
07_hardening-cflags+cppflags.patch
08_small-typos-in-manpages.patch
09_fix-manpage-lilo-conf-5.patch
+10_fix-keytab-lilo.patch
--
2.19.1
signature.asc
Description: OpenPGP digital signature
Bug#839596: Please provide keytab-lilo in its own package
Hi,
Here is a refreshed patch (in Git format) to be applied on version 1:24.2-4.
Regards,
--
Raphaël Halimi
From 93281bc01553c0ec1220abbf7253aa7cde26dd57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Halimi?=
Date: Sun, 2 Oct 2016 16:39:58 +0200
Subject: [PATCH 2/2] Split keytab-lilo into its own package
---
debian/control | 12
debian/keytab-lilo.dirs | 1 +
debian/keytab-lilo.install | 1 +
debian/keytab-lilo.manpages | 1 +
debian/lilo.install | 1 -
debian/lilo.manpages| 1 -
6 files changed, 15 insertions(+), 2 deletions(-)
create mode 100644 debian/keytab-lilo.dirs
create mode 100644 debian/keytab-lilo.install
create mode 100644 debian/keytab-lilo.manpages
diff --git a/debian/control b/debian/control
index 16a9a17..b3653be 100644
--- a/debian/control
+++ b/debian/control
@@ -37,3 +37,15 @@ Description: LInux LOader - Documentation for the classic OS boot loader
.
This package contains the old HTML and README documentations of lilo
version 21.5 (of year 2000).
+
+Package: keytab-lilo
+Architecture: all
+Depends: perl, console-data, ${misc:Depends}
+Description: LInux LOader - compile keytables files for use with LILO
+ You can use LILO to manage your Master Boot Record (with a simple text
+ screen, text menu or colorful splash graphics) or call LILO from other
+ Boot-Loaders to jump-start the Linux kernel.
+ .
+ This package contains the keytab-lilo tool, which is a Perl script that can
+ compile keytable files to use with LILO and other tools (for example SYSLINUX,
+ which uses the same keytable format).
diff --git a/debian/keytab-lilo.dirs b/debian/keytab-lilo.dirs
new file mode 100644
index 000..236670a
--- /dev/null
+++ b/debian/keytab-lilo.dirs
@@ -0,0 +1 @@
+usr/sbin
diff --git a/debian/keytab-lilo.install b/debian/keytab-lilo.install
new file mode 100644
index 000..c7a73f8
--- /dev/null
+++ b/debian/keytab-lilo.install
@@ -0,0 +1 @@
+usr/sbin/keytab-lilo
diff --git a/debian/keytab-lilo.manpages b/debian/keytab-lilo.manpages
new file mode 100644
index 000..b53d61e
--- /dev/null
+++ b/debian/keytab-lilo.manpages
@@ -0,0 +1 @@
+man/keytab-lilo.8
diff --git a/debian/lilo.install b/debian/lilo.install
index fbbeb91..89b5eb1 100644
--- a/debian/lilo.install
+++ b/debian/lilo.install
@@ -1,6 +1,5 @@
sbin/lilo
usr/sbin/mkrescue
-usr/sbin/keytab-lilo
usr/sbin/liloconfig
usr/sbin/lilo-uuid-diskid
etc/kernel/post*
diff --git a/debian/lilo.manpages b/debian/lilo.manpages
index 23864c9..2ac0e7e 100644
--- a/debian/lilo.manpages
+++ b/debian/lilo.manpages
@@ -1,4 +1,3 @@
-man/keytab-lilo.8
man/lilo.8
man/lilo.conf.5
man/mkrescue.8
--
2.19.1
signature.asc
Description: OpenPGP digital signature
Bug#915094: Processes stuck in "D" state with inline_data feature enabled.
This is a kernel bug, not an e2fsprogs bug. Can you tell what what version of the kernel you are using? Inline_data is a feature I generally don't recommend using unless you have a specific reason. It's not on by default. How/when did you enable this feature? And what were you hoping to achieve by enabling it? It looks like you were trying to upgrade some packages when you ran into this issue. Was that something you were doing manually? Are you automatically running "apt-get upgrade" out of cron? Regards, - Ted
Bug#915121: Typo in man page resulting in wrong indentation of several subsections
Package: screen Version: 4.6.2-3 Severity: minor Tags: patch Hi, Here is a patch to fix a nasty typo in the manpage. In "CUSTOMIZATION" section, the "displays" subsection has an indented paragraph, but it's not reverted afterwards, making several following subsections (from "digraph" up to and including "resize") wrongly indented twice. This small (one line) patch fixes that. It's in quilt format, with DEP-3 headers. Regards, -- Raphaël Halimi Description: Fix a typo in man page resulting in wrong indentation In "CUSTOMIZATION" section, the "displays" subsection has an indented paragraph, but it's not reverted afterwards, making several following subsections (from "digraph" up to and including "resize") wrongly indented twice. This small (one line) patch fixes that. Author: Raphaël Halimi Forwarded: no Last-Update: 2018-11-30 --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/doc/screen.1 +++ b/doc/screen.1 @@ -1901,6 +1901,7 @@ \*QDisplays\*U needs a region size of at least 10 characters wide and 5 characters high in order to display. .RE +.RE .TP .IR "\fBdigraph\fR " [ preset [ unicode-value ]] .RS 0 signature.asc Description: OpenPGP digital signature
Bug#910764: openjfx: segmentation fault in GtkNativeMainLoopThread
Hello Markus, could you run your application using xorg instead of the xwayland server (i. e. choose "Gnome unter Xorg" in the gdm3 greeter settings before logging in), please, and report the result? I got the same issue running a JavaFX-UI application with xwayland, too, and its doing fine under Gnome/Xorg. So I believe its rather a problem concerning xwayland-server than OpenJFX. Greetings, Georg
Bug#913069: python-uno is also mising in the transition page
On Fri, Nov 30, 2018 at 02:06:07PM +0100, Eric Valette wrote: > FYI : The build did succeed for several platform but unfortunately failed for > amd64 :-( Yeah :( Welcome to experimental ;-) Builds fine on my system, though. I already did start a build when you first posted it but then busy with other stuff/RL/unstable I will upload my hand-build for now to get this fixed. Yes, that is bad but this is experimental after all and we should get this tested (even when this wouldn't be ready in time for buster which would be "squeezing it" in anyway.) Regards, Rene
Bug#915120: shibboleth-sp2 FTBFS with xmltooling 3.0.2
Source: shibboleth-sp2
Version: 2.6.1+dfsg1-2
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/package.php?p=shibboleth-sp2&suite=sid
...
SPConfig.cpp: In member function 'virtual bool
shibsp::SPConfig::instantiate(const char*, bool)':
SPConfig.cpp:427:117: error: no matching function for call to
'xmltooling::PluginManager, const
xercesc_3_2::DOMElement*>::newPlugin(const char [4], xercesc_3_2::DOMElement*)'
setServiceProvider(ServiceProviderManager.newPlugin(XML_SERVICE_PROVIDER,
dummydoc->getDocumentElement()));
^
In file included from SPConfig.h:38,
from internal.h:48,
from SPConfig.cpp:27:
/usr/include/xmltooling/PluginManager.h:97:12: note: candidate: 'T*
xmltooling::PluginManager::newPlugin(const Key&, const Params&,
bool) const [with T = shibsp::ServiceProvider; Key =
std::__cxx11::basic_string; Params = const xercesc_3_2::DOMElement*]'
T* newPlugin(const Key& type, const Params& p, bool
deprecationSupport) const {
^
/usr/include/xmltooling/PluginManager.h:97:12: note: candidate expects 3
arguments, 2 provided
SPConfig.cpp:439:111: error: no matching function for call to
'xmltooling::PluginManager, const
xercesc_3_2::DOMElement*>::newPlugin(const char*, xercesc_3_2::DOMElement*)'
setServiceProvider(ServiceProviderManager.newPlugin(type.get(),
dummydoc->getDocumentElement()));
^
In file included from SPConfig.h:38,
from internal.h:48,
from SPConfig.cpp:27:
/usr/include/xmltooling/PluginManager.h:97:12: note: candidate: 'T*
xmltooling::PluginManager::newPlugin(const Key&, const Params&,
bool) const [with T = shibsp::ServiceProvider; Key =
std::__cxx11::basic_string; Params = const xercesc_3_2::DOMElement*]'
T* newPlugin(const Key& type, const Params& p, bool
deprecationSupport) const {
^
/usr/include/xmltooling/PluginManager.h:97:12: note: candidate expects 3
arguments, 2 provided
make[4]: *** [Makefile:2355: libshibsp_la-SPConfig.lo] Error 1
Bug#915119: dpkg-dev: dpkg-shlibdeps erroneously reports "symbol pthread_once used by libdnssec.so.6.0.0 found in none of the libraries"
Package: dpkg-dev
Version: 1.19.2
Severity: normal
Control: affects -1 libdnssec6
libdnssec.so.6.0.0 links against pthread, and uses pthread_once.
but dpkg-shlibdeps complains that it is found in none of the
libraries.
I think this is a bug in dpkg-shlibdeps. If not, please let me know
what needs to be done to fix libdnssec.so.6.0.0 (feel free to reassign
the bug in that case.
Here's a shell transcript which describes the problem:
0 dkg@alice:~/src/pkg-dns/knot-dns$ dpkg-shlibdeps
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0
dpkg-shlibdeps: warning: binaries to analyze should already be installed in
their package's directory
dpkg-shlibdeps: warning: symbol pthread_once used by
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0 found in none of the libraries
dpkg-shlibdeps: warning: package could avoid a useless dependency if
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0 was not linked against libm.so.6
(it uses none of the library's symbols)
0 dkg@alice:~/src/pkg-dns/knot-dns$ awk '($1 ~ /\.so/) { lib=$1 } /^
pthread_once@/{print lib ":" $0 }' /var/lib/dpkg/info/*.symbols
libpthread.so.0: pthread_once@GLIBC_2.2.5 2.2.5
libpthread.so.0: pthread_once@GLIBC_2.0 2.0
libpthread.so.0: pthread_once@GLIBC_2.16 2.16
libtsan.so.0: pthread_once@Base 4.9
0 dkg@alice:~/src/pkg-dns/knot-dns$ ldd
/usr/lib/x86_64-linux-gnu/libdnssec.so.6.0.0 | grep pthread
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f98bd112000)
0 dkg@alice:~/src/pkg-dns/knot-dns$
thanks for maintaining dpkg-devscripts!
--dkg
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (200,
'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.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)
Versions of packages dpkg-dev depends on:
ii binutils 2.31.1-9
ii bzip2 1.0.6-9
ii libdpkg-perl 1.19.2
ii make 4.2.1-1.2
ii patch 2.7.6-3
ii perl 5.28.0-4
ii tar 1.30+dfsg-3
ii xz-utils 5.2.2-1.3
Versions of packages dpkg-dev recommends:
ii build-essential 12.5
ii clang-4.0 [c-compiler] 1:4.0.1-10+b1
ii clang-6.0 [c-compiler] 1:6.0.1-9.2
ii fakeroot 1.23-1
ii gcc 4:8.2.0-2
ii gcc-6 [c-compiler] 6.5.0-1
ii gcc-7 [c-compiler] 7.3.0-30
ii gcc-8 [c-compiler] 8.2.0-9
ii gnupg2.2.11-1
ii gpgv 2.2.11-1
ii gpgv22.2.11-1
pn libalgorithm-merge-perl
ii tcc [c-compiler] 0.9.27-8
Versions of packages dpkg-dev suggests:
ii debian-keyring 2018.11.25
-- no debconf information
Bug#915088: multipath-tools: installing multipath-tools will force dracut to be removed while it shouldn't.
Dracut is the only tool to create initramfs on many distros and it works fine with multipath so far. Dracut is to initramfs-tools what systemd is to basic initscripts. Dracut is modular and event driven while initramfs-tools is monolithic and linear static. If you look at /usr/lib/dracut/modules.d you'll notice that a module already exists for multipathd. (/usr/lib/dracut/modules.d/90multipath and /usr/lib/dracut/modules.d/90multipath-hostonly) man dracut man dracut.modules man dracut.cmdline See also the module-setup.sh in both 90multipath and 90multipath-hostonly modules Dracut is really a wonderful piece of code that is really easy to understand and that can create really powerful ramfs images. Cheers, Le 30/11/2018 16:01, « Ritesh Raj Sarraf » a écrit : On Fri, 2018-11-30 at 09:10 +, Olivier Lahaye wrote: >* What exactly did you do (or not do) that was effective (or > ineffective)? > Installed multipath-tools using: > apt-get install --no-install-suggests multipath-tools > >* What was the outcome of this action? > dracut was replaced with initramfs-tools because sg3-utils-udev > is > required by multipath-tools and sg3-utils-udev conflicts with > dracut > >* What outcome did you expect instead? > It should be possible to install multipath-tools and use it with > dracut. In other words, it should be possible to do: > apt-get install multipath-tools dracut The problem is that nobody, afaik, has tested the combination of multipath-tools and dracut together. dracut, afair, claims to be a drop-in replacement for initramfs-tools. But I am not sure at all. Right now, multipath-tools has tight integration with initramfs-tools. Also the sg3-utils-udev package ships in modules to add further integration. If dracut can do the equivalent, then we can relax the dependencies. -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
Bug#915099: RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) Raspberry PI Minecraft API
Control: retitle -1 RFP: minetest-mod-rasperrypijam -- Minetest mod - (most of) Raspberry PI Minecraft API [Julien Puydt] > Hi, > > is that an ITP? a RFP? Ah, sorry. I ment it as a RFP for now. I do not know enough about minetest packaging to do it myself. I joined #debian-games in case you want to discuss this further. > I haven't understood what this is about - and I'm not sure my kids > will need such a mod, so I don't think I'll do anything about it. It is about integrating minetest with tools to use scripting to create thinks in minetest. At least my kids find it very interesting to program in python and sonic pi to make things happen in Minecraft, and I would like them to also be able to do the same using minetest. -- Happy hacking Petter Reinholdtsen
Bug#915118: AppArmor profile is missing 'm' permission
Package: postsrsd Version: 1.4-1 Severity: important debian-changes removes the 'm' bit from the postsrsd binary, which means it does not run because that permission was denied. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Bug#915116: In debian-9 QEMU 2.8.1 with accel=tcg segfaults when running in big load
Package: qemu-system-x86_64 root@libvirt-debian-9:/home/qemu# qemu-system-x86_64 -version QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u5) While host is in load, (repoduced 100% while doing kernel compilation) if I try to run qemu with tcg mode it crashes consistently: ex: Set guest startup RAM size to X megs with: root@libvirt-debian-9:/home/qemu# gdb --args qemu-system-x86_64 -machine accel=tcg -m 100 (gdb) bt #0 tcg_out_opc (opc=opc@entry=85, r=r@entry=0, rm=, x=x@entry=0, s=) at ./tcg/i386/tcg-target.inc.c:460 #1 0x55829ed4 in tcg_out_push (reg=, s=0x561c6440 ) at ./tcg/i386/tcg-target.inc.c:703 #2 tcg_target_qemu_prologue (s=0x561c6440 ) at ./tcg/i386/tcg-target.inc.c:2343 #3 tcg_prologue_init (s=s@entry=0x561c6440 ) at ./tcg/tcg.c:394 #4 0x5582052e in tcg_exec_init (tb_size=) at ./translate-all.c:831 #5 0x55945c35 in tcg_init (ms=) at ./accel.c:42 #6 0x55945d6e in accel_init_machine (ms=0x566df080, acc=0x566a82b0) at ./accel.c:70 #7 configure_accelerator (ms=0x566df080) at ./accel.c:109 #8 0x5580fda9 in main (argc=, argv=, envp=) at ./vl.c:4359 When host is not in load there is not problem, it works as expected. root@libvirt-debian-9:/home/qemu# qemu-system-x86_64 -machine accel=tcg -m 100 qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory I am using Debian 9. In debian-testing this is already fixed, so qemu version is the problem here. I didn't bisect the commit that fixed it, if anyone is interesting in backporting I can do that. Thanks, Katerina signature.asc Description: PGP signature
Bug#915117: xdg-desktop-portal: Recommend a backend?
Source: xdg-desktop-portal Version: 1.0.3-1 xdg-desktop-portal's package description says xdg-desktop-portal is designed to be desktop-agnostic, and uses a desktop-environment-specific GUI backend such as xdg-desktop-portal-gtk to provide its functionality. Should xdg-desktop-portal recommend the virtual package xdg-desktop-portal-backend? xdg-desktop-portal-kde in Testing now provides that virtual package, but xdg-desktop-portal-kde was never backported to Stretch. I see that Debian's Flatpak has this so maybe we should just copy it: Recommends: xdg-desktop-portal-gtk | xdg-desktop-portal-backend By the way, I filed https://bugs.debian.org/915115 to propose that meta-kde install the KDE backend by default. Thanks, Jeremy Bicha
Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing
On Fri, 30 Nov 2018 18:01:26 +0200 Jan Groenewald wrote: > There is https://packages.gitlab.com/gitlab/gitlab-ce > > (deb https://packages.gitlab.com/gitlab/gitlab-ce/debian/ stretch main) Sorry, but no. Just no, no, no and no. Those binary dumps are horrible. They are essentially just dumping 2/3 of an outdated(*) Linux system to /opt. Pirate Praveen is doing an awesome job of packaging this very complex piece of software in a proper way and I at least am very grateful for this. Even if it is only available in unstable, it's a lot better than those blobs provided upstream. Cheers, sur5r (*) - Postgres 9.6 - openSSL 1.0.0 (??!) - Python 3.4 ... the list goes on
Bug#915115: meta-kde: Install xdg-desktop-portal-kde by default
Source: meta-kde Version: 5:102 Flatpak recommends xdg-desktop-portal-gtk | xdg-desktop-portal-backend xdg-desktop-portal-backend is a virtual package provided by the GTK and KDE backends. Since there is a KDE backend, I think one of the KDE metapackage should go ahead and install it by default so that a user who installs Flatpak will get the correct KDE integration without needing to take the further action of finding and installing the KDE backend. For reference, the kubuntu-desktop and kubuntu-full metapackages recommend xdg-desktop-portal-kde. By the way, Snap will soon be using xdg-desktop-portal too. Thanks, Jeremy Bicha
Bug#915114: fontconfig-config: Unnecessary dependency on ucf
Package: fontconfig-config Version: 2.13.1-2 Severity: minor While investigating how to reduce the package list for a container in a Debian derivative, I found that fontconfig-config Depends on ucf but doesn't appear to need it. Its only call to ucf since etch (2007) has been to remove all record of /etc/fonts/local.conf when purged, but that's correctly guarded by "if [ -x /usr/bin/ucf ]" (and the dependency is not helpful here in any case, because when a package in the "config files remain" state is purged, the only packages guaranteed to be present are the Essential set). smcv
Bug#903190: ruby-sham-rack: diff for NMU version 1.4.1-1.1
Control: tags 903190 + patch Control: tags 903190 + pending Dear maintainer, I've prepared an NMU for ruby-sham-rack (versioned as 1.4.1-1.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed diff -Nru ruby-sham-rack-1.4.1/debian/changelog ruby-sham-rack-1.4.1/debian/changelog --- ruby-sham-rack-1.4.1/debian/changelog 2017-08-20 19:19:03.0 +0300 +++ ruby-sham-rack-1.4.1/debian/changelog 2018-11-30 18:12:36.0 +0200 @@ -1,3 +1,11 @@ +ruby-sham-rack (1.4.1-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fix FTBFS by no longer trying to install +a nonexisting README.markdown. (Closes: #903190) + + -- Adrian Bunk Fri, 30 Nov 2018 18:12:36 +0200 + ruby-sham-rack (1.4.1-1) unstable; urgency=medium * New upstream release (Closes: #868750) diff -Nru ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs --- ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs 2017-08-20 19:19:03.0 +0300 +++ ruby-sham-rack-1.4.1/debian/ruby-sham-rack.docs 1970-01-01 02:00:00.0 +0200 @@ -1 +0,0 @@ -README.markdown
