Bug#864873: dgit-maint-merge man page should expand on debianization of upstreams releasing tarballs
Hi Sean, Quoting Sean Whitton (2017-11-23 01:25:19) > On Thu, Nov 23 2017, Johannes Schauer wrote: > > Another section that could be improved in the dgit-maint-merge man page is > > "NEW UPSTREAM RELEASES" "When upstream releases only tarballs". > > > > After running "gbp import-orig" the master branch will contain the new > > upstream version but changes from debian/patches are not applied. The > > man page could expand on best practices on how to carry over changes > > from the last upstream version to the new upstream version. > Right. It should at least say that this action needs to be taken. > > What are the best practices you mention? I was actually hoping that as the master mind behind the maint-merge workflow you would tell me that... XD What I did for my package was to manually collect my commits from the earlier upstream version and then re-apply these on top of the new upstream. But surely there should be a better way to handle this? > > And secondly, the section for "When upstream releases only tarballs" should > > at least contain as much information as the section "When upstream tags > > releases in git". So the former could also have some references to how to > > inspect upstream changes and how to run dch. > > Indeed it should. Thanks for agreeing. :) I don't really think I can be of much help here because I'm not familiar enough with git. Stuff like git merge-tree and merge-base is something I never used before. I'm just reporting this wishlist bug from a user perspective. :) Another small question: | "If you want to maintain a copy of your repository on alioth.debian.org, | you should push both the origin and the upstream branches:" Should that not be "both the master and the upstream branches to origin"? And a related side question (that maybe should also have an answer in the man page): What are the recommendations for the upstream branch? For "When upstream tags releases in git" you write "here is no need to maintain a separate 'upstream' branch" but does this also hold for "When upstream releases only tarballs"? Because if I don't push the upstream branch to anywhere, then the steps under "NEW UPSTREAM RELEASES" will fail because "gbp import-orig" doesn't see an upstream branch. So maybe the man page could also expand on the need for an upstream branch if upstream releases tarball and recommendations on where and when it should be pushed or how one can do without it. For example maybe the question can be answered whether the upstream branch can be pushed to dgit-repos or whether alioth has to be used for that. Thanks! cheers, josch signature.asc Description: signature
Bug#882436: Re : Bug#882436: libreoffice-core: Unable to upgrade (conflicts with openjdk-8-jre-headless)
On Thu, Nov 23, 2017 at 06:11:11AM +0100, nicolas.patr...@gmail.com wrote: > > Yes. This is completely intended. See the changelog: > > So, should we send the bug to openjdk’s maintainer? No, obviously not. If you actually read what I wrote I said that there is #876051. It'd be nice if that was fixed, yes, though. And then LO can remove the conflicts. Besides that, I don't consider this a big bug (your filing as minor was correct, imho, anyway). Not every package must be coinstallable with any other package, and this now is the case with libreoffice-core and openjdk-8. Though that is of course bad because openjdk-8 is the default Java, but... Regards, Rene
Bug#881015: Info received (Bug#881015: Info received (Bug#881015: Massive memory leak in ksmserver))
Another precision is that I start most of these games in windowed mode. 2017-11-23 7:09 GMT+01:00 Debian Bug Tracking System : > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian/Kubuntu Qt/KDE Maintainers > > If you wish to submit further information on this problem, please > send it to 881...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 881015: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881015 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#881360: [Debian-med-packaging] /usr/lib/htslib unused by bcftools anyway
Hi, Andreas, I'm not sure if you saw my message below when I sent it originally. I'd appreciate if you could take a look at this issue. regards Afif على الثلاثاء 14 تشرين الثاني 2017 10:10، كتب Afif Elghraoui: > Hi, Andreas, > > On November 14, 2017 7:08:59 AM EST, John Marshall > wrote: >> It appears that since 7 August 2017 >> (0206c3d81e695291f17b780e77e671f95e36860b and >> 608f125011f3d275806598d0093526218dbfc9bf), Debian's bcftools build no >> longer uses /usr/lib/htslib anyway: >> >> bcftools (1.5-1~exp1) experimental; urgency=medium >> >> [ Afif Elghraoui ] >> * Update packaging for new build system >> [snip] >> -- Afif Elghraoui Mon, 07 Aug 2017 20:06:52 -0400 >> >> > > Would you mind reverting the problematic changes to the htslib packaging to > resolve this issue? I took a look at it a few days ago, but it doesn't git > revert cleanly and I wasn't sure if the following commit you made was also > related. > > Thanks and regards > Afif > -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#881015: Info received (Bug#881015: Massive memory leak in ksmserver)
Hi, It looks like launching 3D video games like American Truck Simulator or other ones tends to trigger the leak. Before launching the game, letting KDE run for one night : 4 GB total memory consumption Yesterday evening, right after closing the game : 5 GB Now (early morning) : 7 GB w/ ksmserver as the top memory consumer 2017-11-11 12:15 GMT+01:00 Debian Bug Tracking System : > Thank you for the additional information you have supplied regarding > this Bug report. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian/Kubuntu Qt/KDE Maintainers > > If you wish to submit further information on this problem, please > send it to 881...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 881015: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881015 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#878549: uprightdiff FTBFS with OpenCV 3.2
On Mon, 30 Oct 2017 23:45:28 -0700 Kunal Mehta wrote: > I've asked my sponsor to review and upload the new version. You might want to submit a public sponsorship request: https://mentors.debian.net/sponsors/rfs-howto -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#882122: thunderbird: Thunderbird can't connect to X server, fails to start
Control: tags -1 pending
Hello Jack,
On Sun, Nov 19, 2017 at 01:26:47PM +0100, Jack Henschel wrote:
> Hi Carsten,
>
> thank you for your very quick response!
>
> > Carsten Schoenert hat am 19. November 2017 um
> > 11:33 geschrieben:
> > > Any idea what the issue might be related to?
> > No, not with some more information.
> > I assume you have already restarted your machine to drop possible issues
> > related to kernel, dbus or X updates?
> > Which DE you are using, do have something changed related to the
> > X-server setup? Which graphic setup you are running? Some problems with
> > a nvidia kernel modul in case you use such hardware?
> D-Bus (and its various dependencies) were updated from 1.12.0-1 to
> 1.12.2-1, libgtk-3 from 3.22.25-1 to 3.22.26-1 and
> libdrm-{intel,amd,common} from 2.4.85-1 to 2.4.88-1. So no major
> updates. And yes, I did restart after installing those updates.
>
> I'm using i3 4.14.1-1 with xorg-server 2:1.19.5-1 on an Intel graphics chip.
strange thing... I still can't reproduce it. Im running typecally Gnome3
and Plasma as the main DE.
> > You can also use 'thunderbird --verbose' to see a bit more messages what
> > the wrapper script is doing or try to do.
> The output of thunderbird --verbose was not very helpful:
For me it shows there are no possible side effects and thats helpful at
leats for me. :-)
> $ thunderbird --verbose
> INFO -> [[ ... using verbose mode ... ]]
> DEBUG -> call '/usr/lib/thunderbird/thunderbird '
> No protocol specified
> Unable to init server: Could not connect: Connection refused
> Error: cannot open display: :0
>
> But, looking through the man page, I found the run-mozilla.sh script for
> debugging:
> $ /usr/lib/thunderbird/run-mozilla.sh /usr/lib/thunderbird/thunderbird-bin
In Debian we don't use that old mozilla script as we want some more
things to happen while calling a wrapper. But that wrapper script is
try to find 'thunderbird-bin' first before go over and start 'thunderbird'.
As both thunderbird binaries have the same hashsum they are the same, it
looks then as Mozilla is checking what name was given for running and is
doing some things differently if /u/l/t/thunderbird-bin was given. We
would need to find out more by using strace but without much gain on
that if we know we always should use thunderbird-bin.
...
> And Thunderbird runs!
> Also, directly running /usr/lib/thunderbird/thunderbird-bin works, too!
> Which is really weird because /usr/lib/thunderbird/thunderbird and
> /usr/lib/thunderbird/thunderbird-bin are the same, but only the latter one
> can connect to the X server.
> $ sha256sum /usr/lib/thunderbird/thunderbird*
> 126efa3f01f0d86c9d97702a90f163013ad1667e1a326fd193d61c72e034584e
> /usr/lib/thunderbird/thunderbird
> 126efa3f01f0d86c9d97702a90f163013ad1667e1a326fd193d61c72e034584e
> /usr/lib/thunderbird/thunderbird-bin
> a3f9e5f5820436e7205a0223ce6a7dee89b30bcf626e6de92f43fee4a2c87b24
> /usr/lib/thunderbird/thunderbird-wrapper-helper.sh
> $ ls -l /usr/lib/thunderbird/thunderbird*
> -rwxr-xr-x 1 root root 126040 Oct 17 18:20 /usr/lib/thunderbird/thunderbird
> -rwxr-xr-x 1 root root 126040 Oct 17 18:20
> /usr/lib/thunderbird/thunderbird-bin
> -rw-r--r-- 1 root root 14545 Oct 7 11:35
> /usr/lib/thunderbird/thunderbird-wrapper-helper.sh
>
> What could be the difference between thunderbird and thunderbird-bin?
I really don't know the reason why. I can remember in the past both
binaries have a different size and one of them was used for calling
Thunderbird for running on a remote side. That has changed sometimes
between version 20 and 30 I guess.
Nethermind, I will modify the wrapper script we are using to call
thunderbird-bin with the next upload.
Regards
Carsten
Bug#882436: Re : Bug#882436: libreoffice-core: Unable to upgrade (conflicts with openjdk-8-jre-headless)
Le 22/11/2017 23:45:14, Rene Engelhard a écrit : > No, if you file bugs PLEASE a bit of carefulness. This is the version > you try to upgrade from... Excuse me, I did not touch this part of the report. > Yes. This is completely intended. See the changelog: So, should we send the bug to openjdk’s maintainer? Regards, nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Bug#882460: simulpic FTCBFS: toolchain variables in Makefile incompatible with dh_auto_build
Source: simulpic Version: 1:2005-1-28-9 Tags: patch User: hel...@debian.org Usertags: rebootstrap simulpic fails to cross build from source, due to bugs in the (patched) Makefile. The final failure comes when the build architecture compiler g++ is invoked on host architecture objects. Usually one would use $(CXX) here, but $(CXX) contains $(CFLAGS). This is a problem of its own as dh_auto_build replaces $(CXX) and thus clears those $(CFLAGS). So Move the $(CFLAGS) into the proper place, $(CXXFLAGS), and use $(CXX) in the way it usually is used. After doing so, simulpic cross builds successfully. Please consider applying the attached patch. Helmut Index: simulpic-2005-1-28/Makefile === --- simulpic-2005-1-28.orig/Makefile +++ simulpic-2005-1-28/Makefile @@ -8,16 +8,16 @@ ALLSRC=$(IECSRC) $(SRCS) $(INCLUDES) Makefile Copyright README simulpic.doc simulpic.1 -CFLAGS= -g -fPIC -O2 -Wall -fno-exceptions \ +CXXFLAGS= -g -fPIC -O2 -Wall -fno-exceptions \ -I. -I/usr/include/g++-3 -D_FILE_OFFSET_BITS=64 -CXX= g++ $(CFLAGS) +CXX= g++ OBJS= $(SRCS:.cc=.o) simulpic: $(OBJS) - g++ $(LDFLAGS) -g -o simulpic $(OBJS) + $(CXX) $(LDFLAGS) -g -o simulpic $(OBJS) clean: - rm -f $(OBJS) a.out *.core simulpic
Bug#882459: astronomical-almanac FTCBFS: uses the build architecture toolchain
Source: astronomical-almanac Version: 5.6-4 Tags: patch User: helm...@debian.org Usertags: rebootstrap astronomical-almanac fails to cross build from source. The packaging doesn't pass cross compilers to the make invocation. This task can be deferred to dh_auto_build easily. Then it still fails, because install uses the build architecture strip. Stripping at install time is bad, because it breaks -dbgsym generation. Simply not stripping here is the solution. After doing both, astronomical-almanac cross builds a -dbgsym package successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru astronomical-almanac-5.6/debian/changelog astronomical-almanac-5.6/debian/changelog --- astronomical-almanac-5.6/debian/changelog 2012-03-02 20:00:43.0 +0100 +++ astronomical-almanac-5.6/debian/changelog 2017-11-23 05:38:08.0 +0100 @@ -1,3 +1,12 @@ +astronomical-almanac (5.6-4.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: (Closes: #-1) ++ Let dh_auto_build pass cross compilers to make. ++ Do not strip at install time, defer to dh_strip. + + -- Helmut Grohne Thu, 23 Nov 2017 05:38:08 +0100 + astronomical-almanac (5.6-4) unstable; urgency=low * new maintainer (closes: #636405) diff --minimal -Nru astronomical-almanac-5.6/debian/rules astronomical-almanac-5.6/debian/rules --- astronomical-almanac-5.6/debian/rules 2012-03-02 14:45:17.0 +0100 +++ astronomical-almanac-5.6/debian/rules 2017-11-23 05:38:08.0 +0100 @@ -25,9 +25,6 @@ else CFLAGS += -O2 endif -ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS))) -INSTALL_PROGRAM += -s -endif ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) MAKEFLAGS += -j$(NUMJOBS) @@ -48,7 +45,7 @@ dh_testdir # compile the package. - $(MAKE) moonrise conjunct aa + dh_auto_build -- moonrise conjunct aa touch build-stamp
Bug#882458: mimetex FTCBFS: uses the build architecture compiler
Source: mimetex Version: 1.74-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap mimetex fails to cross build from source, because it uses the build architecture compiler. After making compiler invocations substitutable and letting dh_auto_build pass substitutions, mimetex cross builds successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru mimetex-1.74/debian/changelog mimetex-1.74/debian/changelog --- mimetex-1.74/debian/changelog 2014-07-14 22:16:16.0 +0200 +++ mimetex-1.74/debian/changelog 2017-11-23 05:33:02.0 +0100 @@ -1,3 +1,10 @@ +mimetex (1.74-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use cross compilers. (Closes: #-1) + + -- Helmut Grohne Thu, 23 Nov 2017 05:33:02 +0100 + mimetex (1.74-1) unstable; urgency=low * New upstream release diff --minimal -Nru mimetex-1.74/debian/patches/Makefile.diff mimetex-1.74/debian/patches/Makefile.diff --- mimetex-1.74/debian/patches/Makefile.diff 2014-07-14 22:02:00.0 +0200 +++ mimetex-1.74/debian/patches/Makefile.diff 2017-11-23 05:32:56.0 +0100 @@ -4,13 +4,13 @@ +all: mimetex + +mimetex: mimetex.o gifsave.o -+ gcc -DAA mimetex.o gifsave.o -lm -o mimetex `dpkg-buildflags --get LDFLAGS` ++ $(CC) -DAA mimetex.o gifsave.o -lm -o mimetex `dpkg-buildflags --get LDFLAGS` + +mimetex.o: -+ gcc -DAA -c mimetex.c `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get CPPFLAGS` ++ $(CC) -DAA -c mimetex.c `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get CPPFLAGS` + +gifsave.o: -+ gcc -DAA -c gifsave.c `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get CPPFLAGS` ++ $(CC) -DAA -c gifsave.c `dpkg-buildflags --get CFLAGS` `dpkg-buildflags --get CPPFLAGS` + +clean: + rm -f mimetex mimetex.o gifsave.o diff --minimal -Nru mimetex-1.74/debian/rules mimetex-1.74/debian/rules --- mimetex-1.74/debian/rules 2014-07-14 22:13:19.0 +0200 +++ mimetex-1.74/debian/rules 2017-11-23 05:32:21.0 +0100 @@ -18,7 +18,7 @@ build-stamp: dh_testdir - make + dh_auto_build touch build-stamp
Bug#882457: rblcheck FTCBFS: uses the build architecture compiler
Source: rblcheck Version: 20020316-9 Tags: patch User: helm...@debian.org Usertags: rebootstrap rblcheck fails to cross build from source, because it uses the build architecture compiler. Including /usr/share/dpkg/buildtools.mk fixes that and makes rblcheck cross build successfully. Please consider applying the attached patch. Helmut diff --minimal -Nru rblcheck-20020316/debian/changelog rblcheck-20020316/debian/changelog --- rblcheck-20020316/debian/changelog 2016-12-28 16:49:41.0 +0100 +++ rblcheck-20020316/debian/changelog 2017-11-23 05:26:56.0 +0100 @@ -1,3 +1,10 @@ +rblcheck (20020316-9.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host architecture compiler. (Closes: #-1) + + -- Helmut Grohne Thu, 23 Nov 2017 05:26:56 +0100 + rblcheck (20020316-9) unstable; urgency=medium * Switched to debhelper compat level 10. diff --minimal -Nru rblcheck-20020316/debian/rules rblcheck-20020316/debian/rules --- rblcheck-20020316/debian/rules 2016-12-28 16:36:00.0 +0100 +++ rblcheck-20020316/debian/rules 2017-11-23 05:26:54.0 +0100 @@ -3,6 +3,7 @@ DPKG_EXPORT_BUILDFLAGS = 1 -include /usr/share/dpkg/buildflags.mk +-include /usr/share/dpkg/buildtools.mk D := $(CURDIR)/debian/rblcheck
Bug#852146: Changing board size while game window is maximized results in clipped output
Control: tags -1 fixed-upstream This is fixed upstream: https://git.tartarus.org/?p=simon/puzzles.git;a=commit;h=f03e8d30a038f740ea0bfe21474de5df69093893
Bug#882456: billard-gl FTCBFS: uses the build architecture compiler for linking
Source: billard-gl Version: 1.75-16 Tags: patch User: helm...@debian.org Usertags: rebootstrap billard-gl fails to cross build from source, because it uses the build architecture compiler for linking. For compilation it uses standard variables CC and CXX that get substituted by dh_auto_build, but for linking it uses LINK=g++. Substituting that one as well, makes the cross build succeed. This problem could be fixed upstream if they assigned LINK = $(CXX). Please consider applying the attached patch. Helmut diff --minimal -Nru billard-gl-1.75/debian/changelog billard-gl-1.75/debian/changelog --- billard-gl-1.75/debian/changelog2015-11-05 16:58:35.0 +0100 +++ billard-gl-1.75/debian/changelog2017-11-23 05:19:30.0 +0100 @@ -1,3 +1,10 @@ +billard-gl (1.75-16.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Also use the cross toolchain for linking. (Closes: #-1) + + -- Helmut Grohne Thu, 23 Nov 2017 05:19:30 +0100 + billard-gl (1.75-16) unstable; urgency=medium * Team upload. diff --minimal -Nru billard-gl-1.75/debian/rules billard-gl-1.75/debian/rules --- billard-gl-1.75/debian/rules2015-11-05 16:58:35.0 +0100 +++ billard-gl-1.75/debian/rules2017-11-23 05:17:19.0 +0100 @@ -20,6 +20,9 @@ %: dh $@ -Dsrc +override_dh_auto_build: + dh_auto_build -- 'LINK=$$(CXX)' + override_dh_auto_install: override_dh_installchangelogs:
Bug#882455: pcmanfm: hangs system when startx is used to initiate joes window manager
Package: pcmanfm Version: 1.2.5-3 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/2 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 pcmanfm depends on: ii libatk1.0-0 2.26.0-2 ii libc62.24-17 ii libcairo21.15.8-2 ii libfm-gtk4 1.2.5-1 ii libfm4 1.2.5-1 ii libfontconfig1 2.12.3-0.2 ii libfreetype6 2.8.1-0.1 ii libgdk-pixbuf2.0-0 2.36.11-1 ii libglib2.0-0 2.54.1-1 ii libgtk2.0-0 2.24.31-2 ii libpango-1.0-0 1.40.12-1 ii libpangocairo-1.0-0 1.40.12-1 ii libpangoft2-1.0-01.40.12-1 ii libx11-6 2:1.6.4-3 ii shared-mime-info 1.9-2 Versions of packages pcmanfm recommends: ii gnome-icon-theme 3.12.0-2 ii gvfs-backends 1.34.1-1+b1 ii gvfs-fuse 1.34.1-1+b1 ii lxqt-policykit [polkit-1-auth-agent] 0.11.1-2 ii oxygen-icon-theme 5:5.37.0-2 pcmanfm suggests no packages. I'm installing a minimal system with no preselected packages. Installation is OK through X11 and menu and sudo, etc. Installation of JWM is OK as well. Then I use aptitude to install pcmanfm. The package is huge: 423 pkgs, 712 MB. Goes slowly. Then running startx goes very slowly and hangs eventually on a screen showing some kind of a bird (origami, not LXDE). System frozen. On reboot, I do purge pcmanfm, and only 2 packages are removed. startx again hangs eventually with the same bird. This happened twice. So, I gave up and installed LXDE-core. PCManFM works OK there, but I miss JWM. The problem has something to with installing pcmanfm with LXDE. -- no debconf information
Bug#560029: "new game" can't be undone
Control: tags -1 fixed-upstream This is fixed upstream: https://git.tartarus.org/?p=simon/puzzles.git;a=commit;h=b9b73adb53b3ffb09a2e8c9682351bf892634470
Bug#882443: expect: autoexpect does not find tclsh8.6
Hi Stanislas, On Thu, Nov 23, 2017 at 2:32 AM, Stanislas M. wrote: > > Dear Maintainer, > > autoexpect exits with message: > > /usr/bin/autoexpect: 4: exec: tclsh8.6: not found > > Versions of packages expect recommends: > pn tcl8.6 expect recommends tcl8.6. If you haven't installed it then you should have a good reason for that. Is there one? Cheers! -- Sergei Golovan
Bug#587158: Bug 587158
Hi,
I had the same issue ("bluetoothd[]: D-Bus setup failed: Connection is
not allowed to own the service "org.bluez" due to security policies in
the configuration file file").
The root cause of the issue seems to be that the configuration file
/etc/dbus-1/system.d/bluetooth.conf
was missing on my system. (etckeeper reports that the file was removed on
2017-07-05, if that's any help.)
For the record, this could not be resolved by doing
aptitude reinstall bluez
or the equivalent sequence (remove + install); these did not reinstall
the missing file.
I corrected by doing
aptitude purge bluez
aptitude install bluez
The former version on my system (reported during the purge operation) was
bluez (5.47-1), although this probably is not the version that caused
the problem.
S.
Bug#882454: gerbera: FTBFS on hurd-i386: Gerbera was unable to deterimine the host OS.
Source: gerbera Version: 1.1.0+dfsg-2 Severity: important Tags: upstream Justification: fails to build from source User: debian-h...@lists.debian.org Usertags: hurd-i386 Builds of gerbera for hurd-i386 (admittedly not a release architecture) have been failing per the below excerpt from https://buildd.debian.org/status/fetch.php?pkg=gerbera&arch=hurd-i386&ver=1.1.0%2Bdfsg-2&stamp=1511312309&raw=0: CMake Error at CMakeLists.txt:314 (message): Gerbera was unable to deterimine the host OS. Please report this. Value of CMAKE_SYSTEM_NAME: GNU Could you please take a look? With any luck, the Linux settings will make a decent starting point. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#882453: airspyhf: FTBFS on non-Linux: Could NOT find LIBUSB
Source: airspyhf Version: 1.0-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-h...@lists.debian.org Usertags: hurd-i386 Hi, Maitland. Builds of airspyhf for hurd-i386 and kfreebsd-* (admittedly not release architectures) have been failing. As detailed in https://buildd.debian.org/status/fetch.php?pkg=airspyhf&arch=hurd-i386&ver=1.0-1&stamp=1511278923&raw=0 https://buildd.debian.org/status/fetch.php?pkg=airspyhf&arch=kfreebsd-amd64&ver=1.0-1&stamp=1511290774&raw=0 https://buildd.debian.org/status/fetch.php?pkg=airspyhf&arch=kfreebsd-i386&ver=1.0-1&stamp=1511279721&raw=0 the hurd-i386 build reports -- Checking for module 'libusb-1.0' -- No package 'libusb-1.0' found -- Could NOT find LIBUSB (missing: LIBUSB_LIBRARIES LIBUSB_INCLUDE_DIR) and the kfreebsd-* builds fare only marginally better: -- Checking for module 'libusb-1.0' -- Found libusb-1.0, version 1.0.13 -- Could NOT find LIBUSB (missing: LIBUSB_LIBRARIES) Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#882452: FTBFS: unknown opcode pause in delaunay_3d.cpp
Source: ovito Version: 2.9.0+dfsg1-5 Severity: important Tags: upstream Justification: fails to build from source (but built successfully in the past) User: debian-h...@lists.debian.org Usertags: hppa Builds of ovito for hppa, m68k, powerpc, and ppc64 (all admittedly non-release architectures) have been failing lately with variants of /tmp/ccA1UlEM.s: Assembler messages: /tmp/ccA1UlEM.s:12621: Error: Unknown opcode: `pause' src/3rdparty/geogram/CMakeFiles/geogram.dir/build.make:425: recipe for target 'src/3rdparty/geogram/CMakeFiles/geogram.dir/delaunay/delaunay_3d.cpp.o' failed as detailed in https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=hppa&ver=2.9.0%2Bdfsg1-5&stamp=1511233991&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=m68k&ver=2.9.0%2Bdfsg1-5&stamp=1511332288&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=powerpc&ver=2.9.0%2Bdfsg1-5&stamp=1511222775&raw=0 https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=ppc64&ver=2.9.0%2Bdfsg1-5&stamp=1511219276&raw=0 Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#882451: ovito: FTBFS on armel: QOpenGLFunctions_* does not name a type
Source: ovito Version: 2.9.0+dfsg1-5 Severity: important Tags: upstream Justification: fails to build from source User: debian-...@lists.debian.org Usertags: armel Builds of ovito for armel have been failing lately as detailed in https://buildd.debian.org/status/fetch.php?pkg=ovito&arch=armel&ver=2.9.0%2Bdfsg1-5&stamp=1511236739&raw=0 with a cascade of errors starting with /<>/ovito-2.9.0+dfsg1/src/opengl_renderer/OpenGLSceneRenderer.h:255:2: error: 'QOpenGLFunctions_2_0' does not name a type; did you mean 'QOpenGLFunctions'? IIRC, Qt uses GLES rather than traditional OpenGL here. Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#806513: ITP: defcon -- set of UFO based objects for use in font editing applications
Control: tags -1 +pending defcon has been uploaded to the Debian NEW queue. Thanks, Jeremy Bicha
Bug#882450: golang-github-alecthomas-chroma: FTBFS w/gccgo: Name undefined
Source: golang-github-alecthomas-chroma
Version: 0.1.1+git20171116.9c81d25-1
Severity: important
Justification: fails to build from source
Builds of golang-github-alecthomas-chroma for architectures using
gccgo on which the compiler didn't crash altogether failed with a pile
of errors of the form
src/github.com/alecthomas/chroma/lexers/c.go:46:21: error: reference to
undefined name 'Name'
{`[a-zA-Z_]\w*`, Name, nil},
as detailed in
https://buildd.debian.org/status/fetch.php?pkg=golang-github-alecthomas-chroma&arch=mips&ver=0.1.1%2Bgit20171116.9c81d25-1&stamp=1511279629&raw=0
https://buildd.debian.org/status/fetch.php?pkg=golang-github-alecthomas-chroma&arch=mips64el&ver=0.1.1%2Bgit20171116.9c81d25-1&stamp=1511288473&raw=0
https://buildd.debian.org/status/fetch.php?pkg=golang-github-alecthomas-chroma&arch=s390x&ver=0.1.1%2Bgit20171116.9c81d25-1&stamp=1511278679&raw=0
https://buildd.debian.org/status/fetch.php?pkg=golang-github-alecthomas-chroma&arch=alpha&ver=0.1.1%2Bgit20171116.9c81d25-1&stamp=1511292496&raw=0
https://buildd.debian.org/status/fetch.php?pkg=golang-github-alecthomas-chroma&arch=powerpc&ver=0.1.1%2Bgit20171116.9c81d25-1&stamp=1511278856&raw=0
I'm not sure offhand why s390x used gccgo, since golang-1.9 does
appear to be available there.
At any rate, could you please take a look?
Thanks!
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#877555: libgegl-dev should supply VAPI bindings
If you check the build logs, you can see: checking for vapigen... /usr/bin/vapigen and later: Vala support:yes Also if you do a search for dh_missing, you can see what files are not being installed. As far as I can tell, there are no vapi files anywhere and there is not an obvious thing wrong in the packaging. https://buildd.debian.org/status/package.php?p=gegl (Click Installed to see the build log) Thanks, Jeremy Bicha
Bug#882449: RFP: ruby-paperclip-av-transcoder -- Audio/Video Transcoder for Paperclip using FFMPEG/Avconv
Package: wnpp Severity: wishlist * Package name: ruby-paperclip-av-transcoder Version : 0.6.4 Upstream Author : Omar "owahab" Abdel-Wahab * URL : https://github.com/ruby-av/paperclip-av-transcoder * License : MIT https://github.com/ruby-av/paperclip-av-transcoder/blob/master/LICENSE.txt Programming Lang: Ruby Description : Audio/Video Transcoder for Paperclip using FFMPEG/Avconv Audio/Video Transcoder for Paperclip using FFMPEG/Avconv. (Relies on ruby-av API)
Bug#879960: libqt5sql5-psql: [libqt5sql5-psql] basic support postgresql-10
Hi Dmitry, This has been fixed in Qt 5.9.3. See ChangeId: Ib19ae7ba426f262e80c52670e7ecb3532ff460a0 https://codereview.qt-project.org/#/c/209141/ The patch: https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=commitdiff;h=435c4b2ccbbb7284918dd2d4a14f8e44c3977d98;hp=ad36da8ff416501e249beb098e5b84eaa2fba43d --- Sincerely yours/С уважением, Damir Islamov/Дамир Исламов 0xB5653FEF.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Bug#882448: RFP: ruby-av -- Programmable Ruby interface for FFMPEG/Libav
Package: wnpp Severity: wishlist * Package name: ruby-av Version : 0.9.0 Upstream Author : Omar "owahab" Abdel-Wahab * URL : https://github.com/ruby-av/av * License : MIT https://github.com/ruby-av/av/blob/master/LICENSE.txt Programming Lang: Ruby Description : Programmable Ruby interface for FFMPEG/Libav A Ruby Programmable interface for FFmpeg and Libav. The idea is to have a common API for both CLIs.
Bug#599585: did you receive my previous email ?
I spand a long time to solve it... :\ sudo apt-get remove --purge slapd ldap-utils ldapscripts sudo rm -R /var/backups/unknown-* sudo apt-get install slapd ldap-utils ldapscripts sudo rm -R /var/backups/unknown-* sudo dpkg-reconfigure slapd and finally it worked as expected with the configuration I desired... On Thu, 1 Sep 2016 03:53:15 -0300 (ART) Friedrich Mayrhofer wrote: > > -- > Hello, > > This is the second time i am sending you this mail.I, Friedrich Mayrhofer and my wife has Donate $ 1,000,000.00 USD > to You, Email Me personally for more details. > > Regards. > > Friedrich Mayrhofer > >
Bug#773294: tracker.debian.org: add support for the vcswatch service
On Wed, 2017-11-22 at 15:44 +0100, Pierre-Elliott Bécue wrote: > Would you like a QA link for each package? Yes, it acts as promotion for the service so more folks know about it. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#882118: ITP: glyphsinfo -- Glyphs info used inside Glyphs.app
Control: tags -1 +pending Uploaded to the Debian NEW queue. Thanks, Jeremy Bicha
Bug#882447: pyzor: please make the build reproducible
Source: pyzor
Version: 1:1.0.0-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
Hi,
Whilst working on the Reproducible Builds effort [0], we noticed
that pyzor could not be built reproducibly.
This was because it was including the memory addresses of an internal
dispatch table in the documentation. We fix that by making them
"private."
Patch attached.
[0] https://reproducible-builds.org/
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
--- a/debian/patches/reproducible-build.patch 1970-01-01 09:00:00.0
+0900
--- b/debian/patches/reproducible-build.patch 2017-11-23 10:34:09.956545410
+0900
@@ -0,0 +1,24 @@
+Description: Make the build reproducible
+Author: Chris Lamb
+Last-Update: 2017-11-23
+
+--- pyzor-1.0.0.orig/pyzor/server.py
pyzor-1.0.0/pyzor/server.py
+@@ -285,7 +285,7 @@ class RequestHandler(SocketServer.Datagr
+ self.client_address[0])
+ # Get a handle to the appropriate method to execute this operation.
+ try:
+-dispatch = self.dispatches[opcode]
++dispatch = self._dispatches[opcode]
+ except KeyError:
+ raise NotImplementedError("Requested operation is not "
+ "implemented.")
+@@ -398,7 +398,7 @@ class RequestHandler(SocketServer.Datagr
+ self.response["Count"] = "%d" % record.r_count
+ self.response["WL-Count"] = "%d" % record.wl_count
+
+-dispatches = {
++_dispatches = {
+ 'ping': None,
+ 'pong': handle_pong,
+ 'info': handle_info,
--- a/debian/patches/series 2017-11-23 10:30:38.825305023 +0900
--- b/debian/patches/series 2017-11-23 10:34:08.796510172 +0900
@@ -1 +1,2 @@
remove-exernal-resources.patch
+reproducible-build.patch
Bug#882446: geocode-glib: please make the build reproducible
Source: geocode-glib Version: 3.25.4.1-2 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, Whilst working on the Reproducible Builds effort [0], we noticed that geocode-glib could not be built reproducibly. Patch attached. [0] https://reproducible-builds.org/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- --- a/debian/patches/reproducible-build.patch 1970-01-01 09:00:00.0 +0900 --- b/debian/patches/reproducible-build.patch 2017-11-23 10:29:17.645171554 +0900 @@ -0,0 +1,15 @@ +Description: Make the build reproducible +Author: Chris Lamb +Last-Update: 2017-11-23 + +--- geocode-glib-3.25.4.1.orig/geocode-glib/geocode-enum-types.h.in geocode-glib-3.25.4.1/geocode-glib/geocode-enum-types.h.in +@@ -9,7 +9,7 @@ G_BEGIN_DECLS + + /*** BEGIN file-production ***/ + +-/* enumerations from "@filename@" */ ++/* enumerations from "@basename@" */ + /*** END file-production ***/ + + /*** BEGIN value-header ***/ --- a/debian/patches/series 1970-01-01 09:00:00.0 +0900 --- b/debian/patches/series 2017-11-23 10:29:16.253005677 +0900 @@ -0,0 +1 @@ +reproducible-build.patch
Bug#882445: Proposed change of offensive packages to -offensive
Sean Whitton dijo [Wed, Nov 22, 2017 at 05:18:37PM -0700]: > > So to be concrete, how about this: > > > > N. Packages with potentially offensive content > > > > As a maintainer you should make a judgement about whether the > > contents of a package is appropriate to include, whether it needs > > any kind of content warning, and whether some parts should be split > > out into a separate package (so that users who want to avoid certain > > parts can do so). In making these decisions you should take into > > account the project's views as expressed in our Diversity Statement. > > > > If you split out (potentially) offensive or disturbing material into > > a separate package, you should usually mark this in the package name > > by adding "-offensive". For example, "cowsay" vs > > "cowsay-offensive". In this situation the "-offensive" package can > > be Suggested by the core package(s), but should not be Recommended > > or Depended on, so that it is not installed by default. > > I second this patch. I suggest we add it as section 3.1.1, i.e., as a > subsection to 3.1 "The package name". > > Iain, Gunnar and Steve: could you repeat your seconding of this patch to > this debian-policy bug, please? Kindly quote the above text that you > are seconding. > > For posterity, the rest of the discussion outside of this bug may be > found here: https://lists.debian.org/debian-devel/2017/11/msg00209.html Right. I second this patch. Thanks, Sean, for doing the administrative steps! signature.asc Description: PGP signature
Bug#864873: dgit-maint-merge man page should expand on debianization of upstreams releasing tarballs
control: tag -1 -patch control: owner -1 ! Hello, On Thu, Nov 23 2017, Johannes Schauer wrote: > Another section that could be improved in the dgit-maint-merge man > page is "NEW UPSTREAM RELEASES" "When upstream releases only > tarballs". > > After running "gbp import-orig" the master branch will contain the new > upstream version but changes from debian/patches are not applied. The > man page could expand on best practices on how to carry over changes > from the last upstream version to the new upstream version. Right. It should at least say that this action needs to be taken. What are the best practices you mention? > And secondly, the section for "When upstream releases only tarballs" > should at least contain as much information as the section "When > upstream tags releases in git". So the former could also have some > references to how to inspect upstream changes and how to run dch. Indeed it should. -- Sean Whitton signature.asc Description: PGP signature
Bug#882445: Proposed change of offensive packages to -offensive
Package: debian-policy Severity: normal Tags: patch User: debian-pol...@packages.debian.org Usertags: normative Hello Ian, Iain, Gunnar, Steve, On Wed, Nov 22 2017, Ian Jackson wrote: > So to be concrete, how about this: > > N. Packages with potentially offensive content > > As a maintainer you should make a judgement about whether the > contents of a package is appropriate to include, whether it needs > any kind of content warning, and whether some parts should be split > out into a separate package (so that users who want to avoid certain > parts can do so). In making these decisions you should take into > account the project's views as expressed in our Diversity Statement. > > If you split out (potentially) offensive or disturbing material into > a separate package, you should usually mark this in the package name > by adding "-offensive". For example, "cowsay" vs > "cowsay-offensive". In this situation the "-offensive" package can > be Suggested by the core package(s), but should not be Recommended > or Depended on, so that it is not installed by default. I second this patch. I suggest we add it as section 3.1.1, i.e., as a subsection to 3.1 "The package name". Iain, Gunnar and Steve: could you repeat your seconding of this patch to this debian-policy bug, please? Kindly quote the above text that you are seconding. For posterity, the rest of the discussion outside of this bug may be found here: https://lists.debian.org/debian-devel/2017/11/msg00209.html -- Sean Whitton signature.asc Description: PGP signature
Bug#882444: xrandr lists modes that it then cannot find
Package: x11-xserver-utils
Version: 7.7+7+b1
File: /usr/bin/xrandr
xrandr lists modes that it then cannot find.
$ xrandr|perl -anwle 'for($F[0]){print if /x/;}'|xargs -n 1 xrandr --dryrun
--output LVDS-1 --mode
crtc 0: 1366x768 59.99 +0+0 "LVDS-1"
crtc 0: disable
screen 0: 1360x768 359x203 mm 96.09dpi
crtc 0: 1360x768 59.80 +0+0 "LVDS-1"
crtc 0: disable
screen 0: 1024x768 270x203 mm 96.09dpi
crtc 0: 1024x768 60.00 +0+0 "LVDS-1"
xrandr: cannot find mode 960x720
xrandr: cannot find mode 928x696
xrandr: cannot find mode 896x672
xrandr: cannot find mode 960x600
xrandr: cannot find mode 960x540
crtc 0: disable
screen 0: 800x600 211x158 mm 96.09dpi
crtc 0: 800x600 60.32 +0+0 "LVDS-1"
xrandr: cannot find mode 840x525
xrandr: cannot find mode 800x512
xrandr: cannot find mode 700x525
xrandr: cannot find mode 640x512
xrandr: cannot find mode 720x450
crtc 0: disable
screen 0: 640x480 169x126 mm 96.09dpi
crtc 0: 640x480 59.94 +0+0 "LVDS-1"
xrandr: cannot find mode 680x384
xrandr: cannot find mode 576x432
xrandr: cannot find mode 512x384
xrandr: cannot find mode 400x300
xrandr: cannot find mode 320x240
Bug#864873: dgit-maint-merge man page should expand on debianization of upstreams releasing tarballs
On Fri, 30 Jun 2017 21:47:25 +0100 Sean Whitton wrote: > On Fri, Jun 16, 2017 at 01:07:04PM +0100, Sean Whitton wrote: > > Here's a patch, though I think we need to wait for #864881. > > Here is an updated patch taking into account the gbp maintainer's resolution > of #864881. Cool, thanks! Another section that could be improved in the dgit-maint-merge man page is "NEW UPSTREAM RELEASES" "When upstream releases only tarballs". After running "gbp import-orig" the master branch will contain the new upstream version but changes from debian/patches are not applied. The man page could expand on best practices on how to carry over changes from the last upstream version to the new upstream version. And secondly, the section for "When upstream releases only tarballs" should at least contain as much information as the section "When upstream tags releases in git". So the former could also have some references to how to inspect upstream changes and how to run dch. Thanks! cheers, josch signature.asc Description: signature
Bug#882443: expect: autoexpect does not find tclsh8.6
Package: expect Version: 5.45-7+deb9u1 Severity: normal Dear Maintainer, autoexpect exits with message: /usr/bin/autoexpect: 4: exec: tclsh8.6: not found -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages expect depends on: ii libc6 2.24-11+deb9u1 ii libtcl8.6 8.6.6+dfsg-1+b1 ii tcl-expect 5.45-7+deb9u1 Versions of packages expect recommends: pn tcl8.6 pn tk8.6 expect suggests no packages. -- no debconf information
Bug#881097: To be removed from wheezy as well
On Wed, Nov 22, 2017 at 09:00:59PM +0100, Emilio Pozuelo Monfort wrote: > On 08/11/17 20:19, Ola Lundqvist wrote: > > Hi > > > > Considering that this package is about to be removed from jessie I > > guess it should be removed from wheezy too. How is that done? Should I > > contact the FTP maintainers about it, or do we simply ignore the > > issue? > > We don't have point releases, so I'm not sure we can get a package removed at > this stage without extra work by the ftp masters. So our options would be: > > - mark as no-dsa if it's not important enough > - mark as unsupported / end-of-life > - fix it > - get it removed > > The issue seems only exploitable if it's used by a service that is exposed > remotely or to other issues... and has no rdeps in wheezy. OTOH there is at > least one sponsor using that package. So removing it may not be the best > course > given there is a proposed patch. So I'd go with either no-dsa or fix it, > depending on the assessed importance. Hi, My apologies for taking a while to join the thread. As the most recent uploader of this package, I feel responsible for helping get it into a safe state if we opt to keep it. However, I am not an active user, so if the package is to remain in Debian, it might be better to transition it to the Debian Perl Team (assuming that is amenable to the team). I tend to agree with Emilio that removing it might not be the best course of action for our users, particularly given that we have a patch and the popcon [1] is non-zero. Removing it from the distribution seems like it merely leaves users with a known vulnerability. Also, the package might be used in derivatives. I agree with Simon that it's a little odd for the patch to bump the version. (OTOH, it makes it much easier to differentiate from the vulnerable 0.15.) Still, I am inclined to take the patch as a patch against upstream 0.15 for the upload to unstable and then backport it for 0.13 for stable and oldstable. Or perhaps Alexandr Ciornii (on the cc) would be willing to release 0.16 including the patch. Thoughts? Thank you, tony [1] https://qa.debian.org/popcon.php?package=libnet-ping-external-perl signature.asc Description: PGP signature
Bug#881617: [pkg-wine-party] Bug#881617: wine-development: wine32 creates win64 prefixes: wine prefer win32 on amd64 while wineserver prefer win64
Oh, and about the inconsistency: yes, the wine wrapper /usr/bin/wine defaults to the loader (from wine32) /usr/lib/wine/wine, while the wineserver wrapper defaults to /usr/lib/wine/wineserver64. But that's absolutely correct: Even if you run a 32-bit prefix wineserver64 is the right choice, you don't need wineserver32 for that. If you're building Wine from vanilla upstream for 32- and 64-bit you end up with just exactly that binary. And if you want something like vanilla upstream built only for 32-bit you just have to uninstall wine64, so that /usr/lib/wine/wineserver32 is used. The 32-bit wine loader is also the right choice for starting wine, even if you want to run a 64-bit Windows application. I'm quite sure that you're never expected to call wine64 directly. Greets jre
Bug#882417: mariadb-10.1: FTBFS on arm64 (internal compiler error)
The fix in -3 was wrong and so was the one in -4 :(, but I finally got all the pieces in -5 upload that's coming up. -- Ondřej Surý On Wed, Nov 22, 2017, at 22:37, Sebastiaan Couwenberg wrote: > On 11/22/2017 08:58 PM, Ondřej Surý wrote: > > This has been reported as bug in gcc-7 and I am taking doko's suggestion > > and downgrading the -O3 to -O2 meanwhile in 1:10.1.29-3 as a temporary > > measure. > > mariadb-10.1 (1:10.1.29-3) still FTBFS on arm64. > > It's starting to look like it nor its reverse dependencies will migrate > to testing by the end of the year.
Bug#882417: [debian-mysql] Bug#882417: mariadb-10.1: FTBFS on arm64 (internal compiler error)
On Wed, Nov 22, 2017 at 08:58:01PM +0100, Ondřej Surý wrote: > Control: severity -1 important > Control: reassign -1 gcc-7 > Control: forcemerge 882415 -1 > > This has been reported as bug in gcc-7 and I am taking doko's suggestion > and downgrading the -O3 to -O2 meanwhile in 1:10.1.29-3 as a temporary > measure. Obviously you didn't try it yourself... Because that doesn't work. Still happens. See https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.1&arch=arm64&ver=1%3A10.1.29-3&stamp=1511381757&raw=0 Regards, Rene
Bug#882442: suricata-oinkmaster: Change to improved ETOPEN ruleset url
Package: suricata-oinkmaster Version: 1:4.0.1-1 Severity: minor The ET OPEN upstream url in the suricata-oinkmaster.conf file can be changed to the new improved ruleset for suricata 4.x https://rules.emergingthreats.net/open/suricata-4.0.0/ -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-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 /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages suricata-oinkmaster depends on: ii oinkmaster 2.0-4 ii suricata1:4.0.1-1 suricata-oinkmaster recommends no packages. suricata-oinkmaster suggests no packages. -- no debconf information
Bug#882436: libreoffice-core: Unable to upgrade (conflicts with openjdk-8-jre-headless)
notfound 882436 1:5.4.3~rc1-2
found 882436 1:5.4.3-1
block 882436 by 876051
thanks
Hi,
On Wed, Nov 22, 2017 at 09:46:00PM +0100, Nicolas Patrois wrote:
> Package: libreoffice-core
> Version: 1:5.4.3~rc1-2
No, if you file bugs PLEASE a bit of carefulness. This is the version
you try to upgrade from...
> Severity: minor
>
> Dear Maintainer,
>
> libreoffice-core conflits with openjdk-8-jre-headless but 8u151-b12-1 is
> installed.
Yes. This is completely intended. See the changelog:
libreoffice (1:5.4.3-1) unstable; urgency=medium
[...]
* debian/patches/java9-jawt.diff: add from master; find jawt with Java9 and
also fix odk/settings/settings.mk for it
* debian/patches/java9-rhino.diff: add from master; fix rhino build with Java9
[...]
- explicitly use and depend on openjdk 9 on i386 now that #876069 is fixed.
- set JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF8 in build-indep (needed for
Java9 in reportbuilder)
[...]
* debian/control.in: make -core conflict against openjdk-{6,7,8}-jre-headless
on i386- -java-common would make more sense, but it's Arch: all..
-- Rene Engelhard Tue, 07 Nov 2017 20:59:01 +0100
This is a compromise between having LO still crash because of the Stack
Class security fix regressions (yes, STILL unfixed in the kernel) or
by using a OpenJDK which is fixed. Which is 9.
A merge Depends wouldn't work since you could still have 8 installed and
LO might pick that one up.
[There's an option upstream which sounds possible to "pin" a specific
JDK, but that turns out to have an other purpose _and_ is outdated]
> Then, I can’t upgrade:
> 4) libreoffice [1:5.4.3~rc1-2 (now)]
> 5) libreoffice-avmedia-backend-vlc [1:5.4.3~rc1-2 (now)]
> 6) libreoffice-base [1:5.4.3~rc1-2 (now)]
> 7) libreoffice-base-core [1:5.4.3~rc1-2 (now)]
> 8) libreoffice-base-drivers [1:5.4.3~rc1-2 (now)]
> 9) libreoffice-calc [1:5.4.3~rc1-2 (now)]
> 10) libreoffice-core [1:5.4.3~rc1-2 (now)]
> 11) libreoffice-draw [1:5.4.3~rc1-2 (now)]
> 12) libreoffice-gnome [1:5.4.3~rc1-2 (now)]
> 13) libreoffice-gtk3 [1:5.4.3~rc1-2 (now)]
> 14) libreoffice-impress [1:5.4.3~rc1-2 (now)]
> 15) libreoffice-math [1:5.4.3~rc1-2 (now)]
> 16) libreoffice-officebean [1:5.4.3~rc1-2 (now)]
> 17) libreoffice-ogltrans [1:5.4.3~rc1-2 (now)]
> 18) libreoffice-report-builder-bin [1:5.4.3~rc1-2 (now)]
> 19) libreoffice-sdbc-firebird [1:5.4.3~rc1-2 (now)]
> 20) libreoffice-sdbc-hsqldb [1:5.4.3~rc1-2 (now)]
> 21) libreoffice-sdbc-postgresql [1:5.4.3~rc1-2 (now)]
> 22) libreoffice-writer [1:5.4.3~rc1-2 (now)]
Correct. You want to install openjdk-9.
Or get openjdk-8 (and/or linux) fixed. See 876051 and the referenced
linux bugi (#865303). After that one I can conflict against the unfixed
openjdk-8 versions instead of against all. Until then... bad luck.
> -- Package-specific info:
> All deployed bundled extensions:
>
> Identifier: org.openoffice.da.writer2latex.oxt
[...]
> Identifier: com.sun.wiki-publisher
[...]
> Identifier: com.sun.star.comp.Calc.NLPSolver
[...]
> Identifier: org.openoffice.da.writer2xhtml.oxt
[...]
So 4 of the 5 extensions installed are Java at at least wiki-publisher
and nlpsolver are known to make LO run into the crash (even when those
features are not used).
> -- System Information:
> Debian Release: buster/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: i386 (i686)
That is your problem, fwiw, if you can't live with this workaround on this
"obsolete" architecture, you might want to use amd64.
Regards,
Rene
Bug#882400: please package new version 0.13
Quoting Johannes Schauer (2017-11-22 11:08:00) > Yes, that's right. I'm also excited about the new release so I'll get to > packaging it soon. ^^ There are copyright issues, so this might take a bit longer... https://github.com/asciimoo/searx/issues/1091 signature.asc Description: signature
Bug#882441: davmail several SWT GLib WARNING and CRITICAL
Package: davmail Version: 4.8.0.2479-3 Severity: minor Tags: confirmed workaround This bugreport is about a known bug. Purpose of this B.R. is document two workarounds: starting as SWT_GTK3=0 davmail having in the properties file davmail.server=true Below text from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879146#39 On Wed, Nov 22, 2017 at 06:56:10PM +0100, Alexandre Rossi wrote: > >> FYI, I would be happy to move on with this but I'm stuck with the > >> program segfaulting when used with the proposed patch. It works > >> correctly if launched like this : > >> SWT_GTK3=0 davmail > >> > >> I'm still investigating as to why. > >> > >> Alex > >> > >> > >> (SWT:24928): GLib-GObject-WARNING **: cannot register existing type > >> 'GdkDisplayManager' > >> (SWT:24928): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' > >> failed > >> (SWT:24928): GLib-GObject-CRITICAL **: g_object_new_with_properties: > >> assertion 'G_TYPE_IS_OBJECT (object_type)' failed > >> (SWT:24928): GLib-GObject-WARNING **: invalid (NULL) pointer instance > >> (SWT:24928): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion > >> 'G_TYPE_CHECK_INSTANCE (instance)' failed > > > > > > Because I expect that those SWT messages wouldn't happen with > > > >davmail.server=true > > > > in davmail.properties, I'm about to upload 4.8.0.2479-3 > > > > Main reason is preventing davmail being removed from testing. > > Okay now users of the GUI version must set the envvar for davmail not > to crash. I'll search for a fix. Groeten Geert Stappers -- Leven en laten leven
Bug#882440: ecryptfs-utils: ecryptfs decrypts home after systemd user daemon is loaded. trouble ensues...
Package: ecryptfs-utils Version: 111-4 Severity: important Dear Maintainer, After having created some systemd user units (and timers), as I have done on several other machines without issue, I noticed that the units were not started upon login on this particular machine. In fact systemctl showed no knowledge of them at all - until I reloaded the systemd user daemon and timers; after that all was fine. The difference between this machine and the other working setups: my home is encrypted via ecryptfs on this laptop. So I wondered if maybe the systemd user daemon was started upon login BEFORE my home was decrypted (thus it'd know nothing of my setup). Sure enough, in /etc/pam.d/common-session, pam_ecryptfs.so unwrap was invoked AFTER pam_systemd.so. Reversing the order fixed the problem. I don't know too much about pam but I think ecryptfs should specify a higher priority in the common-session stack. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.12.0-2-686-pae (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 ecryptfs-utils depends on: ii gettext-base0.19.8.1-4 ii keyutils1.5.9-9 ii libassuan0 2.4.3-3 ii libc6 2.24-17 ii libecryptfs1111-4 ii libgpg-error0 1.27-5 ii libgpgme11 1.9.0-6 ii libkeyutils11.5.9-9 ii libpam-runtime 1.1.8-3.6 ii libpam0g1.1.8-3.6 ii libtspi10.3.14+fixed1-1 ecryptfs-utils recommends no packages. Versions of packages ecryptfs-utils suggests: ii cryptsetup 2:1.7.5-1 -- no debconf information
Bug#882276: dovecot-sieve: debian stretch reporting errors with lib95_imap_sieve_plugin.so dovecot undefined symbol
I've tested in Debian testing (Buster) and found that the issue is also present there as well. -Lance
Bug#875519: qelectrotech: Please stop installing deprecated mimelnk files
tags 875519 pending thanks Hello, Thank you for this information. It will be fixed soon in the next version. best regards Denis Briand pgpjz7NLRJMFU.pgp Description: PGP signature
Bug#881772: ruby2.5: FTBFS on ppc64(el): stack level too deep
Hi Terceiro, On 11/15/2017 02:32 PM, Antonio Terceiro wrote: > Hi, > > On Tue, Nov 14, 2017 at 06:16:22PM -0500, Aaron M. Ucko wrote: >> Source: ruby2.5 >> Version: 2.5.0~preview1-1 >> Severity: important >> Tags: upstream >> Justification: fails to build from source >> User: debian-powe...@lists.debian.org >> Usertags: ppc64 ppc64el >> >> Builds of ruby2.5 for ppc64el and the non-release architecture ppc64 >> have been failing per the below excerpt from >> >> https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=ppc64el&ver=2.5.0%7Epreview1-1&stamp=1510662722&raw=0 >> >> FTR, the ppc64 log, which exhibits the same error, is at >> >> https://buildd.debian.org/status/fetch.php?pkg=ruby2.5&arch=ppc64&ver=2.5.0%7Epreview1-1&stamp=1510663941&raw=0 >> >> Could you please take a look? > > Thanks for reporting. > >> Thanks! >> >> 1) Error: >> TestBacktrace#test_caller_lev: >> SystemStackError: stack level too deep >> /<>/test/ruby/test_backtrace.rb:96:in `times' >> /<>/test/ruby/test_backtrace.rb:96:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:92:in `times' >> /<>/test/ruby/test_backtrace.rb:92:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:92:in `times' >> /<>/test/ruby/test_backtrace.rb:92:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:92:in `times' >> /<>/test/ruby/test_backtrace.rb:92:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:92:in `times' >> /<>/test/ruby/test_backtrace.rb:92:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:92:in `times' >> /<>/test/ruby/test_backtrace.rb:92:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:92:in `times' >> /<>/test/ruby/test_backtrace.rb:92:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:93:in `block (2 levels) in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:92:in `times' >> /<>/test/ruby/test_backtrace.rb:92:in `block in >> test_caller_lev' >> /<>/test/ruby/test_backtrace.rb:106:in `block in >> test_caller_lev' >> >> Finished tests in 517.516592s, 33.1661 tests/s, 4326.2574 assertions/s. >> 17164 tests, 2238910 assertions, 0 failures, 1 errors, 85 skips >> >> ruby -v: ruby 2.5.0dev (2017-10-10) [powerpc64le-linux-gnu] >> uncommon.mk:691: recipe for target 'yes-test-almost' failed > > Dear POWER porters, would you be able to help with this? Sorry for not looking at it yet. Unfortunately we will not be able to see it this week, but I hope to start look at it next week.
Bug#807717: RFP: ttf-fxemoji -- Firefox OS Emojis
The Firefox OS Emoji project is no longer developed, which means the emoji set will just be missing more and more emoji as time passes. Should this bug be closed now? https://github.com/mozilla/fxemoji Thanks, Jeremy Bicha
Bug#878268: RFS: streamlink/0.9.0-1 [ITP]
Control: retitle -1 RFS: streamlink/0.9.0-1 [ITP] Hi, I am looking for a sponsor for my package "streamlink" I made a new upload for the new upstream version: 0.9.0. The package is available using this dget command: dget -x https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.9.0-1.dsc Changes since last upload: streamlink (0.9.0-1) unstable; urgency=low * New upstream version 0.9.0 * Recommend python3-socks for socks proxy support * Drop documentation patches applied upstream streamlink (0.8.1-4) unstable; urgency=low * Use gzip format in deb files - bintray repository does not support control.tar.xz Can anyone look at it ? Thanks :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#882417: mariadb-10.1: FTBFS on arm64 (internal compiler error)
On 11/22/2017 08:58 PM, Ondřej Surý wrote: > This has been reported as bug in gcc-7 and I am taking doko's suggestion > and downgrading the -O3 to -O2 meanwhile in 1:10.1.29-3 as a temporary > measure. mariadb-10.1 (1:10.1.29-3) still FTBFS on arm64. It's starting to look like it nor its reverse dependencies will migrate to testing by the end of the year.
Bug#881219: test latest upstream
Hey Dann, It doesn't appear to have made a differnce, it still is failing. Thanks jeff On Wed, Nov 22, 2017 at 2:18 PM, dann frazier wrote: > hey Jeff, > Would you mind checking to see if this is fixed in latest upstream? > I've posted a build here: > > https://people.debian.org/~dannf/bugs/881219/OVMF_CODE.fd-8284b1791 >
Bug#879636: #879636: virtual memory exhausted: Cannot allocate memory
On Wed, Nov 22, 2017 at 2:24 PM, Mathieu Malaterre wrote: > Dear mips gurus, > > Could someone please suggest a fix for the following FTBFS issue for > OpenVDB package: > > https://buildd.debian.org/status/fetch.php?pkg=openvdb&arch=mipsel&ver=4.0.2-1&stamp=1508213166&raw=0 > > Thanks much Turns out that --param ggc-min-expand=10 worked just fine on eller.d.o. Sorry for the noise,
Bug#881219: test latest upstream
hey Jeff, Would you mind checking to see if this is fixed in latest upstream? I've posted a build here: https://people.debian.org/~dannf/bugs/881219/OVMF_CODE.fd-8284b1791
Bug#882439: sshguard systemd service file is configured to start too soon
Package: sshguard
Version: 1.7.1-1
Severity: important
Tags: patch
Dear Maintainer,
* What led up to the situation?
1. Google Cloud instance
2. Installed sshguard
3. Added hostnames to /etc/sshguard/whitelist
4. rebooted
5. checked /var/log/auth.log and saw that it wasn't able to resolve my
whitelisted addresses (actually, logwatch read the files for me and
reported it, ...)
* What exactly did you do (or not do) that was effective (or
ineffective)?
I can change the systemd .service file (see patch)
-- System Information:
Debian Release: 9.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-4-amd64 (SMP w/1 CPU core)
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 sshguard depends on:
ii init-system-helpers 1.48
ii iptables 1.6.0+snapshot20161117-6
ii libc62.24-11+deb9u1
ii lsb-base 9.20161125
sshguard recommends no packages.
sshguard suggests no packages.
-- Configuration Files:
/etc/sshguard/whitelist changed
# To see more examples, please see
# /usr/share/doc/sshguard/examples/whitelistfile.example
# Address blocks in CIDR notation
127.0.0.0/8
::1/128
10.0.0.0/8
# whitelist
www.google.com
news.google.com
mail.google.com
docs.google.com
[EOF]
/etc/resolv.conf changed
domain c.elevated-nature-167919.internal
search c.elevated-nature-167919.internal. google.internal.
nameserver 169.254.169.254
[EOF]
-- no debconf information
syslog:
Nov 21 23:59:28 machine kernel: [4.524706 <4524706>] ip6_tables: (C)
2000-2006 Netfilter Core Team
...
Nov 21 23:59:28 machine systemd[1]: Started SSHGuard.
...
Nov 21 23:59:28 machine sshguard-journalctl[520]: Chain INPUT (policy
ACCEPT)
...
Nov 21 23:59:28 machine dhclient[581]: Internet Systems Consortium DHCP
Client 4.3.5
Nov 21 23:59:28 machine ifup[509]: Internet Systems Consortium DHCP Client
4.3.5
...
Nov 21 23:59:29 machine ifup[509]: DHCPREQUEST of 10.128.0.6 on eth0 to
255.255.255.255 port 67
Nov 21 23:59:29 machine dhclient[581]: Sending on
LPF/eth0/42:01:0a:80:00:06
Nov 21 23:59:29 machine dhclient[581]: Sending on Socket/fallback
Nov 21 23:59:29 machine dhclient[581]: DHCPREQUEST of 10.128.0.6 on eth0 to
255.255.255.255 port 67
Nov 21 23:59:29 machine dhclient[581]: DHCPACK of 10.128.0.6 from
169.254.169.254
Nov 21 23:59:29 machine ifup[509]: DHCPACK of 10.128.0.6 from
169.254.169.254
Nov 21 23:59:29 machine dhclient[581]: bound to 10.128.0.6 -- renewal in
36358 seconds.
Nov 21 23:59:29 machine ifup[509]: bound to 10.128.0.6 -- renewal in 36358
seconds.
Nov 21 23:59:29 machine systemd[1]: Started Raise network interfaces.
Nov 21 23:59:29 machine systemd[1]: Reached target Network.
auth.log:
Nov 21 23:59:28 machine sshguard[537]: Could not resolve hostname '
www.google.com': Temporary failure in name resolution.
Nov 21 23:59:28 machine sshguard[537]: whitelist: Unable to handle line 10
from whitelist file "/etc/sshguard/whitelist".
Nov 21 23:59:28 machine sshguard[537]: Could not resolve hostname '
news.google.com': Temporary failure in name resolution.
Nov 21 23:59:28 machine sshguard[537]: whitelist: Unable to handle line 11
from whitelist file "/etc/sshguard/whitelist".
Nov 21 23:59:28 machine sshguard[537]: Could not resolve hostname '
mail.google.com': Temporary failure in name resolution.
Nov 21 23:59:28 machine sshguard[537]: whitelist: Unable to handle line 12
from whitelist file "/etc/sshguard/whitelist".
Nov 21 23:59:28 machine sshguard[537]: Could not resolve hostname '
docs.google.com': Temporary failure in name resolution.
Nov 21 23:59:28 machine sshguard[537]: whitelist: Unable to handle line 13
from whitelist file "/etc/sshguard/whitelist".
Nov 21 23:59:29 machine sshguard[537]: Monitoring attacks from stdin
You can see that sshguard starts before dhclient/ifup, and fails its dns
resolution before dhcp starts.
# ip route get 169.254.169.254
169.254.169.254 via 10.128.0.1 dev eth0 src 10.128.0.6
cache
As far as I understand, dns lookups will not work until after a network
interface (eth0) arrives.
systemd-analyze dump|egrep 'ssh|net|> Unit' > systemd-dump
UNITS=$(perl -ne 'next unless s/.*> Unit (.*):/$1/; print' systemd-dump )
UNITS_TO_READABLE=$(for a in $UNITS; do systemctl show $a 2>/dev/null|grep
^Desc|perl -pne "s{Description=(.*)}{s\{$a\}\{\$1 ($a)\};}"; done)
cat systemd-dump |perl -pne "$UNITS_TO_READABLE"|egrep
'Unit|Raise|SSH|Secure Shell|network.service'|sed -e
's/^->/\n\n\n->/'|egrep -C3 'Raise|SSH|Secure Shell|\(network'|egrep -A6 --
'->.*(Raise|SSH|Secure Shell|\(network)'|perl -ne 'next unless /^.../;print'
-> Unit Network (network.target):
WantedBy: Raise network interfaces (networking.service)
Before: OpenBSD Secure Shell server (ssh.service)
After: Raise network interfaces (networking.service)
ReferencedBy: OpenBSD Sec
Bug#867641: What next?
I've tried multiple times to contact the upstream maintainer of gdbm, but I have never heard back. What next? -- Brad Spencer
Bug#882381: [ftpsync] Error using socks and old sed
Hi Bastian Thank you for your prompt reply. I would like to talk about it below. The -E option is common to all current operation systems as it is specified by POSIX. As this script not only runs on Linux, using GNU specific options is not the way to go. I also found no supported Linux distribution without support for it. I tell SuSE support. Their sed under SLES11 or SLES12 knows no option -E. ;-) >I would be more concerned about a stage2 that runs for over an hour. The problem is that e.g. my existing proxy has a timeout of 120 and rsync 3600 seconds. The program rsync calculates its keep alive transmissions according to the following calculation: timeout / 2. This results in a timeout of 3600 seconds keep alive packets every 1800 seconds. However, the proxy ends the connection after 120 seconds of inactivity. So while ftpsync checks in Stage2 what files it can delete (no traffic),the proxy's timeout fails and terminates the socks connection. If the rsync wants to access the remote station again, it first notices that it is offline and ends with an error. But if I synchronize the timeouts of the proxy and rsync, the keep alive packets will be sent on time and the connection will remain open.Another note, the proxy is not under my administration and I can not change that. Original Text: Das Problem ist, dass z.B. mein vorhandener Proxy einen Timeout von 120 und rsync 3600 Sekunden hat. Das Programm rsync berechnet seine keep alive Sendungen nach folgender Rechnung: timeout/2. Das ergibt bei einem Timeout von 3600 Sekunden keep alive Pakete alle 1800 Sekunden. Der Proxy beendet aber schon nach 120 Sekunden inaktivität die Verbindung. Während also ftpsync in Stage2 überprüft, welche Dateien es löschen kann (kein Datenverkehr), schlägt der timeout des Proxy zu und beendet die Socks Verbindung. Wenn das rsync dann wieder auf die gegenstelle zugreifen möchte merkt es erst, dass es offline ist und beendet mit einem Fehler. Wenn ich aber die timeouts vom Proxy und rsync synchronisiere werden die keep alive Pakete rechtzeitig gesendet und die Verbindung bleibt offen. Noch ein Hinweis, der Proxy steht nicht unter meiner Administration und ich kanns deswegen nicht ändern. Regards, Björn -- mfg Björn ICQ: 22207642, MSN: de...@gmx.de
Bug#882438: RFS: libt3config/0.2.11-1 ITP#882376
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libt3config" * Package name: libt3config Version : 0.2.11-1 Upstream Author : Gertjan Halkes * URL : https://os.ghalkes.nl/t3/libt3config.html * License : GPLv3 Section : libs It builds those binary packages: libt3config-dev - Development files for libt3config libt3config0 - Library for reading and writing configuration files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libt3config Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libt/libt3config/libt3config_0.2.11-1.dsc Regards, Gertjan Halkes
Bug#875637: iipimage-server: Wrong configuration file /etc/apache2/mods-available/iipsrv.conf
Control: found -1 1.0-2 Hi again, On Wed, Nov 22, 2017 at 9:58 PM, Mathieu Malaterre wrote: > fixed 875637 1.0-2 > thanks > > Hi, > > On Tue, Oct 10, 2017 at 11:04 AM, Laurent Bonnaud > wrote: >> Hi, >> >> this bug is still there: > > no Actually yes. >> Package: iipimage-server >> Version: 1.0-2 >> >> apache2_reload: apache2: Syntax error on line 147 of >> /etc/apache2/apache2.conf: Syntax error on line 20 of >> /etc/apache2/mods-enabled/iipsrv.conf: Expected but saw >> > > Make sure to purge your configuration files first. Do not play with > the BTS this remove valid package from testing distribution, thanks. Please accept my apologies, I misread your report. A new upload should fix the typo, I was not looking at the right line. Sorry again.
Bug#882437: cwltool FTBFS with ruamel.yaml 0.15.34
Source: cwltool
Version: 1.0.20170810192106-2
Severity: serious
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/cwltool.html
...
debian/rules override_dh_installman
make[1]: Entering directory '/build/1st/cwltool-1.0.20170810192106'
python2 setup.py develop --user
running develop
running egg_info
writing requirements to cwltool.egg-info/requires.txt
writing cwltool.egg-info/PKG-INFO
writing top-level names to cwltool.egg-info/top_level.txt
writing dependency_links to cwltool.egg-info/dependency_links.txt
writing entry points to cwltool.egg-info/entry_points.txt
reading manifest file 'cwltool.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no previously-included files matching '*~' found anywhere in
distribution
warning: no previously-included files matching '*.pyc' found anywhere in
distribution
writing manifest file 'cwltool.egg-info/SOURCES.txt'
running build_ext
Creating
/build/1st/cwltool-1.0.20170810192106/fakehome/.local/lib/python2.7/site-packages/cwltool.egg-link
(link to .)
Adding cwltool 1.0.20170810192106 to easy-install.pth file
Installing cwltool script to
/build/1st/cwltool-1.0.20170810192106/fakehome/.local/bin
Installed /build/1st/cwltool-1.0.20170810192106
Processing dependencies for cwltool==1.0.20170810192106
Searching for ruamel.yaml<0.15,>=0.12.4
Reading https://pypi.python.org/simple/ruamel.yaml/
Download error on https://pypi.python.org/simple/ruamel.yaml/: [Errno -3]
Temporary failure in name resolution -- Some packages may not be found!
Couldn't retrieve index page for 'ruamel.yaml'
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: [Errno -3] Temporary failure
in name resolution -- Some packages may not be found!
No local packages or working download links found for ruamel.yaml<0.15,>=0.12.4
error: Could not find suitable distribution for
Requirement.parse('ruamel.yaml<0.15,>=0.12.4')
debian/rules:17: recipe for target 'debian/cwltool.1' failed
make[1]: *** [debian/cwltool.1] Error 1
Bug#882436: libreoffice-core: Unable to upgrade (conflicts with openjdk-8-jre-headless)
Package: libreoffice-core
Version: 1:5.4.3~rc1-2
Severity: minor
Dear Maintainer,
libreoffice-core conflits with openjdk-8-jre-headless but 8u151-b12-1 is
installed.
Then, I can’t upgrade:
4) libreoffice [1:5.4.3~rc1-2 (now)]
5) libreoffice-avmedia-backend-vlc [1:5.4.3~rc1-2 (now)]
6) libreoffice-base [1:5.4.3~rc1-2 (now)]
7) libreoffice-base-core [1:5.4.3~rc1-2 (now)]
8) libreoffice-base-drivers [1:5.4.3~rc1-2 (now)]
9) libreoffice-calc [1:5.4.3~rc1-2 (now)]
10) libreoffice-core [1:5.4.3~rc1-2 (now)]
11) libreoffice-draw [1:5.4.3~rc1-2 (now)]
12) libreoffice-gnome [1:5.4.3~rc1-2 (now)]
13) libreoffice-gtk3 [1:5.4.3~rc1-2 (now)]
14) libreoffice-impress [1:5.4.3~rc1-2 (now)]
15) libreoffice-math [1:5.4.3~rc1-2 (now)]
16) libreoffice-officebean [1:5.4.3~rc1-2 (now)]
17) libreoffice-ogltrans [1:5.4.3~rc1-2 (now)]
18) libreoffice-report-builder-bin [1:5.4.3~rc1-2 (now)]
19) libreoffice-sdbc-firebird [1:5.4.3~rc1-2 (now)]
20) libreoffice-sdbc-hsqldb [1:5.4.3~rc1-2 (now)]
21) libreoffice-sdbc-postgresql [1:5.4.3~rc1-2 (now)]
22) libreoffice-writer [1:5.4.3~rc1-2 (now)]
-- Package-specific info:
All deployed bundled extensions:
Identifier: org.openoffice.da.writer2latex.oxt
Version: 1.4
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description: Writer2LaTeX exporte les documents Writer vers LaTeX et BibTeX
bundled Packages: {
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/help
is registered: yes
Media-Type: application/vnd.sun.star.help
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/writer2latex.rdb
is registered: yes
Media-Type: application/vnd.sun.star.uno-typelibrary;type=RDB
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/W2LDialogs2/
is registered: yes
Media-Type: application/vnd.sun.star.basic-library
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/W2LDialogs/
is registered: yes
Media-Type: application/vnd.sun.star.basic-library
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/Options.xcs
is registered: yes
Media-Type: application/vnd.sun.star.configuration-schema
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/writer2latex-filter.jar
is registered: yes
Media-Type: application/vnd.sun.star.uno-component;type=Java
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/w2l_types.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/w2l_filters.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/OptionPages.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/writer2latex/Options.xcu
is registered: yes
Media-Type: application/vnd.sun.star.configuration-data
Description:
}
Identifier: com.sun.wiki-publisher
Version: 1.2.0
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher
is registered: yes
Media-Type: application/vnd.sun.star.package-bundle
Description: Le Wiki Publisher vous permet de cr\xe9er des articles de Wiki
sur un serveur MediaWiki sans avoir \xe0 conna\xeetre la syntaxe du langage
markup Mediawiki. Publiez de nouveaux documents ou des documents existants de
fa\xe7on transparente depuis Writer vers une page de wiki.
bundled Packages: {
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/help
is registered: yes
Media-Type: application/vnd.sun.star.help
Description:
URL:
vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiExtension.xcs
is registered: yes
Media-Type: application/vnd.sun.star.configuration-schema
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/WikiEditor/
is registered: yes
Media-Type: application/vnd.sun.star.basic-library
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/components.rdb
is registered: yes
Media-Type: application/vnd.sun.star.uno-components
Description:
URL: vnd.sun.star.expand:$BUNDLED_EXTENSIONS/wiki-publisher/Addons.xcu
is registered: yes
Media-Type: appl
Bug#882422: [Pkg-fonts-devel] Bug#882422: fonts-firacode: bare equals sign invisibl
Am Mittwoch, den 22.11.2017, 17:29 + schrieb Jonathan Dowland: > I haven't exhaustively tested all other ligature definitions or other symbols, > but this makes it practically unusable. This is a freshly installed stable > system. This is already stated in the package description: This font is expected to work in most text editors but won't work in most (especially VTE-based) terminal emulators. A detailed list is available on https://github.com/tonsky/FiraCode#terminal-support - Fabian signature.asc Description: This is a digitally signed message part
Bug#882434: stretch-pu: package ust/2.9.0-2+deb9u1
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu Hi, The attached diff fixes a bug that makes the python3-lttngust package completely broken unless the corresponding liblttng-ust-dev is also installed. The original python code load the library using ctypes without specifying a soname. This fix was reported and merged upstream. Fixed in unstable: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882366 Regards, Michael -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.9.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru ust-2.9.0/debian/changelog ust-2.9.0/debian/changelog --- ust-2.9.0/debian/changelog 2017-03-08 12:04:25.0 -0500 +++ ust-2.9.0/debian/changelog 2017-11-22 14:45:44.0 -0500 @@ -1,3 +1,10 @@ +ust (2.9.0-2+deb9u1) stable; urgency=medium + + * [5ffa17d] Set gbp branch config + * [8e770e4] Fix python3-lttngust load un-versioned library (Closes: #882366) + + -- Michael Jeanson Wed, 22 Nov 2017 14:45:44 -0500 + ust (2.9.0-2) unstable; urgency=medium * [b8d4e77] Add missing liblttng-ust-fd.so.* (Closes: #857166) diff -Nru ust-2.9.0/debian/gbp.conf ust-2.9.0/debian/gbp.conf --- ust-2.9.0/debian/gbp.conf 1969-12-31 19:00:00.0 -0500 +++ ust-2.9.0/debian/gbp.conf 2017-11-22 14:44:31.0 -0500 @@ -0,0 +1,3 @@ +[DEFAULT] +upstream-branch=upstream/2.9.0 +debian-branch=debian/stretch diff -Nru ust-2.9.0/debian/patches/fix-specify-soname-in-python-lttngust-loadlibrary.patch ust-2.9.0/debian/patches/fix-specify-soname-in-python-lttngust-loadlibrary.patch --- ust-2.9.0/debian/patches/fix-specify-soname-in-python-lttngust-loadlibrary.patch 1969-12-31 19:00:00.0 -0500 +++ ust-2.9.0/debian/patches/fix-specify-soname-in-python-lttngust-loadlibrary.patch 2017-11-22 14:45:15.0 -0500 @@ -0,0 +1,30 @@ +From 00ee1adfe1e34d43494227781f6662b0a21b7c4b Mon Sep 17 00:00:00 2001 +From: Michael Jeanson +Date: Tue, 21 Nov 2017 11:11:15 -0500 +Subject: [PATCH] Fix: specify SONAME in python-lttngust LoadLibrary + +When loading the python agent library with ctypes in the python +bindings, specify the SONAME. This will make sure we load the proper +library in the event of a SONAME bump and the bindings will work without +having to install the "dev" package which in most distros contains the +non-versionned ".so". + +Signed-off-by: Michael Jeanson +Signed-off-by: Mathieu Desnoyers +--- + python-lttngust/lttngust/loghandler.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/python-lttngust/lttngust/loghandler.py b/python-lttngust/lttngust/loghandler.py +index e82cf5c5..6f144cac 100644 +--- a/python-lttngust/lttngust/loghandler.py b/python-lttngust/lttngust/loghandler.py +@@ -22,7 +22,7 @@ + + + class _Handler(logging.Handler): +-_LIB_NAME = 'liblttng-ust-python-agent.so' ++_LIB_NAME = 'liblttng-ust-python-agent.so.0' + + def __init__(self): + super(self.__class__, self).__init__(level=logging.NOTSET) diff -Nru ust-2.9.0/debian/patches/series ust-2.9.0/debian/patches/series --- ust-2.9.0/debian/patches/series 2016-11-29 18:21:51.0 -0500 +++ ust-2.9.0/debian/patches/series 2017-11-22 14:45:15.0 -0500 @@ -1,3 +1,4 @@ fix-incompatible-java-bytecode-format.patch use-python3.patch javah-doesnt-generate-class-files.patch +fix-specify-soname-in-python-lttngust-loadlibrary.patch
Bug#881745: fswebcam: build dependency libgd2-noxpm-dev does not exist
Control: tags -1 pending Hi, On 22/11/17 12:01, Luca Niccoli wrote: > Hi James, > > I have a uploaded a new version on mentors.debian.net, you can see it at > https://mentors.debian.net/package/fswebcam > Would you be willing to sponsor an upload? I've uploaded it. I made some minor changes to the changelog. I added a "Closes" for this bug, and I changed the urgency to "medium" which is now the normal urgency. The actual diff I uploaded is attached. Thanks! James diff -Nru fswebcam-20140113/debian/changelog fswebcam-20140113/debian/changelog --- fswebcam-20140113/debian/changelog 2014-01-20 23:16:51.0 + +++ fswebcam-20140113/debian/changelog 2017-11-22 09:56:11.0 + @@ -1,3 +1,11 @@ +fswebcam (20140113-2) unstable; urgency=medium + + * Build-Depend on libgd-dev instead of libgd2-*-dev (Closes: #881745) + * Use DEP5 format for debian/copyright + * Bump Standards-Version (no changes needed) + + -- Luca Niccoli Wed, 22 Nov 2017 10:56:11 +0100 + fswebcam (20140113-1) unstable; urgency=low * Update debian/watch diff -Nru fswebcam-20140113/debian/control fswebcam-20140113/debian/control --- fswebcam-20140113/debian/control2014-01-20 23:16:51.0 + +++ fswebcam-20140113/debian/control2017-11-22 09:56:11.0 + @@ -2,8 +2,8 @@ Section: graphics Priority: optional Maintainer: Luca Niccoli -Build-Depends: debhelper (>= 9.20120417), libgd2-noxpm-dev | libgd2-xpm-dev, libv4l-dev -Standards-Version: 3.9.5 +Build-Depends: debhelper (>= 9.20120417), libgd-dev, libv4l-dev +Standards-Version: 4.1.1 Homepage: http://www.firestorm.cx/fswebcam/ Vcs-Git: git://anonscm.debian.org/collab-maint/fswebcam.git Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/fswebcam.git;a=summary diff -Nru fswebcam-20140113/debian/copyright fswebcam-20140113/debian/copyright --- fswebcam-20140113/debian/copyright 2014-01-20 23:16:51.0 + +++ fswebcam-20140113/debian/copyright 2017-11-22 09:56:11.0 + @@ -1,62 +1,34 @@ -This package was debianized by Luca Niccoli on -Wed, 28 Jan 2008 16:05:41 +0100. - -It was downloaded from http://www.firestorm.cx/fswebcam/files/ - -Upstream author: Philip Heron - -Licence (videodev_mjpeg.h): - - videodev_mjpeg.h is a part of mjpegtools, written by - - Rainer Johanni - Gernot Ziegler - Andrew Stevens - Bernhard Praschinger - Ronald Bultje - Xavier Biquard - Matthew Marjanovic - Philipp Zabel - Kawamata/Hitoshi - Stefan Fendt - Scott Moser - Shawn Sulma - Mike Bernson - James Klicman - - mjpegtools is distributed under the terms of the GNU General Public - License, version 2. You may use, modify, and redistribute it under the - terms of this license. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - -License (everything else): - - Copyright 2004-2009 Philip Heron - - This program is distributed under the terms of the GNU General Public - License, version 2. You may use, modify, and redistribute it under the - terms of this license. - - This program is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - GNU General Public License for more details. - - You should have received a copy of the GNU General Public License - along with this program; if not, write to the Free Software - Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - -The Debian packaging is © 2010, Luca Niccoli and is -licensed under the same license as the upstream source, see above. - -On Debian GNU/Linux systems, the complete text of the GNU General Public -License can be found in `/usr/share/common-licenses/GPL-2' file. - +Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ +Upstream-Name: fswebcam +Upstream-Contact: Philip Heron +Source: http://www.firestorm.cx/fswebcam/files/ + +Files: * +Copyright: 2004-2014 Philip Heron +License: GPL-2 + +Files: debian/* +Copyright: 2010-2017 Luca Niccoli +License: GPL-2 + +Files: videodev_mjpeg.h +Copyright: 2000-2008 the mjpegtool authors +License: GPL-2 + +License: GPL-2 + This program is distributed under the terms of the GNU General Public + License, version 2. You may use, modify, and redistribute it under the + terms of this license. + . + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the
Bug#882435: RFP: ruby-cocaine -- A small library for doing (command) lines.
Package: wnpp Severity: wishlist * Package name: ruby-cocaine Version : 0.5.8 Upstream Author : Jon "jyurek" Yurek * URL : https://github.com/thoughtbot/cocaine * License : MIT https://github.com/thoughtbot/cocaine/blob/master/LICENSE Programming Lang: Ruby Description : A small library for doing (command) lines. Allows ruby programs to run commands, with features like logging, "interpolated arguments", some safety checks, and throws exceptions on errors or the wrong returned number.
Bug#882417: mariadb-10.1: FTBFS on arm64 (internal compiler error)
Control: severity -1 important Control: reassign -1 gcc-7 Control: forcemerge 882415 -1 This has been reported as bug in gcc-7 and I am taking doko's suggestion and downgrading the -O3 to -O2 meanwhile in 1:10.1.29-3 as a temporary measure. Cheers, -- Ondřej Surý On Wed, Nov 22, 2017, at 16:04, Bas Couwenberg wrote: > Source: mariadb-10.1 > Version: 1:10.1.29-2 > Severity: serious > Justification: makes the package in question unusable or mostly so > Control: affects -1 src:apr-util, src:asterisk, src:dovecot, src:exim4, > src:gammu, src:gnunet, src:gnustep-sqlclient, src:grass, src:jabberd2, > src:kamailio, src:kdb, src:kopanocore, src:mailutils, > src:mysql-connector-c++, src:pike7.8, src:pmacct, src:poco, src:sope, > src:vtk6, and src:zabbix > > Dear Maintainer, > > mariadb-10.1 (1:10.1.29-2) is looking much better than the previous > uploads, but it still FTBFS on arm64 due to an internal compiler error: > > " > /<>/storage/mroonga/vendor/groonga/lib/ts/ts_expr_node.c: > In function 'grn_ts_op_not_equal_evaluate': > > /<>/storage/mroonga/vendor/groonga/lib/ts/ts_expr_node.c:3824:18: > internal compiler error: in gen_vec_cmpv2dfv2di, at > config/aarch64/aarch64-simd.md:2495 > out_ptr[i] = grn_ts_op_ ## type ## _ ## kind(buf_ptrs[0][i],\ > ~~~^~ > buf_ptrs[1][i]);\ > ~~~ > /<>/storage/mroonga/vendor/groonga/lib/ts/ts_expr_node.c:3863:5: > note: in expansion of macro 'GRN_TS_OP_CHK_EVALUATE_CASE' > GRN_TS_OP_CHK_EVALUATE_CASE(type, FLOAT, float)\ > ^~~ > /<>/storage/mroonga/vendor/groonga/lib/ts/ts_expr_node.c:3893:3: > note: in expansion of macro 'GRN_TS_OP_CHK_EVALUATE' > GRN_TS_OP_CHK_EVALUATE(not_equal) > ^~ > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > " > https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.1&arch=arm64&ver=1%3A10.1.29-2&stamp=1511344924&raw=0 > > This build failure still prevents testing migration of mariadb-10.1 and > its reverse dependencies. > > Kind Regards, > > Bas >
Bug#881097: To be removed from wheezy as well
On 08/11/17 20:19, Ola Lundqvist wrote: > Hi > > Considering that this package is about to be removed from jessie I > guess it should be removed from wheezy too. How is that done? Should I > contact the FTP maintainers about it, or do we simply ignore the > issue? We don't have point releases, so I'm not sure we can get a package removed at this stage without extra work by the ftp masters. So our options would be: - mark as no-dsa if it's not important enough - mark as unsupported / end-of-life - fix it - get it removed The issue seems only exploitable if it's used by a service that is exposed remotely or to other issues... and has no rdeps in wheezy. OTOH there is at least one sponsor using that package. So removing it may not be the best course given there is a proposed patch. So I'd go with either no-dsa or fix it, depending on the assessed importance. Cheers, Emilio
Bug#853783: libsane-hpaio: Failed to open hpaio:/net/HP_Color_Laserjet_MFP_M277DW?ip=194.168.1.4: Error during device I/O
On Tue 31 Jan 2017 at 21:50:23 +0100, Svante Signell wrote: > Package: libsane-hpaio > Version: 3.16.11+repack0-2 > Severity: important > > Hello, > > Upgrading libane-hpaio (and hplip*, etc) to 3.16.11+repack0-2 makes the > scanner > non-functional. (The same applies to 3.16.10+repack0-1 and 3.16.9+repack0-2). > Even if awahi-daemon is running the message is: > Failed to open hpaio:/net/HP_Color_Laserjet_MFP_M277DW?ip=194.168.1.4: Error > during device I/O. > > Searching for the printer works (as well as the printer itself): > scanimage -L > device `hpaio:/net/HP_Color_LaserJet_MFP_M277dw?ip=192.168.1.4' is a Hewlett- > Packard HP_Color_LaserJet_MFP_M277dw all-in-one > > Installed driver is: > hp-color_laserjet_pro_mfp_m277-ps.ppd.gz downloaded from HP. > > Previous working version is: 3.16.7-1 snapshot doesn't have that version. This makes testing with what you used previouly impossible. > Printer/Scanner/Copier/Faxer: Network connected HP Color Laserjet Pro MFP > M277dw > Tested software: scanimage, xscanimage, simple-scan I am going to assume (contrary to my normal practice) that installing 3.17.10+repack0-1 doesn't work for you either. Please correct me if that isn't the case. Let's see if we can move this bug on with a stab in the dark. :) Edit /usr/share/hplip/data/models/models.dat and alter [hp_laserjet_pro_mfp_m277dw] to read [laserjet_pro_mfp_m277dw]. Does 'scanimage -L' give a positive outcome? And can you scan? Cheers, Brian.
Bug#882430: libics FTBFS on 32bit: FAIL: test_strides3.sh
Control: forwarded -1 https://github.com/svi-opensource/libics/issues/6 Control: tags -1 upstream Hi, I've forwarded the issue upstream. Kind regards Andreas. -- http://fam-tille.de
Bug#873417: [Pkg-opencl-devel] Bug#873417: pocl: Please update to llvm-toolchain 4.0 or, better, 5.0
The main issue seems to be that pocl has switched to CMake. I’ve fixed this locally and it builds and passes all the tests, it just looks like the symbols files need to be updated which I’m not sure how to do properly. I don’t have write access to collab-maint so couldn’t push the CMake fix, so patch is attached if anyone is interested. James > On 21 Nov 2017, at 07:59, Andreas Tille wrote: > > Hi, > > I realised that there is a new upstream version 0.14 which seems to > allow LLVM 4.0. I gave it a try in Git in the new branch 0.14 but faced > build problems I was not able to solve. However, since I was hoping > that the refreshed patches might help (please review!) I commited this > branch. > > Hope this helps a bit > > Andreas. > > -- > http://fam-tille.de > > ___ > Pkg-opencl-devel mailing list > pkg-opencl-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-opencl-devel pocl-cmake.diff Description: pocl-cmake.diff
Bug#873417: [Pkg-opencl-devel] Bug#873417: pocl: Please update to llvm-toolchain 4.0 or, better, 5.0
On 2017-11-21 18:12, James Price wrote: > The main issue seems to be that pocl has switched to CMake. I’ve fixed this > locally and it builds and passes all the tests, it just looks like the > symbols files need to be updated which I’m not sure how to do properly. > > I don’t have write access to collab-maint so couldn’t push the CMake fix, so > patch is attached if anyone is interested. Thanks, I'll take a look ... Andreas
Bug#877555: libgegl-dev should supply VAPI bindings
> On Wednesday, 22 November 2017, 18:52:49 GMT, Jeremy Bicha > wrote: > gegl already Build-Depends on valac. OK, that's good to know. So the next thing to check is if the build is being configured with --without-vala See https://git.gnome.org/browse/gegl/tree/configure.ac#n478 Regards, Al Thomas
Bug#882431: strongswan-starter: counters plugin should be visible to strongswan-swanctl package
Control: tags -1 + patch I've built a private package with the attached patch, and tested that "swanctl -C" works, however I haven't tested strongswan-starter/stroke (but the move looks trivial, couldn't possibly break?) -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D From 50cc42baf5d5c0815a483caae250711a2334de12 Mon Sep 17 00:00:00 2001 From: Gerald Turner Date: Tue, 21 Nov 2017 14:30:23 -0800 Subject: [PATCH] Move counters plugin from strongswan-starter package to libstrongswan package so that it may be used by swanctl as well --- debian/control| 1 + debian/libstrongswan.install | 3 +++ debian/strongswan-starter.install | 4 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/debian/control b/debian/control index f0c6dcd8..571257a6 100644 --- a/debian/control +++ b/debian/control @@ -71,6 +71,7 @@ Description: strongSwan utility and crypto library For libstrongswan (cryptographic backends, URI fetchers and database layers): - aes (AES-128/192/256 cipher software implementation) - constraints (X.509 certificate advanced constraint checking) + - counters (Provides IKE performance counters) - dnskey (Parse RFC 4034 public keys) - fips-prf (PRF specified by FIPS, used by EAP-SIM/AKA algorithms) - gmp (RSA/DH crypto backend based on libgmp) diff --git a/debian/libstrongswan.install b/debian/libstrongswan.install index 072ff7e0..c44318f5 100644 --- a/debian/libstrongswan.install +++ b/debian/libstrongswan.install @@ -2,6 +2,7 @@ usr/lib/ipsec/libstrongswan.so* usr/lib/ipsec/plugins/libstrongswan-aes.so usr/lib/ipsec/plugins/libstrongswan-constraints.so +usr/lib/ipsec/plugins/libstrongswan-counters.so usr/lib/ipsec/plugins/libstrongswan-dnskey.so usr/lib/ipsec/plugins/libstrongswan-fips-prf.so usr/lib/ipsec/plugins/libstrongswan-gmp.so @@ -27,6 +28,7 @@ usr/lib/ipsec/plugins/libstrongswan-xcbc.so # config files usr/share/strongswan/templates/config/plugins/aes.conf usr/share/strongswan/templates/config/plugins/constraints.conf +usr/share/strongswan/templates/config/plugins/counters.conf usr/share/strongswan/templates/config/plugins/dnskey.conf usr/share/strongswan/templates/config/plugins/fips-prf.conf usr/share/strongswan/templates/config/plugins/gmp.conf @@ -51,6 +53,7 @@ usr/share/strongswan/templates/config/plugins/x509.conf usr/share/strongswan/templates/config/plugins/xcbc.conf etc/strongswan.d/charon/aes.conf etc/strongswan.d/charon/constraints.conf +etc/strongswan.d/charon/counters.conf etc/strongswan.d/charon/dnskey.conf etc/strongswan.d/charon/fips-prf.conf etc/strongswan.d/charon/gmp.conf diff --git a/debian/strongswan-starter.install b/debian/strongswan-starter.install index 7eebe6be..7b02b0a8 100644 --- a/debian/strongswan-starter.install +++ b/debian/strongswan-starter.install @@ -21,7 +21,3 @@ usr/lib/ipsec/plugins/libstrongswan-stroke.so usr/share/strongswan/templates/config/plugins/stroke.conf etc/strongswan.d/charon/stroke.conf debian/usr.lib.ipsec.stroke /etc/apparmor.d/ -#counters -usr/lib/ipsec/plugins/libstrongswan-counters.so -usr/share/strongswan/templates/config/plugins/counters.conf -etc/strongswan.d/charon/counters.conf -- 2.14.2 signature.asc Description: PGP signature
Bug#882200: transition: sox
On 21/11/17 10:37, Jaromír Mikeš wrote: > Ok ... I let block this bug by freedv already ... > now I am waiting if somebody provide me DM flag for sox package to I can > upload > it to unstable. > When this done should I also bumps freedv bug to RC? Yes. Cheers, Emilio
Bug#882424: Acknowledgement (smime master password in new version seems not able to be disabled)
I was using alpine's password file as a way to connect to the local imap
server, to read the user's local maildirs. It does not seem well suited
to that.
A better way is documented in this blog post, but it's not at all easy to find.
https://cpbl.wordpress.com/2011/11/16/how-to-alpine-maildir-offlineimap/
Essentially all that is needed is this in /etc/pine.conf:
inbox-path={localhost}inbox
rsh-command=/usr/lib/dovecot/imap
Since lack of imap support is such a long-standing pain point with
alpine, simply documenting this workaround in README.Debian would go a long
way.
--
see shy jo
signature.asc
Description: PGP signature
Bug#877555: libgegl-dev should supply VAPI bindings
> The vapigen program needs to be installed on the build machine. The VAPI > should then be generated. > There is a check in configure.ac for > vapigen:https://git.gnome.org/browse/gegl/tree/configure.ac#n478 >vapigen is part of the valac package, >e.g.https://packages.debian.org/stretch/i386/valac/filelist gegl already Build-Depends on valac. Thanks, Jeremy Bicha
Bug#882432: RFP: ruby-paperclip -- Easy file attachment management for ActiveRecord
Package: wnpp Severity: wishlist * Package name: ruby-paperclip Version : 5.1.0 Upstream Author : Jon "jyurek" Yurek * URL : https://github.com/thoughtbot/paperclip * License : MIT https://github.com/thoughtbot/paperclip/blob/master/LICENSE Programming Lang: Ruby Description : Easy file attachment management for ActiveRecord Paperclip is intended as an easy file attachment library for ActiveRecord. The intent behind it was to keep setup as easy as possible and to treat files as much like other attributes as possible. This means they aren't saved to their final locations on disk, nor are they deleted if set to nil, until ActiveRecord::Base#save is called. It manages validations based on size and presence, if required. It can transform its assigned image into thumbnails if needed, and the prerequisites are as simple as installing ImageMagick (which, for most modern Unix-based systems, is as easy as installing the right packages). Attached files are saved to the filesystem and referenced in the browser by an easily understandable specification, which has sensible and useful defaults.
Bug#882431: strongswan-starter: counters plugin should be visible to strongswan-swanctl package
Package: strongswan-starter Version: 5.6.1-1 Severity: normal Dear Maintainer, Upstream strongSwan 5.6.1 introduced the counters plugin, which moved from being stroke-specific, to being shared with swanctl. FWICT Alioth commit d14d4c17 added the counters plugin to the strongswan-starter package where stroke resides. Perhaps in reaction to the upstream change - perhaps because stroke would fail without the plugin being available? Sorry for my ignorance, I no longer use strongswan-starter/stroke anywhere, and instead rely solely on charon-systemd/swanctl. As you can see from the documentation, this plugin was intended to be accessible to the strongswan-swanctl package as well. https://wiki.strongswan.org/versions/67 “The IKE event counters, previously only available via ipsec listcounters command, may now also be queried and reset via vici and the new swanctl --counters command. They are collected and provided by the optional counters plugin (enabled by default for backwards compatibility if the stroke plugin is built).” https://wiki.strongswan.org/projects/strongswan/wiki/Swanctl “The --counters command was added with 5.6.1." It would seem appropriate to move the counters plugin to the libstrongswan package (although I always get confused about libcharon vs. libstrongswan). I'd like to use this feature of swanctl to create a munin-node statistics collection script. -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (601, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-0.bpo.1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages strongswan-starter depends on: ii adduser3.115 ii debconf [debconf-2.0] 1.5.61 ii init-system-helpers1.48 ii libc6 2.24-11+deb9u1 ii libstrongswan 5.6.1-1.1 ii lsb-base 9.20161125 Versions of packages strongswan-starter recommends: pn strongswan-charon strongswan-starter suggests no packages. -- Gerald Turner Encrypted mail preferred! OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D signature.asc Description: PGP signature
Bug#882430: libics FTBFS on 32bit: FAIL: test_strides3.sh
Source: libics Version: 1.6.1-1 Severity: serious https://buildd.debian.org/status/package.php?p=libics&suite=sid ... make check-TESTS make[2]: Entering directory '/<>' make[3]: Entering directory '/<>' PASS: test_ics1.sh PASS: test_compress.sh PASS: test_ics2b.sh PASS: test_ics2a.sh FAIL: test_strides3.sh PASS: test_gzip.sh PASS: test_strides2.sh PASS: test_strides.sh PASS: test_history.sh PASS: test_metadata.sh libics 1.6.1: ./test-suite.log # TOTAL: 10 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test_strides3.sh == *** Error in `/<>/.libs/test_strides3': free(): invalid pointer: 0x579a8978 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x698aa)[0xf75878aa] /lib/i386-linux-gnu/libc.so.6(+0x705f7)[0xf758e5f7] /lib/i386-linux-gnu/libc.so.6(+0x70e46)[0xf758ee46] /<>/.libs/libics.so.0(IcsCloseIds+0x53)[0xf7759723] /<>/.libs/libics.so.0(IcsGetDataWithStrides+0x1c7)[0xf7761b47] /<>/.libs/test_strides3(+0x983)[0x56591983] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf6)[0xf7536456] /<>/.libs/test_strides3(+0xba0)[0x56591ba0] === Memory map: 56591000-56593000 r-xp 00:26 266067099 /<>/.libs/test_strides3 56593000-56594000 r--p 1000 00:26 266067099 /<>/.libs/test_strides3 56594000-56595000 rw-p 2000 00:26 266067099 /<>/.libs/test_strides3 57981000-579c9000 rw-p 00:00 0 [heap] f73e3000-f73fe000 r-xp 00:26 266037493 /lib/i386-linux-gnu/libgcc_s.so.1 f73fe000-f73ff000 r--p 0001a000 00:26 266037493 /lib/i386-linux-gnu/libgcc_s.so.1 f73ff000-f740 rw-p 0001b000 00:26 266037493 /lib/i386-linux-gnu/libgcc_s.so.1 f740-f7421000 rw-p 00:00 0 f7421000-f750 ---p 00:00 0 f751c000-f751e000 rw-p 00:00 0 f751e000-f76d5000 r-xp 00:26 266037488 /lib/i386-linux-gnu/libc-2.25.so f76d5000-f76d6000 ---p 001b7000 00:26 266037488 /lib/i386-linux-gnu/libc-2.25.so f76d6000-f76d8000 r--p 001b7000 00:26 266037488 /lib/i386-linux-gnu/libc-2.25.so f76d8000-f76d9000 rw-p 001b9000 00:26 266037488 /lib/i386-linux-gnu/libc-2.25.so f76d9000-f76dc000 rw-p 00:00 0 f76dc000-f76f5000 r-xp 00:26 266037413 /lib/i386-linux-gnu/libz.so.1.2.8 f76f5000-f76f6000 r--p 00018000 00:26 266037413 /lib/i386-linux-gnu/libz.so.1.2.8 f76f6000-f76f7000 rw-p 00019000 00:26 266037413 /lib/i386-linux-gnu/libz.so.1.2.8 f76f7000-f7751000 r-xp 00:26 266037484 /lib/i386-linux-gnu/libm-2.25.so f7751000-f7752000 r--p 00059000 00:26 266037484 /lib/i386-linux-gnu/libm-2.25.so f7752000-f7753000 rw-p 0005a000 00:26 266037484 /lib/i386-linux-gnu/libm-2.25.so f7755000-f7756000 rw-p 00:00 0 f7756000-f776f000 r-xp 00:26 266065818 /<>/.libs/libics.so.0.0.0 f776f000-f777 r--p 00018000 00:26 266065818 /<>/.libs/libics.so.0.0.0 f777-f7771000 rw-p 00019000 00:26 266065818 /<>/.libs/libics.so.0.0.0 f7771000-f7774000 rw-p 00:00 0 f7774000-f7776000 r--p 00:00 0 [vvar] f7776000-f7778000 r-xp 00:00 0 [vdso] f7778000-f779b000 r-xp 00:26 266037492 /lib/i386-linux-gnu/ld-2.25.so f779b000-f779c000 r--p 00022000 00:26 266037492 /lib/i386-linux-gnu/ld-2.25.so f779c000-f779d000 rw-p 00023000 00:26 266037492 /lib/i386-linux-gnu/ld-2.25.so ffee-fff01000 rw-p 00:00 0 [stack] ./test_strides3.sh: line 1: 23936 Aborted ./test_strides3 $srcdir/test/testim.ics result_s3.ics FAIL test_strides3.sh (exit status: 134) Testsuite summary for libics 1.6.1 # TOTAL: 10 # PASS: 9 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log Makefile:990: recipe for target 'test-suite.log' failed make[3]: *** [test-suite.log] Error 1
Bug#882429: RFP: ruby-cucumber-expressions -- Cucumber Expressions for Ruby
Package: wnpp
Severity: wishlist
* Package name: ruby-cucumber-expressions
Version : 5.0.3
Upstream Author : Aslak ("aslakhellesoy") Hellesøy @aslak_hellesoy
* URL : https://github.com/cucumber/cucumber-expressions-ruby
* License : MIT
https://github.com/cucumber/cucumber-expressions-ruby/blob/master/LICENSE
Programming Lang: Ruby
Description : Cucumber Expressions for Ruby
cucumber-expression is part of the cucumber acceptance testing framework.
Debian already has
ruby-cucumber-core and cucumber, but for some reason it has been split apart
into a variety of
subprojects and cucumber-expressions does not seem to be among the subpackages
that were packaged.
Bug#882428: nbdkit FTBFS: nbdkit-nbd-plugin.so exists in debian/tmp but is not installed to anywhere
Source: nbdkit Version: 1.1.18-1 Severity: serious https://buildd.debian.org/status/package.php?p=nbdkit&suite=sid ... debian/rules override_dh_install make[1]: Entering directory '/<>' dh_install -X.la --fail-missing dh_install: Please use dh_missing --list-missing/--fail-missing instead dh_install: This feature will be removed in compat 12. dh_missing: usr/lib/x86_64-linux-gnu/nbdkit/plugins/nbdkit-nbd-plugin.so exists in debian/tmp but is not installed to anywhere dh_missing: usr/share/man/man1/nbdkit-nbd-plugin.1 exists in debian/tmp but is not installed to anywhere dh_missing: missing files, aborting The following debhelper tools have reported what they installed (with files per package) * dh_install: nbdkit (12), nbdkit-plugin-dev (8), nbdkit-plugin-guestfs (2), nbdkit-plugin-libvirt (2), nbdkit-plugin-perl (2), nbdkit-plugin-python (2), nbdkit-plugin-ruby (2) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built For a short-term work-around: Add the files to debian/not-installed dh_install: dh_missing --exclude .la --fail-missing returned exit code 255 debian/rules:21: recipe for target 'override_dh_install' failed make[1]: *** [override_dh_install] Error 25
Bug#882427: manaplus FTBFS on ppc64el: tets failure
Source: manaplus Version: 1.7.10.28-1 Severity: serious https://buildd.debian.org/status/logs.php?pkg=manaplus&arch=ppc64el ... unittests/gui/windowmanager.cc:831: FAILED: due to unexpected exception with message: Unknown exception === test cases: 391 | 375 passed | 16 failed assertions: 1402104 | 1402086 passed | 18 failed FAIL manaplustests (exit status: 18) Testsuite summary for ManaPlus 1.7.11.11 # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See src/test-suite.log Please report to aka...@inbox.ru Makefile:35009: recipe for target 'test-suite.log' failed make[4]: *** [test-suite.log] Error 1
Bug#882426: i8kutils: No effect on Latitude E7440
Package: i8kutils Version: 1.43 Severity: important Dear Maintainer, My laptop's fan acting very strangely (it does not seem to be correlated with the temperature at all…), I tried using i8kutils. Unfortunately, it has absolutely no effects, even as root. Other users got it working on the same laptop (Latitude E7440) : https://superuser.com/questions/533102/laptop-fan-is-always-on-using-linux-mint-14 Kernel module is loaded : $ lsmod | grep smm dell_smm_hwmon 16384 0 i8kctl output seems correct : $ i8kctl 1.0 A21 348DTZ1 36 -1 2 -1 6698 -1 -1 But i8kctl has no effect, either for starting : # i8kctl fan 2 2 or stopping the fan : # i8kctl fan 0 0 Of course, the system service also does not seem to have any effect. I am using the newest version of the BIOS (A21). Do not hesitate to ask if I can provide other information, or if I should report this upstream. Rergards, Yvan -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=$ Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages i8kutils depends on: ii acpi 1.7-1+b1 ii init-system-helpers 1.51 ii libc62.24-17 ii lsb-base 9.20170808 ii tcl 8.6.0+9 i8kutils recommends no packages. i8kutils suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#773294: tracker.debian.org: add support for the vcswatch service
On Wed, 22 Nov 2017, Pierre-Elliott Bécue wrote: > > - either the user is explicit (compression="gzip" attribute, or > > compression=None/False for no compression) > > - or the user relies on compression="auto" (default value) in which > > case it should just rely on the filename extension that we should pass > > along in some way. > > pabs was also suggesting to have something doing the decompression > implicitly and thus providing no argument for compression. > > Which one would you prefer? I prefer the hybrid approach that I suggested. We have an attribute controlling the use of compression, its default value is "auto" which means that compression is used when the file extension indicates compressed content, but it's always possible to override this by adding an explicit value to this attribute. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Bug#882425: coreutils: who command doesn't list hostname even with --lookup
Package: coreutils Version: 8.26-3 Severity: normal Dear Maintainer, * What led up to the situation? I have recently upgraded two machines from Debian jessie to Debian Stretch. After the upgrade running 'who' (or 'who am i' or any other variant) returns the list of users and their IP addresses, when previously it returned the list of users and the hostnames of the machines they are logging in from. Adding the '--lookup' option to the 'who' command does not list the hostname either. I can only get IP addresses from 'who', where previous it was the hostname. None of the networking files have been edited since the upgrade (/etc/nsswitch, /etc/hosts, /etc/network/interfacesi, /etc/resolv.conf). -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/40 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on: ii libacl1 2.2.52-3+b1 ii libattr1 1:2.4.47-2+b2 ii libc62.24-11+deb9u1 ii libselinux1 2.6-3+b3 coreutils recommends no packages. coreutils suggests no packages. -- no debconf information
Bug#879146: About to upload davmail 4.8.0.2479-3 to prevent removal from testing
>> FYI, I would be happy to move on with this but I'm stuck with the >> program segfaulting when used with the proposed patch. It works >> correctly if launched like this : >> SWT_GTK3=0 davmail >> >> I'm still investigating as to why. >> >> Alex >> >> >> (SWT:24928): GLib-GObject-WARNING **: cannot register existing type >> 'GdkDisplayManager' >> (SWT:24928): GLib-CRITICAL **: g_once_init_leave: assertion 'result != 0' >> failed >> (SWT:24928): GLib-GObject-CRITICAL **: g_object_new_with_properties: >> assertion 'G_TYPE_IS_OBJECT (object_type)' failed >> (SWT:24928): GLib-GObject-WARNING **: invalid (NULL) pointer instance >> (SWT:24928): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion >> 'G_TYPE_CHECK_INSTANCE (instance)' failed > > > Because I expect that those SWT messages wouldn't happen with > >davmail.server=true > > in davmail.properties, I'm about to upload 4.8.0.2479-3 > > Main reason is preventing davmail being removed from testing. Okay now users of the GUI version must set the envvar for davmail not to crash. I'll search for a fix. Thanks for uploading. Alex
Bug#879719: libsane-hpaio: Does not recognize OfficeJet Pro 8710
On 11/22/2017 01:46 PM, Brian Potkin wrote: > I forgot to ask: is scanning successful if, instead of duplicating the > section. you just delete the "hp_" from [hp_officejet_pro_8710]? Yes, same effect.
Bug#882424: smime master password in new version seems not able to be disabled
Package: alpine Version: 2.21+dfsg1-1 Severity: normal This new version of alpine has started encrypting .pine-password with a master password, which it prompts the user for. My users who are still using alpine don't appreciate this, because it's now asking for some new password every time they use it. Since the .pine-password file was only readable by those users anyway, and was being used to communicate with an IMAP server on the same host, to work around alpine's longstanding inability to read Maildir files on the same host, which are also readable by those same users only, encrypting it with another password is not adding any security and is only causing me technical headaches. (Also I'm pretty sure all the users entered the *exact same password* as the master password as the password in the password file that's it's encrypting..) There should be a way to disable this security feature for the cases where it adds no security. I can't find any configuration that would disable it. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/2 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: systemd (via /run/systemd/system) Versions of packages alpine depends on: ii libc6 2.24-17 ii libgssapi-krb5-2 1.15.2-2 ii libkrb5-3 1.15.2-2 ii libldap-2.4-2 2.4.45+dfsg-1 ii libpam0g 1.1.8-3.6 ii libssl1.1 1.1.0g-2 ii libtinfo5 6.0+20170902-1 ii mlock 8:2007f~dfsg-5 Versions of packages alpine recommends: ii alpine-doc 2.21+dfsg1-1 Versions of packages alpine suggests: ii aspell 0.60.7~20110707-4 ii postfix [mail-transport-agent] 3.2.3-1 -- no debconf information -- see shy jo
Bug#879719: libsane-hpaio: Does not recognize OfficeJet Pro 8710
On 11/21/2017 08:09 PM, Brian Potkin wrote: > > Hello Gedalya. Thank you for your report. I forwarded it upstream and > now you will see there is a reply. Please would you respond to that > message there as I am unable to speak for you. I'll look into that. Thank you! > > Meanwhile, let's see what we can do here. First, upgrade hplip to the > latest, 1.17.10+repack0 Already done, I update my system frequently. No change regarding this issue. > and read > > https://wiki.debian.org/SaneOverNetwork > > Post the output of > > scanimage -L --- $ scanimage -L No scanners were identified. If you were expecting something different, check that the scanner is plugged in, turned on and detected by the sane-find-scanner tool (if appropriate). Please read the documentation which came with this software (README, FAQ, manpages). --- Note: In order to produce this, I need to stop cupsd. Somehow, at some point sane started finding the scanner via CUPS, the printer being configured there. On my laptop, where this printer is not installed in CUPS, there is no need to stop CUPS to get this error. With CUPS running, or with models.dat edited: $ scanimage -L device `hpaio:/net/officejet_pro_8710?ip=192.168.9.238&queue=false' is a Hewlett-Packard officejet_pro_8710 all-in-one
Bug#882423: Device: combo is readonly
Package: cutecom Version: 0.30.3-1+b1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** We use CuteCom to verify data from serial and to test device interface software. CuteCom detects /dev/ttyS0, but it does not detect MOXA or virtual serial ports. Older versions of CuteCom allows us to manually enter the Device, which allowed us to connect to things like /dev/ttyVSP0, /dev/ttyr06, and /dev/battery. * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cutecom depends on: ii libc6 2.24-11+deb9u1 ii libgcc11:6.3.0-18 ii libqt5core5a 5.7.1+dfsg-3+b1 ii libqt5gui5 5.7.1+dfsg-3+b1 ii libqt5serialport5 5.7.1~20161021-2 ii libqt5widgets5 5.7.1+dfsg-3+b1 ii libstdc++6 6.3.0-18 cutecom recommends no packages. Versions of packages cutecom suggests: ii lrzsz 0.12.21-8 -- no debconf information
Bug#868059: tc: m_xt: Segfault with iptables-1.6.0
Control: severity -1 serious
Control: tag -1 pending
Hi Gabor,
(I'm cc-ing the iptables maintainers so that they can correct me if I'm
wrong in my findings below; iproute2's maintainer Alexander; and Julian
who proposed an update to a new upstream release. Spoiler alert: I'm
proposing to fix the most obvious issues in a targetted way.)
Gabor Zsoldos (2017-07-11):
> Package: iproute2
> Version: 4.9.0-1
> Severity: normal
I'm bumping severity, since a tc segfault is pretty bad…
> This is a known and corrected bug in the mainstream.
> See:
> https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?h=v4.10.0&id=97a02cabefb2e2dcfe27f89943709afa84be5525
So, I've checked what happened with iptables 1.6, and tracked this down
to this splendidly huge commit in iptables.git:
| commit 384958620abab397062b67fb2763e813b63f74f0
| Author: Pablo Neira Ayuso
| Date: Thu Sep 27 19:12:53 2012 +0200
|
| use nf_tables and nf_tables compatibility interface
| […]
| 23 files changed, 5723 insertions(+), 5 deletions(-)
Basically, it introduces a new field (compat_rev) in the xtables_globals
structure, and that one needs to be initialized by library users. I've
only quickly checked codesearch but it seems the 6 following packages
contains hits for this structure:
+ connman: src/iptables.c has: .compat_rev = xtables_compatible_revision
+ iproute2: this bug report.
+ iptables: not relevant. :)
+ kamailio: modules/iptrtpproxy/iptrtpproxy.c only defines a NULL
pointer, which is unused anyway.
+ nftables: src/xt.c has .compat_rev = nft_xt_compatible_revision
+ python-iptables: python-iptables-0.11.0/iptc/xtables.py has an
xtables_version > 10 test and sets _xt_globals.compat_rev = _xt_compat_rev
So it seems to me that the iproute2 package is the only one needing an
update (both in unstable and in stable). That's good news!
Unfortunately, cherry-picking the upstream patch above does only solve
the segfault, but tc isn't fully functional anyway. Trying to set up
some rules, one can get such output:
tc-ipt v0.2: Extension does not know id 1504083504
A few reports online mention that deleting include/xtables.h solved the
problem. I've verified this hypothesis practically (tc seems to do its
job properly), but also double checked why this happens. This upstream
commit adds a function pointer right in the middle of two structures
(xtables_match and xtables_target):
| commit 7a0992da44cfb6cab0ccd1beadcf326df8773552
| Author: Pablo Neira Ayuso
| Date: Sun Jul 24 12:45:53 2016 +0200
|
| src: introduce struct xt_xlate_{mt,tg}_params
| […]
| 56 files changed, 279 insertions(+), 261 deletions(-)
So iproute2 being compiled against an outdated version of iptables's
include/xtables.h header, the resulting m_xt.so plugin gets the wrong
offset for a bunch of structure members (checked by comparing objdump's
output directly, or with diffoscope), which leads to the issue mentioned
above. Syncing the header with stretch's iptables makes it work again,
so I think I'll add a patch to update it this way. (There were no
further changes regarding this header between stretch and unstable yet.)
There are probably reasons for including a copy of the header instead of
using the system one (probably because such things are common when it
comes to kernel-related headers), but deleting the header entirely would
work as well.
I'll upload an NMU to unstable shortly and push appropriate patches to
the collab-maint repository. If everything looks fine enough, I'll move
to proposing an update to stretch through stretch-proposed-updates.
Cheers,
--
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
signature.asc
Description: PGP signature
Bug#882422: fonts-firacode: bare equals sign invisibl
Package: fonts-firacode Version: 1.204-2 Severity: important Within gnome-terminal (3.22.2-1) with font hinting settings as: full, RGB; a bare equals sign is totally invisible when using firacode, either regular, light or retina (although this is on non-"retina" displays) I think the ligature definitions are screwed up. An email address written as displays as foo@bar=> (with the => bit a ligature, note the missing opening < at the start of the string) too. I haven't exhaustively tested all other ligature definitions or other symbols, but this makes it practically unusable. This is a freshly installed stable system. Thanks -- System Information: Debian Release: 9.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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) -- no debconf information
Bug#882158: stretch-pu: package glibc/2.24-11+deb9u2
On 2017-11-19 18:36, Aurelien Jarno wrote:
> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
>
> Dear stable release managers,
>
> I would like to upload a new glibc package for the next stretch release.
> It mostly consists in pulling the release/2.24/master upstream branch.
> Unfortunately this makes the patch big because:
> - it includes patches that were applied as debian patches before (mostly
> security ones)
> - upstream decided to backport all the test support from master in order
> to ease the backport of fixes from master including the corresponding
> tests
>
> I have therefore included two diffs, the full debdiff compared to
> version 2.24-11+deb9u1 currently in stable, and the one comparing the
> tree with all the patches applied. The biggest part of the later diff
> comes from the support infrastructure for tests (support/*) or from
> tests (tst-*). After removing changes which don't end-up in the binary
> packages, there are less than 600 lines changed.
>
> Most of the changes were already in buster/sid for quite some time, with
> the notable exception of compatibility with Intel C++ which is only in
> sid and experimental.
>
> Thanks for considering, and don't hesitate to ask for more details if
> needed.
I would also like to add the attached an additional patch to fix a
critical bug which has been filled recently, breaking some systems
during jessie to stretch upgrades (see bug#882272).
Thanks,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
diff --git a/debian/changelog b/debian/changelog
index 239aacd4..cb182fb9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -24,6 +24,9 @@ glibc (2.24-11+deb9u2) UNRELEASED; urgency=medium
- Fix invalid cast in group merging affecting ppc64 and s390x.
- Define collation for Malayalam chillu characters.
- Correct collation of U+0D36 and U+0D37 Malayalam characters.
+ * debian/script.in/nohwcap.sh: always check for all optimized packages
+as multiarch allows one to install foreign architectures. Closes:
+#882272.
[ Santiago Vila ]
* debian/debhelper.in/libc-bin.postinst: do not update /etc/nsswitch.conf
diff --git a/debian/script.in/nohwcap.sh b/debian/script.in/nohwcap.sh
index b952b886..5e0d0aee 100644
--- a/debian/script.in/nohwcap.sh
+++ b/debian/script.in/nohwcap.sh
@@ -3,33 +3,16 @@
# from /lib, and ignore all optimised libraries. This file is
# inconditionaly created in the preinst script of libc.
-# Get the list of optimized packages for a given architecture
-# Before removing a package from this list, make sure it appears
-# in the Conflicts: line of libc.
-case ${DPKG_MAINTSCRIPT_ARCH} in
-alpha)
-hwcappkgs="libc6-alphaev67"
-;;
-i386)
-hwcappkgs="libc6-i686 libc6-xen"
-;;
-kfreebsd-i386)
-hwcappkgs="libc0.1-i686"
-;;
-esac
-
# We check the version between the current installed libc and
-# all optimized packages (on architectures where such packages
-# exists).
+# all optimized packages. Due to multiarch, this has to be done
+# independently of the architecture of the package.
all_upgraded=yes
-if [ -n "$hwcappkgs" ]; then
-for pkg in $hwcappkgs ; do
-ver=$(dpkg-query -l $pkg 2>/dev/null | sed -e '/^[a-z][a-z]\s/!d;/^.[nc]/d;' -e "s/^..\s\+$pkg[0-9a-z:]*\s\+//;s/\s.*//g")
-if [ -n "$ver" ] && [ "$ver" != "CURRENT_VER" ]; then
-all_upgraded=no
-fi
-done
-fi
+for pkg in libc6.1-alphaev67 libc6-i686 libc6-xen libc0.1-i686 ; do
+ver=$(dpkg-query -l $pkg 2>/dev/null | sed -e '/^[a-z][a-z]\s/!d;/^.[nc]/d;' -e "s/^..\s\+$pkg[0-9a-z:]*\s\+//;s/\s.*//g")
+if [ -n "$ver" ] && [ "$ver" != "CURRENT_VER" ]; then
+all_upgraded=no
+fi
+done
# If the versions of all optimized packages are the same as the libc
# one, we could remove /etc/ld.so.nohwcap. Otherwise, it will be removed
Bug#882420: segyio: FTBFS on s390x: Assertion failed in file: /<>/lib/test/segy.c on line: 547
From: Aaron M. Ucko Sent: Wednesday, November 22, 2017 5:39 PM To: Debian Bug Tracking System Subject: Bug#882420: segyio: FTBFS on s390x: Assertion failed in file: /<>/lib/test/segy.c on line: 547 Source: segyio Version: 1.3.3-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-s...@lists.debian.org Usertags: s390x The build of segyio for s390x failed with a strange error, per the below excerpt from https://buildd.debian.org/status/fetch.php?pkg=segyio&arch=s390x&ver=1.3.3-1&stamp=1511256490&raw=0: 1/17 Test #1: c.segy ...***Failed0.00 sec Assertion failed in file: /<>/lib/test/segy.c on line: 547 Expected: 4.24, Actual: 4.24, diff: 0.00, eps: 0.00 starting interpret file read inline 4 Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu Hi, I've patched this in upstream and in the alioth git repo https://anonscm.debian.org/cgit/debian-science/packages/segyio.git/commit/?id=1b05cb8db357bb0bc091674693657c2182cece99 but I've yet to upload it as some minor details are missing still. --- The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorized use, dissemination of the information or copying of this message is prohibited. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you
Bug#824854: ACPI Errors in kernel 3.x and higher
Can confirm this still happens under Debian 9.2 kernel 4.9.0-4-amd64 x86_64 Board: Supermicro X9DRT-HF+ BIOS revision: 3.12: [2.554037] ACPI Error: [\_SB_.PRAD] Namespace lookup failure, AE_NOT_FOUND (20160831/psargs-359) [2.554246] ACPI Error: Method parse/execution failed [\_GPE._L24] (Node 880853ca18c0), AE_NOT_FOUND (20160831/psparse-543) [2.554503] ACPI Exception: AE_NOT_FOUND, while evaluating GPE method [_L24] (20160831/evgpe-646) Diego
Bug#882421: segyio: FTBFS on sparc64: test_rotation: AssertionError: 1.571 != 0.0 within 3 places
Source: segyio Version: 1.3.3-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-sp...@lists.debian.org Usertags: sparc64 The build of segyio for sparc64 (admittedly not a release architecture) failed per the below excerpts from https://buildd.debian.org/status/fetch.php?pkg=segyio&arch=sparc64&ver=1.3.3-1&stamp=1511256932&raw=0. 1.571 is of course approximately π/2. Could you please take a look? Thanks! 16/17 Test #6: python.tools .***Failed0.61 sec test_cube_filename (tools.ToolsTest) ... ok test_cube_identity (tools.ToolsTest) ... ok test_cube_identity_prestack (tools.ToolsTest) ... ok test_dt_fallback (tools.ToolsTest) ... ok test_dt_no_fallback (tools.ToolsTest) ... ok test_empty_text_header_creation (tools.ToolsTest) ... ok test_native (tools.ToolsTest) ... ok test_rotation (tools.ToolsTest) ... FAIL test_sample_indexes (tools.ToolsTest) ... ok test_unstructured_rotation (tools.ToolsTest) ... ok test_values_text_header_creation (tools.ToolsTest) ... ok test_wrap (tools.ToolsTest) ... ok == FAIL: test_rotation (tools.ToolsTest) -- Traceback (most recent call last): File "/<>/.pybuild/pythonX.Y_3.6/build/python/test/tools.py", line 128, in test_rotation close(right, rotation(f, line = 'slow'), places = 3) AssertionError: 1.571 != 0.0 within 3 places -- Ran 12 tests in 0.032s FAILED (failures=1) [...] 94% tests passed, 1 tests failed out of 17 Total Test time (real) = 0.92 sec The following tests FAILED: 6 - python.tools (Failed) Errors while running CTest Makefile:122: recipe for target 'test' failed -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#882420: segyio: FTBFS on s390x: Assertion failed in file: /<>/lib/test/segy.c on line: 547
Source: segyio Version: 1.3.3-1 Severity: important Tags: upstream Justification: fails to build from source User: debian-s...@lists.debian.org Usertags: s390x The build of segyio for s390x failed with a strange error, per the below excerpt from https://buildd.debian.org/status/fetch.php?pkg=segyio&arch=s390x&ver=1.3.3-1&stamp=1511256490&raw=0: 1/17 Test #1: c.segy ...***Failed0.00 sec Assertion failed in file: /<>/lib/test/segy.c on line: 547 Expected: 4.24, Actual: 4.24, diff: 0.00, eps: 0.00 starting interpret file read inline 4 Could you please take a look? Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
