Bug#1071520: tp-smapi-dkms: (regression) breaks kernel versions 6.6.13-1~bpo12+1
On Tue, May 21, 2024 at 07:46:43AM +0200, Manny wrote: > > This was reported and fixed in #1038207 > > > > If you're using a bpo kernel, I highly suggest to use kernel modules > > from bpo too. > > I appreciate the suggestion. But I have to wonder, why didn’t apt > prevent this? The purpose of apt is to manage dependencies and > version compatibility and it seems to have failed. apt can only act on package metadata, but linux-image in bpo has no "Breaks: tp-smapi-dkms (< 0.44-1~)" and thus apt could not prevent that.
Bug#1040898: tp-smapi-dkms: Update to support Kernel 6.4+
forcemerge 1038207 1040898 thanks On Wed, Jul 12, 2023 at 08:46:22AM +0200, Jan Volec wrote: > Package: tp-smapi-dkms > Version: 0.43-3 > Severity: critical > Justification: breaks unrelated software no it does not :) > DKMS fails to compile the module with the 6.4 kernels; see > https://github.com/linux-thinkpad/tp_smapi, > and the patch > https://github.com/linux-thinkpad/tp_smapi/commit/0c3398b1acf2a2cabd9cee91dc3fe3d35805fa8b This has already been reported in https://bugs.debian.org/1038207 and I am merging these bugs.
Bug#1040840: tp-smapi-dkms: Thinkpad fails to wake from sleep correctly with tp-smapi-dkms after bookworm upgrade
On Wed, Jul 12, 2023 at 09:06:36AM +0200, Caren Hern wrote: > Hi Evgeni, > > yes I have suspend active. Hibernate was never working. Okay, I can at least double-check that against the machines I have here! > I am also confused now, because I just reinstalled the package (no errors) > but indead when I try to manually load it using modprobe it indead throws an > error (ERROR: could not insert 'tp_smapi': No such device or address). Yeah, that's more like what I've expected. The SMAPI interface was removed in the *20/*30 series in favor of plain ACPI and the module should (rightfully) refuse to load if it can't find SMAPI. The `thinkpad_ec` module has a `force_io` parameter to make it load on *some* half-supported models, but even that shouldn't do anything when there is no SMAPI at all. > I just don't understand how the issue suddenly disappeared after removing > the package. I am wondering if its something with some other part of DKMS. > Because straight after the upgrade the issue was there a lot, then I > reinstalled the two packages which have kernel modules (tp-smapi-dkms and > broadcom-sta-dkms) because I thought maybe they were built for the wrong > kernel or something and the issue went away for two weeks, until it suddenly > reappeared and subsequently disappeared again after I completely removed the > tp-smapi package. dkms *should* properly detect any kernel changes and rebuild stuff. > One time after a freeze I read through dmesg but didn't find anything that > looked of (to me!). > > I will keep it installed now and will let you know if it happens again. Thanks!
Bug#1040840: tp-smapi-dkms: Thinkpad fails to wake from sleep correctly with tp-smapi-dkms after bookworm upgrade
Hi, On Tue, Jul 11, 2023 at 02:24:38PM +0200, Caren Hern wrote: > After upgrading to from bulleye to bookworm (Kernel version 6.1.0-9) I > experienced frequent freezes after wake. > The power LED would light up, and I was able to toggle the keyboard > backlight, but no other buttons responded (such as Fn-Lock light) > and the screen was black. One single time the screen showed the login window, > but still everything was unresponsive. I've not seen that on my X201s, but I don't suspend too much. Are you using Suspend (to RAM) or Hibernate (to Disk)? > > After trying various changes I removed all install DKMS modules one by one, > until I found that just with tp-smapi-dkms uninstalled there has been no > freezes in the last week (before the machine would freeze approx. 60% of > times after wake, multiple times a day). > > Thinkpad T470 tp-smapi shouldn't work on that model at all and refuse to load. (but I have no matching machine to verify that behaviour) Confused Evgeni
Bug#987332: aprx automatically starts up with really bad default config
On Sun, Apr 25, 2021 at 03:41:38PM +0300, Heikki Hannikainen wrote: > On Sun, 25 Apr 2021, Evgeni Golov wrote: > > > On Thu, Apr 22, 2021 at 12:19:57AM +0300, Heikki Hannikainen wrote: > > > > > - Remove N0CALL-1 from the default configuration (comment the line out) so > > > that it will refuse to start up before configured with the callsign of the > > > user > > > > Is N0CALL-1 part of the default config aprx ships upstream? > > I am afraid it is. Not sure if debian ships the upstream default config file > or its own. Looks like it's shipping upstream, yeah. > > > - Ensure that the instances which have already been started up like this > > > will shut down again when upgraded to the next version > > > > Not sure this is easily doable after the fact now, but we at least can > > prevent new clients from poping up. > > This would be very important to make this happen. Shipping a config with the > "mycall N0CALL-1" line commented out would probably work. I am not the maintainer of aprx, just someone who wants to fix a bug, so I'd prefer not to have the last call on this, but let me give you my view: If we change the default config, but let the service enabled, it will fail to start (which is *technically* what you want, as it will prevent wrongly configured installations from connecting to you). At the same time, everyone who updates from Buster to Bullseye (and has the bad old config) will face a failed upgrade and has to search why it failed, what they have to fix and then restart the upgrade. We're not breaking a working service with this approach, but it also feels weird towards the user (even if we can question why they have aprx installed, when it's not properly configured -- or is there any use without the daemon running correctly?). I think it should be possible to detect the "N0CALL" configurations on upgrade and disable the service, thus reaching the same state as with my above change for new installs. This, plus some documentation in README.Debian would make the user expirience much better than a failed upgrade? Evgeni
Bug#987332: aprx automatically starts up with really bad default config
Hi, On Thu, Apr 22, 2021 at 12:19:57AM +0300, Heikki Hannikainen wrote: > - Have it not start up by default after installation, before it is configured This should be doable by the following patch: diff -Nru aprx-2.9.0+dfsg/debian/rules aprx-2.9.0+dfsg/debian/rules --- aprx-2.9.0+dfsg/debian/rules2018-09-27 03:20:51.0 + +++ aprx-2.9.0+dfsg/debian/rules2021-04-25 08:47:13.0 + @@ -31,10 +31,13 @@ rm -vf ./test ./aprx-complex.conf Makefile override_dh_installinit: - dh_installinit --restart-after-upgrade + dh_installinit --restart-after-upgrade --no-enable override_dh_installdirs: dh_installdirs $(MAKE) DESTDIR=$(CURDIR)/debian/aprx logrotate.aprx install cp logrotate.aprx debian/aprx.logrotate install -m 644 apparmor.aprx $(CURDIR)/debian/aprx/etc/apparmor.d/sbin.aprx + +override_dh_installsystemd: + dh_installsystemd --no-enable > - Remove N0CALL-1 from the default configuration (comment the line out) so > that it will refuse to start up before configured with the callsign of the > user Is N0CALL-1 part of the default config aprx ships upstream? > - Ensure that the instances which have already been started up like this > will shut down again when upgraded to the next version Not sure this is easily doable after the fact now, but we at least can prevent new clients from poping up.
Bug#987113: ruby-librarian: autopkgtest failure: times out everywhere
On Sat, Apr 24, 2021 at 07:46:32PM +0200, Evgeni Golov wrote:
> Moin,
>
> On Sat, Apr 17, 2021 at 10:20:45PM +0200, Paul Gevers wrote:
> > Librarian::Mock::Cli
> > version
> > autopkgtest [04:30:22]: ERROR: timed out on command "su -s /bin/bash
>
> poking around this…
> the tests pass fine as long the deb is not installed (so it's only
> running from the source checkout), and freeze instantly when it is.
>
> (I can repro in a clean bullseye container, without autopkgtest/debci
> involved at all: rake -f debian/ruby-tests.rake)
So the issue is that when it runs the tests with the installed code, it
can't find the "root" of the project in [1] and tries to traverse in an
endless loop (as the original code assumes the tests are run in-tree).
Trivial patch that "fixes" it is the following:
diff --git lib/librarian/rspec/support/cli_macro.rb
lib/librarian/rspec/support/cli_macro.rb
index 21ffb3f..2cf91e1 100644
--- lib/librarian/rspec/support/cli_macro.rb
+++ lib/librarian/rspec/support/cli_macro.rb
@@ -51,7 +51,7 @@ module Librarian
def self.included(base)
base.instance_exec do
let(:project_path) do
- project_path = Pathname.new(__FILE__).expand_path
+ project_path = Pathname.pwd.expand_path
project_path = project_path.dirname until
project_path.join("Rakefile").exist?
project_path
end
But I still find that super ugly and not sure it's the right approach
here.
[1]
https://github.com/voxpupuli/librarian/blob/v0.6.4/lib/librarian/rspec/support/cli_macro.rb#L54-L55
Bug#987113: ruby-librarian: autopkgtest failure: times out everywhere
Moin, On Sat, Apr 17, 2021 at 10:20:45PM +0200, Paul Gevers wrote: > Librarian::Mock::Cli > version > autopkgtest [04:30:22]: ERROR: timed out on command "su -s /bin/bash poking around this… the tests pass fine as long the deb is not installed (so it's only running from the source checkout), and freeze instantly when it is. (I can repro in a clean bullseye container, without autopkgtest/debci involved at all: rake -f debian/ruby-tests.rake)
Bug#981699: thinkfan: fails on upgrade
On March 4, 2021 3:50:21 PM UTC, gregor herrmann wrote: >On Tue, 02 Mar 2021 22:44:24 +, Thorsten Glaser wrote: > >> and the new one doesn’t work, and I don’t even >> know what I’m supposed to put where. Perhaps upstream has some kind >> of list what model needs which settings? Also, YAML is such a weird >> format unfriendly to human editing… > >What "works" is to put > >-c /etc/thinkfan.conf > >into DAEMON_ARGS in /etc/default/thinkfan, i.e. use the old config. > >In the meantime I've converted the old .conf to a new .yaml for my >Thinkpad, starting from the example config in /etc and the new >thinkfan.conf manpage. > >I have no good idea for handling this on upgrades; _maybe_ shipping a >more minimal/generic /etc/thinkpad.yaml would help (the current one >is a huge exmple file with all kinds of options and will probably not >work for any machine); or ship it as an example and nothing in /etc >(which of course also breaks updates but apparently there's no good >way out of this). Yeah, not shipping the yaml is also what David proposed in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983727 and I think that's the cleanest we can go with. FWIW, you don't need -c if there is no yaml, it will find the old conf if it's called thinkfan.conf automatically. > > >Cheers, >gregor > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Bug#981699: thinkfan: fails on upgrade
On March 2, 2021 9:01:28 PM UTC, Thorsten Glaser wrote: >Evgeni Golov dixit: > >>>… without that it’ll also fail, which means it’ll fail package >>>installation, which is a serious (RC) bug. >> >>No, the daemon is not started on install > >Did that change recently? Because when I reported this bug first >it was precisely because it was started on install… No, it was like that since I've first uploaded the package to Debian. > >>, exactly because neither the old nor the new configuration is in a >>state where it's supposed to work out of the box. > >But why? The pre-YAML thing *did* work out of the box, very finely >so, and I only changed the config one hot summer to have a little >more quiet. This worked for *years*. 🤷♀️ If you happen to have a ThinkPad with exactly the same sensors like the author had when the example was written, you were just lucky. > >bye, >//mirabilos -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Bug#981699: thinkfan: fails on upgrade
On March 2, 2021 8:26:12 PM UTC, Thorsten Glaser wrote: >Evgeni Golov dixit: > >>> No, this is about the *vanilla* config shipped by the package. >>> It used to work (my adjustment later was only regarding the levels >>> of temperature as I’ve got an SSD, not HDD, so it can become a bit >>> higher for quietness) and now the package doesn’t work at all. >> >>Yeah, but that config is gone from the upstream tarball as it's >>deprecated. > >The YAML one? The conf one > >tglase@tglase-nb:~ $ ll /etc/thinkfan.* >-rw-r--r-- 1 root root 1976 Jun 23 2020 /etc/thinkfan.conf >-rw-r--r-- 1 root root 6999 Jan 27 21:06 /etc/thinkfan.yaml > >Nope, still there, not dpkg-maintscript-helper rm_conffile’d. It should be dpkg-bak tho, weird. > >But let’s see… > >tglase@tglase-nb:~ $ sudo rm /etc/thinkfan.yaml >[sudo] password for tglase: >tglase@tglase-nb:~ $ sudo mv /etc/thinkfan.conf /etc/thinkfan.old >tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start >Starting fan control tool: thinkfan >ERROR: /etc/thinkfan.conf: No such file or directory > failed! Well, it needs *one* present, not both gone ;) > >… without that it’ll also fail, which means it’ll fail package >installation, which is a serious (RC) bug. No, the daemon is not started on install, exactly because neither the old nor the new configuration is in a state where it's supposed to work out of the box. > >Honestly, all this hassle, I’d consider reverting to the last >working (pre-YAML) version, if it were me, and try to work >something out, over the next years, with upstream that actually >works… I'll just drop the package. I'm not using it myself anymore. > >bye, >//mirabilos -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Bug#981699: thinkfan: fails on upgrade
On Tue, Mar 02, 2021 at 07:28:11PM +, Thorsten Glaser wrote: > Evgeni Golov dixit: > > >> tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start > >> Starting fan control tool: thinkfan > >> ERROR: Error scanning > >> /sys/devices/pci:00/:00:03.1/:27:00.0/hwmon: No such file or > >> directory > >> failed! > > > >-3 has a NEWS.Debian explaining the change and how you can get your old > >config back. > > No, this is about the *vanilla* config shipped by the package. > It used to work (my adjustment later was only regarding the levels > of temperature as I’ve got an SSD, not HDD, so it can become a bit > higher for quietness) and now the package doesn’t work at all. Yeah, but that config is gone from the upstream tarball as it's deprecated.
Bug#981699: thinkfan: fails on upgrade
Hey, On Tue, Mar 02, 2021 at 04:13:01PM +0100, Thorsten Glaser wrote: > Unfortunately, thinkfan still fails to work: > > tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan stop > Stopping fan control tool: thinkfan. > tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start > Starting fan control tool: thinkfan > ERROR: Error scanning > /sys/devices/pci:00/:00:03.1/:27:00.0/hwmon: No such file or > directory > failed! -3 has a NEWS.Debian explaining the change and how you can get your old config back. Given there is no automatic conversion from the legacy config to yaml, I don't see what else the packaging could do here for you -- besides the not installation of the yaml in the first place, but then you'd still have to restore your old .conf…
Bug#983727: thinkfan should not ship an example in /etc/thinkfan.yaml
Hey again, On Mon, Mar 01, 2021 at 07:30:14PM +, Evgeni Golov wrote: > >By installing /etc/thinkfan.yaml on systems with a working configuration > >in /etc/thinkfan.conf, the daemon simply fails to start (while simply > >removing the new /etc/thinkfan.yaml allow one to start it again). > > Isn't the old one renamed to thinkfan.conf.dpkg-bak and thus not found? When I upgrade 0.9.3-2 (buster) to 1.2.1-3 I end up with: -rw-r--r--. 1 root root 1.8K Mar 2 19:05 /etc/thinkfan.conf.dpkg-bak -rw-r--r--. 1 root root 6.9K Feb 27 14:03 /etc/thinkfan.yaml So even if we'd not ship the new yaml, it wouldn't start and you'd have to manually rename the .conf.dpkg-bak to .conf.
Bug#983727: thinkfan should not ship an example in /etc/thinkfan.yaml
found 983727 1.2.1-1 thanks Hey David! Thanks for the report. On February 28, 2021 9:29:54 PM UTC, "David Prévot" wrote: >Package: thinkfan >Version: 1.2.1-3 >Severity: serious > >The “thinkfan Example Config File” currently shipped as >/etc/thinkfan.yaml “is NOT a working config file that can just be >copied” (quotes from the file itself). Technically, neither was the old one ;) >Pretending that “The new default configuration might not work for your >system” in NEWS.Debian implies that it could work in some cases, but >that does not seem to be the case at all. > >By installing /etc/thinkfan.yaml on systems with a working configuration >in /etc/thinkfan.conf, the daemon simply fails to start (while simply >removing the new /etc/thinkfan.yaml allow one to start it again). Isn't the old one renamed to thinkfan.conf.dpkg-bak and thus not found? >Please, ship the “thinkfan Example Config File” in >/usr/share/doc/thinkfan/examples in order to not break existing >configuration, especially since it can’t work as is anyway. I'll look into this that weekend. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Bug#958590: Bug#794384: hdapsd: diff for NMU version 1:20141203-1.1
Hey Adrian, On Fri, Feb 05, 2021 at 01:32:15PM +0200, Adrian Bunk wrote: > I've prepared an NMU for hdapsd (versioned as 1:20141203-1.1) and > uploaded it to DELAYED/1. Please feel free to tell me if I should > cancel it. Thanks, but NACK. I have prepared something similar (with more changes) in https://salsa.debian.org/debian/hdapsd/-/merge_requests/2, which I plan to upload this weekend. Evgeni
Bug#955279: sysdig: undefined symbol: _ZN4grpc13ClientContextC1Ev
Hi Bernhard, thanks for digging into this! I'd argue that the real bug is in the grpc package, as dropping symbols without a soname bump is bad. But that clearly doesn't help you now. CCing the maintainer of grpc, shall we reassign and you do the needed changes? Evgeni On April 5, 2020 11:49:04 AM UTC, "Bernhard Übelacker" wrote: >Dear Maintainer, >I tried to have a look and it looks like being related >to the libgrpc++1 package. > >The _ZN4grpc13ClientContextC1Ev symbol was included in >libgrpc++1 versions up to 1.17.2-1. >Since version 1.22.0-2 it is missing from that library. > >Because 1.26.0-2 is the first version after 1.16.1-1, >which got uploaded to unstable (other versions just in >experimental), this issue got visible since 2020-03-21. > >A local rebuild of sysdig against libgrpc++1 1.26.0-2 >seems to work. > >Therefore it looks like there was an ABI change in libgrpc++1. >I am not sure what actions on grpc side are needed, >but at least a rebuild of sysdig seems necessary. > >Kind regards, >Bernhard
Bug#950170: gimplensfun ftbfs with libexiv2-27
I think this is fixed by https://github.com/seebk/GIMP-Lensfun/commit/ca4511c1a4dd8edabe86e4a943861fda07b7e86c Feel free to 0day NMU, I don't have much time right now. On January 29, 2020 7:00:30 PM UTC, Paul Gevers wrote: >Source: gimplensfun >Version: 0.2.4-1 >Severity: serious >Justification: ftbfs >Tags: ftbfs sid bullseye > >Dear maintainer, > >exiv2 started a transition and I scheduled binNMUs. However, your >package failed. Please investigate. > >Paul > >Tail of log for gimplensfun on amd64: > >/usr/include/gimp-2.0/libgimp/gimpdrawable.h:52:16: note: declared here > 52 | GimpDrawable * gimp_drawable_get(gint32 >drawable_ID); > |^ >src/gimplensfun.cpp:1224:59: warning: ‘GimpDrawable* >gimp_drawable_get(gint32)’ is deprecated: Use 'gimp_drawable_get_buffer' >instead [-Wdeprecated-declarations] > 1224 | drawable = gimp_drawable_get (param[2].data.d_drawable); > | ^ >In file included from /usr/include/gimp-2.0/libgimp/gimp.h:41, > from src/gimplensfun.cpp:31: >/usr/include/gimp-2.0/libgimp/gimpdrawable.h:52:16: note: declared here > 52 | GimpDrawable * gimp_drawable_get(gint32 >drawable_ID); > |^ >make[1]: *** [Makefile:51: src/gimplensfun.o] Error 1 >make[1]: Leaving directory '/<>' >dh_auto_build: error: make -j1 returned exit code 2 >make: *** [debian/rules:15: build-arch] Error 25 > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Bug#938053: python-publicsuffix: diff for NMU version 1.1.0-2.1
Thanks Sandro, feel free to upload to sid without delay! On December 22, 2019 8:23:22 PM UTC, Sandro Tosi wrote: >Control: tags 938053 + patch > > >Dear maintainer, > >I've prepared an NMU for python-publicsuffix (versioned as 1.1.0-2.1). The diff >is attached to this message. > >Regards. >
Bug#937900: [pkg-lxc-devel] Bug#937900: python-lxc: Python2 removal in sid/bullseye
Hi Moritz, yeah, that sounds reasonable. PEB, terceiro, any objections? Evgeni On December 19, 2019 7:43:30 PM UTC, "Moritz Mühlenhoff" wrote: >On Fri, Aug 30, 2019 at 07:41:57AM +, Matthias Klose wrote: >> Package: src:python-lxc >> Version: 0.1-3 >> Severity: normal >> Tags: sid bullseye >> User: debian-pyt...@lists.debian.org >> Usertags: py2removal >> >> Python2 becomes end-of-live upstream, and Debian aims to remove >> Python2 from the distribution, as discussed in >> https://lists.debian.org/debian-python/2019/07/msg00080.html > >Hi Evgeni, >there are no remaining rdeps for python-lxc and Python 3 support is >available via the separate python3-lxc source package, let's remove? > >Cheers, >Moritz > >___ >Pkg-lxc-devel mailing list >pkg-lxc-de...@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-lxc-devel
Bug#885771: selinux-policy-dev package post-installation script subprocess returned error exit status 1
Package: selinux-policy-dev Version: 2:2.20171228-1 Severity: serious Ohai, upgrade to latest s-p-dev fails: Setting up selinux-policy-dev (2:2.20171228-1) ... Running sepolgen-ifgen...dpkg: error processing package selinux-policy-dev (--configure): installed selinux-policy-dev package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: selinux-policy-dev Looking closer, it seems polgen-ifgen fails: % sudo sepolgen-ifgen /usr/share/selinux/devel/include/support/obj_perm_sets.spt: Syntax error on line 157 ` [type=TICK] error parsing headers error parsing file /usr/share/selinux/devel/include/support/obj_perm_sets.spt: could not parse text: "/usr/share/selinux/devel/include/support/obj_perm_sets.spt: Syntax error on line 157 ` [type=TICK]" Regards Evgeni -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages selinux-policy-dev depends on: ii checkpolicy 2.7-1 ii gawk 1:4.1.4+dfsg-1 ii m41.4.18-1 ii make 4.1-9.1 ii policycoreutils 2.7-1 ii policycoreutils-dev 2.7-2 ii policycoreutils-python-utils 2.7-2 ii python2.7.14-4 ii selinux-utils 2.7-2 Versions of packages selinux-policy-dev recommends: ii setools 4.1.1-3 selinux-policy-dev suggests no packages. -- no debconf information
Bug#884973: tp-smapi-dkms: tp-smapi doesn't build for 4.15.0-rc?
control: severity -1 important On Fri, Dec 22, 2017 at 10:03:17AM +0100, Elimar Riesebieter wrote: > Package: tp-smapi-dkms > Version: 0.42-1 > Severity: serious > Justification: fails to build from source Nope. 4.15 is not in Debian (not even experimental), so it can't be serious. > tp-smapi doesn't build for the upcoming kernels 4.15: > > /var/lib/dkms/tp_smapi/0.42/build/hdaps.c: In function ‘hdaps_init’:¬ > /var/lib/dkms/tp_smapi/0.42/build/hdaps.c:781:2: error: implicit > declaration of function ‘init_timer’; did you mean ‘init_timers’? [-Werr> > init_timer(&hdaps_timer);¬ > ^~¬ > init_timers¬ > /var/lib/dkms/tp_smapi/0.42/build/hdaps.c:782:23: error: assignment from > incompatible pointer type [-Werror=incompatible-pointer-types]¬ > hdaps_timer.function = hdaps_mousedev_poll; Thanks for the report, I'll have a look with my upstream hat on when I find some time. Evgeni
Bug#880502: [pkg-lxc-devel] Bug#880502: lxc: cannot start container with kernel 4.13.10
Ohai, On Wed, Nov 01, 2017 at 12:00:12PM -0200, Antonio Terceiro wrote: > > lxc-start 20171101123914.655 ERRORlxc_apparmor - > > lsm/apparmor.c:apparmor_process_label_set:220 - If you really want to start > > this container, set > > lxc-start 20171101123914.655 ERRORlxc_apparmor - > > lsm/apparmor.c:apparmor_process_label_set:221 - lxc.aa_allow_incomplete = 1 > > lxc-start 20171101123914.655 ERRORlxc_apparmor - > > lsm/apparmor.c:apparmor_process_label_set:222 - in your container > > configuration file > So, I tried downgrading the kernel to the one in testing, rebooted, and > now I can start containers again, So this is being caused by a change in > the kernel between 4.13.4-2 and 4.13.10-1 > > I still need to study the lxc code path that is being triggered to be > able to provide more useful information. Since the issue is definitively > related to apparmor, I am also copying the apparmor team in case they > have any input to provide. Can you try to set "lxc.aa_allow_incomplete = 1" in your config? LXC expects Ubuntus patched kernels when it comes to AppArmor, not the upstream ones :( And I think Debian enabled AppArmor by default in the latest kernels. Evgeni
Bug#880217: ansible-tower-cli-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/ansible-tower-cli/CONFIG_CMD_OPTIONS.md.gz
Hi, On Mon, Oct 30, 2017 at 06:23:32PM +0100, Andreas Beckmann wrote: > See policy 7.6 at > https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces This should be https://www.debian.org/doc/debian-policy/#overwriting-files-and-replacing-packages-replaces Where can I file a bug against your templates? ;) > From the attached log (scroll to the bottom...): I'll fix these asap, thanks! Evgeni
Bug#873386: LuaJIT 2.1 breaks Lua 5.1 API
Package: libluajit-5.1-dev Version: 2.1.0~beta3+dfsg-2 Severity: serious Tags: upstream Hi, LuaJIT 2.1 introduces symbols from Lua 5.2 [1] and drops a few compat symbols [2] that are still present in Lua 5.1 [3]. This breaks software that either not expects these 5.2 symbols, or expects the compat stuff to be present. [4] I don't think the current state is apropriate for testing. Regards Evgeni [1] https://github.com/LuaJIT/LuaJIT/commit/de97b9d52bbc42effeaf1180764053a912526873 [2] https://github.com/LuaJIT/LuaJIT/commit/dc320ca70f2c5bb3977b82853bcee6dad2523d01 [3] https://www.lua.org/source/5.1/lauxlib.h.html [4] https://github.com/LuaJIT/LuaJIT/issues/325 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libluajit-5.1-dev:amd64 depends on: ii libluajit-5.1-2 2.1.0~beta3+dfsg-2 libluajit-5.1-dev:amd64 recommends no packages. libluajit-5.1-dev:amd64 suggests no packages. -- no debconf information
Bug#869186: [Pkg-mutt-maintainers] Bug#869186: mutt: Install missing required dependencies (libxapian30)
Hi, On Fri, Jul 21, 2017 at 07:02:50AM -0400, Boruch Baum wrote: > Upon upgrading `mutt' from the stable to testing repositories, mutt > ceased to function, offering the following error message: There is no mutt 1.7.2-1 in testing. Did you mean upgrading jessie→stretch? >#+BEGIN_SRC conf >mutt: symbol lookup error: /usr/lib/x86_64-linux-gnu/libnotmuch.so.4: >undefined symbol: > _ZN6Xapian9Compactor26resolve_duplicate_metadataERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmPS7_ >#+End_SRC > > Performing the following fixed the problem for me: > >#+BEGIN_SRC conf >apt-get install libxapian30 > >The following packages will be upgraded: > libxapian-dev libxapian30 xapian-tools >#+END_SRC ¯\_(ツ)_/¯ mutt has a dependency on libnotmuch4, libnotmuch4 has a dependency on libxapian30, mutt is not using any xapian directly AFAIK. so we might discuss this as being a not-strong-enough dep between libnotmuch4 and libxapian30, but not a serios bug in mutt. > -- System Information: > Distributor ID: Devuan > Description: Devuan GNU/Linux 1.0 (jessie) > Release: 1.0 > Codename: jessie > Architecture: x86_64 Why do you have mutt from stretch on a jessie(-derived) system?
Bug#857295: [pkg-lxc-devel] Bug#857295: Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)
Hi Stiepan, On Fri, Mar 24, 2017 at 10:51:24AM -0400, Stiepan wrote: > Using a bridge set up with libvirt (as in > http://wiki.libvirt.org/page/Networking#NAT_forwarding_.28aka_.22virtual_networks.22.29) > doesn't work. Is that what the libvirt package does on Debian out-of-the-box? If so it works just fine for me on my laptop where I put the containers on the vibr0 created by libvirt. > Neither does using a bridge set up as indicated in > https://wiki.debian.org/LXC/SimpleBridge#Using_lxc-net (causes the same > errors as with libvirt). So I just fired a fresh jessie+backports Vagrant box and it worked fine (incl network in the container): $ vagrant init debian/jessie64 $ vagrant up $ vagrant ssh vagrant@jessie:~$ sudo nano /etc/apt/sources.list deb http://httpredir.debian.org/debian jessie-backports main vagrant@jessie:~$ sudo apt update vagrant@jessie:~$ sudo apt install lxc/jessie-backports lxcfs vagrant@jessie:~$ sudo nano /etc/default/lxc-net USE_LXC_BRIDGE="true" vagrant@jessie:~$ systemctl enable lxc-net vagrant@jessie:~$ systemctl restart lxc-net vagrant@jessie:~$ ip a s dev lxcbr0 3: lxcbr0: mtu 1500 qdisc noqueue state DOWN group default link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 scope global lxcbr0 valid_lft forever preferred_lft forever vagrant@jessie:~$ sudo sysctl -w kernel.unprivileged_userns_clone=1 vagrant@jessie:~$ exit # needed to trigger lxcfs' PAM module $vagrant ssh vagrant@jessie:~$ cat /proc/self/cgroup 8:perf_event:/ 7:blkio:/ 6:net_cls,net_prio:/ 5:freezer:/user/vagrant/0 4:devices:/ 3:cpu,cpuacct:/ 2:cpuset:/ 1:name=systemd:/user/vagrant/0 vagrant@jessie:~$ mkdir ~/.config/lxc/ -p vagrant@jessie:~$ nano ~/.config/lxc/default.conf xc.include = /etc/lxc/default.conf lxc.id_map = u 0 624288 65536 lxc.id_map = g 0 624288 65536 vagrant@jessie:~$ sudo nano /etc/lxc/lxc-usernet vagrant veth lxcbr0 10 vagrant@jessie:~$ lxc-create -n jessie -t download -- -d debian -r jessie -a amd64 vagrant@jessie:~$ nano .local/share/lxc/jessie/config lxc.network.type=veth lxc.network.flags=up lxc.network.link=lxcbr0 vagrant@jessie:~$ lxc-start -n jessie vagrant@jessie:~$ lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 jessie RUNNING 0 - -- > Using a classical / "plain old" / you-name-it bridge, set up as in > http://wiki.libvirt.org/page/Networking#Altering_the_interface_config, does > work. I don't see any technical difference between the plain br0 setup with this link and the ones created by lxc-net or libvirt. Can you point them out please? > By the way, the lxc_delete_network:3028... additional error I was seeing pops > up only when /etc/lxc/lxc-usernet is still set to use br0, whilst the LXC > container is > set to use virbr0 and hence can be ignored, sorry about that. When properly > configured (i.e. when both are configured to use virbr0, or lxcbr0), > container startup > simply fails with a "Failed to create the configured network" error, but > still fails, whereas when using classical br0, it works. Can you please provide the steps how to setup your setup from a plain jessie or stretch image? > So, if your bridge is set up as suggested in > https://wiki.debian.org/BridgeNetworkConnections' Manual bridge setup > section, using either brctl or > /etc/network/interfaces (for a persistent config), we have the same > configuration and it works, which is fine. Still, I thought that LXC enabled > using lxcbr0 bridges > in user mode, as lxc-user-nic's man page suggests is possible. Can you > confirm whether this is the case with the current version? lxc-user-nic is to attach a user-namespace-nic to an existing bridge, you can't create a bridge with it.
Bug#857295: [pkg-lxc-devel] Bug#857295: Info received ([oss-security] LXC: CVE-2017-5985: lxc-user-nic didn't verify network namespace ownership)
Hi, On Fri, Mar 24, 2017 at 05:03:57AM -0400, Stiepan wrote: > Fyi, now that lxc 2.0.7-2 landed in jessie-backports, I am getting a new > error when trying to start an lxc instance (running jessie as well) using a > virtual br0 rather than "plain old" br0 (all of this in unprivileged mode), > namely: lxc_delete_network:3028 - Failed to remove interface "vethXJW6PL" > from host: Operation not permitted. With "plain old" br0, it still works as > expected. Can you alaborate a bit more on your network setup please? What is a "virtual br0"? How do you you set this up? My setup uses brctl to setup the bridge and then unpviliged containers work fine. I guess that is "plain old" for ya? Regards Evgeni
Bug#855671: chaussette: FTBFS: ConnectionError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /
Control: tags -1 + patch On Sun, Mar 19, 2017 at 10:06:01AM +0100, Evgeni Golov wrote: > > > socket.error: [Errno 92] Protocol not available > > > > That's probably https://github.com/circus-tent/chaussette/issues/82? > > But the traceback looks different, so not setting forwarded just yet. > > Confirmed, downgading python-waitress to 0.8.10-1 from snapshot.d.o makes the > test succeed. I posted a patch [1] upstream [2], let's see what they think. [1] https://github.com/circus-tent/chaussette/pull/83/commits/e10c891bb2a003dd7827f7d96bf458e0e4ca2dd8 [2] https://github.com/circus-tent/chaussette/pull/83
Bug#855671: chaussette: FTBFS: ConnectionError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /
Control: forwarded -1 https://github.com/circus-tent/chaussette/issues/82 Control: tags -1 + upstream Control: retitle -1 FTBFS: chaussette incompatible with waitress 1.0, tests fail On Sun, Mar 19, 2017 at 08:56:42AM +0100, Evgeni Golov wrote: > On Sun, Mar 19, 2017 at 08:48:47AM +0100, Evgeni Golov wrote: > > > The issue is that the waitress backend does not start: > > % /usr/bin/python2.7 -m chaussette.server --backend waitress > > 2017-03-19 08:46:54 [23969] [INFO] Application is > 0x7f6317213758> > > 2017-03-19 08:46:54 [23969] [INFO] Serving on localhost:8080 > > 2017-03-19 08:46:54 [23969] [INFO] Using > 'chaussette.backend._waitress.Server'> as a backend > > Traceback (most recent call last): > > File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main > > "__main__", fname, loader, pkg_name) > > File "/usr/lib/python2.7/runpy.py", line 72, in _run_code > > exec code in run_globals > > File > > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > > line 228, in > > main() > > File > > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > > line 224, in main > > inner() > > File > > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > > line 205, in inner > > socket_type=_SOCKET_TYPE[args.socket_type]) > > File > > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > > line 38, in make_server > > server = server_class((host, port), app, **server_class_kwargs) > > File "chaussette/backend/_waitress.py", line 20, in __init__ > > port=port) > > File "/usr/lib/python2.7/dist-packages/waitress/server.py", line 179, in > > __init__ > > self.socket.setsockopt(IPPROTO_IPV6, IPV6_V6ONLY, 1) > > File "/usr/lib/python2.7/socket.py", line 228, in meth > > return getattr(self._sock,name)(*args) > > socket.error: [Errno 92] Protocol not available > > That's probably https://github.com/circus-tent/chaussette/issues/82? > But the traceback looks different, so not setting forwarded just yet. Confirmed, downgading python-waitress to 0.8.10-1 from snapshot.d.o makes the test succeed.
Bug#855671: chaussette: FTBFS: ConnectionError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /
On Sun, Mar 19, 2017 at 08:48:47AM +0100, Evgeni Golov wrote: > The issue is that the waitress backend does not start: > % /usr/bin/python2.7 -m chaussette.server --backend waitress > 2017-03-19 08:46:54 [23969] [INFO] Application is 0x7f6317213758> > 2017-03-19 08:46:54 [23969] [INFO] Serving on localhost:8080 > 2017-03-19 08:46:54 [23969] [INFO] Using 'chaussette.backend._waitress.Server'> as a backend > Traceback (most recent call last): > File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main > "__main__", fname, loader, pkg_name) > File "/usr/lib/python2.7/runpy.py", line 72, in _run_code > exec code in run_globals > File > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > line 228, in > main() > File > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > line 224, in main > inner() > File > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > line 205, in inner > socket_type=_SOCKET_TYPE[args.socket_type]) > File > "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", > line 38, in make_server > server = server_class((host, port), app, **server_class_kwargs) > File "chaussette/backend/_waitress.py", line 20, in __init__ > port=port) > File "/usr/lib/python2.7/dist-packages/waitress/server.py", line 179, in > __init__ > self.socket.setsockopt(IPPROTO_IPV6, IPV6_V6ONLY, 1) > File "/usr/lib/python2.7/socket.py", line 228, in meth > return getattr(self._sock,name)(*args) > socket.error: [Errno 92] Protocol not available That's probably https://github.com/circus-tent/chaussette/issues/82? But the traceback looks different, so not setting forwarded just yet.
Bug#855671: chaussette: FTBFS: ConnectionError: HTTPConnectionPool(host='localhost', port=8080): Max retries exceeded with url: /
Hi, On Tue, Feb 21, 2017 at 09:29:50AM +0100, David Douard wrote: > Thanks for the bug report. I'll try to investiate this (as well as several > other small issues) ASAP (probably not before one or 2 weeks however). The issue is that the waitress backend does not start: % /usr/bin/python2.7 -m chaussette.server --backend waitress 2017-03-19 08:46:54 [23969] [INFO] Application is 2017-03-19 08:46:54 [23969] [INFO] Serving on localhost:8080 2017-03-19 08:46:54 [23969] [INFO] Using as a backend Traceback (most recent call last): File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", line 228, in main() File "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", line 224, in main inner() File "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", line 205, in inner socket_type=_SOCKET_TYPE[args.socket_type]) File "/home/evgeni/Debian/BSP/credativ2017/chaussette-1.3.0/chaussette/server.py", line 38, in make_server server = server_class((host, port), app, **server_class_kwargs) File "chaussette/backend/_waitress.py", line 20, in __init__ port=port) File "/usr/lib/python2.7/dist-packages/waitress/server.py", line 179, in __init__ self.socket.setsockopt(IPPROTO_IPV6, IPV6_V6ONLY, 1) File "/usr/lib/python2.7/socket.py", line 228, in meth return getattr(self._sock,name)(*args) socket.error: [Errno 92] Protocol not available But it is announced as available: >>> import chaussette.backend >>> chaussette.backend.backends() ['eventlet', 'fastgevent', 'gevent', 'geventwebsocket', 'geventws4py', 'socketio', 'tornado', 'waitress', 'wsgiref']
Bug#857794: reportbug: crash when encountering some non-ASCII characters
Hi Dima, > Hi. I just tried to send an unblock, and reportbug crashed. Session: > > dima@scrawny:~$ sudo apt install reportbug > ... > Please enter the name of the package: geda-gaf > Checking status database... > Traceback (most recent call last): … > return codecs.ascii_decode(input, self.errors)[0] > UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in position 327: > ordinal not in range(128) The package has "أحمد المحمودي (Ahmed El-Mahmoudy) " as uploader. And that is not parsable by your non Unicode environment. > Presumably there's some non-ascii something somewhere that's tripping it > up. It is 100% reproducible, and as you can see I'm using the latest > available reportbug. Thanks. I can reproduce it with LC_ALL=C, but not with C.UTF-8. I would argue that reportbug can't do anything here, as your environment just can't display the string correctly.
Bug#845323: Issue resolved
Hi On Mon, Dec 05, 2016 at 02:21:24PM +0100, pyt...@gmx.li wrote: > After playing around a while with the packets I could figure out, that the > package is working with the stable version of "python-ethtool" (currently > 0.11-2). Thanks for the report and the debugging. This could be https://bugs.debian.org/857346 Can you please test the packages at [1] which contain a patch for the above bug? Regards Evgeni [1] https://people.debian.org/~evgeni/tmp/python-ethtool/
Bug#857346: python-ethtool: diff for NMU version 0.12-1.1
Control: tags 857346 + pending Dear maintainer, I've prepared an NMU for python-ethtool (versioned as 0.12-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. Evgeni diff -Nru python-ethtool-0.12/debian/changelog python-ethtool-0.12/debian/changelog --- python-ethtool-0.12/debian/changelog 2016-09-24 15:34:09.0 +0200 +++ python-ethtool-0.12/debian/changelog 2017-03-18 16:47:04.0 +0100 @@ -1,3 +1,15 @@ +python-ethtool (0.12-1.1) unstable; urgency=medium + + * Non-maintainer upload. + + [ Evgeni Golov ] + * update Homage in d/control + + [ Reiner Herrmann ] + * Fix argument parsing in C library (Closes: #857346) + + -- Evgeni Golov Sat, 18 Mar 2017 16:47:04 +0100 + python-ethtool (0.12-1) unstable; urgency=medium * [ea5192b] Fix some other gcc5 warnings. diff -Nru python-ethtool-0.12/debian/control python-ethtool-0.12/debian/control --- python-ethtool-0.12/debian/control 2016-09-24 15:34:09.0 +0200 +++ python-ethtool-0.12/debian/control 2017-03-17 16:34:53.0 +0100 @@ -5,7 +5,7 @@ Maintainer: Bernd Zeimetz Build-Depends: debhelper (>= 7.0.50~), python-all-dev (>= 2.6.6-3~), libnl-route-3-dev, asciidoc, pkg-config, libxml2-utils, docbook-xml, xsltproc, sgml-data, libxml2, docbook-xsl, docbook-xml Standards-Version: 3.9.3 -Homepage: http://fedorapeople.org/gitweb?p=dsommers/public_git/python-ethtool.git;a=summary +Homepage: https://fedorapeople.org/cgit/dsommers/public_git/python-ethtool.git/ Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/spacewalk/python-ethtool.git Vcs-Git: git://anonscm.debian.org/collab-maint/spacewalk/python-ethtool.git diff -Nru python-ethtool-0.12/debian/patches/fix_argument_parsing python-ethtool-0.12/debian/patches/fix_argument_parsing --- python-ethtool-0.12/debian/patches/fix_argument_parsing 1970-01-01 01:00:00.0 +0100 +++ python-ethtool-0.12/debian/patches/fix_argument_parsing 2017-03-17 16:37:38.0 +0100 @@ -0,0 +1,111 @@ +Author: Reiner Herrmann +Description: Fix argument parsing of device names + PyArg_ParseTuple was called with the format string "s*" to parse the + passed device name into a C string. + But according to Python C-API documentation, "s*" is used for parsing data + into a Py_buffer structure: https://docs.python.org/2/c-api/arg.html + To store it into a C string, "s" has to be used. + (Memory doesn't need to be freed, as it is managed by Python.) +Bug-Debian: https://bugs.debian.org/857346 + +--- a/python-ethtool/ethtool.c b/python-ethtool/ethtool.c +@@ -121,7 +121,7 @@ + const char *devname; + char hwaddr[20]; + +- if (!PyArg_ParseTuple(args, "s*", &devname)) ++ if (!PyArg_ParseTuple(args, "s", &devname)) + return NULL; + + /* Setup our request structure. */ +@@ -163,7 +163,7 @@ + const char *devname; + char ipaddr[20]; + +- if (!PyArg_ParseTuple(args, "s*", &devname)) ++ if (!PyArg_ParseTuple(args, "s", &devname)) + return NULL; + + /* Setup our request structure. */ +@@ -295,7 +295,7 @@ + const char *devname; + int fd, err; + +- if (!PyArg_ParseTuple(args, "s*", &devname)) ++ if (!PyArg_ParseTuple(args, "s", &devname)) + return NULL; + + /* Setup our request structure. */ +@@ -328,7 +328,7 @@ + const char *devname; + char netmask[20]; + +- if (!PyArg_ParseTuple(args, "s*", &devname)) ++ if (!PyArg_ParseTuple(args, "s", &devname)) + return NULL; + + /* Setup our request structure. */ +@@ -368,7 +368,7 @@ + const char *devname; + char broadcast[20]; + +- if (!PyArg_ParseTuple(args, "s*", &devname)) ++ if (!PyArg_ParseTuple(args, "s", &devname)) + return NULL; + + /* Setup our request structure. */ +@@ -409,7 +409,7 @@ + char buf[2048]; + const char *devname; + +- if (!PyArg_ParseTuple(args, "s*", &devname)) ++ if (!PyArg_ParseTuple(args, "s", &devname)) + return NULL; + + /* Setup our control structures. */ +@@ -479,7 +479,7 @@ + char buf[1024]; + const char *devname; + +- if (!PyArg_ParseTuple(args, "s*", &devname)) ++ if (!PyArg_ParseTuple(args, "s", &devname)) + return NULL; + + /* Setup our control structures. */ +@@ -545,7 +545,7 @@ + const char *devname; + int err = -1; + +- if (PyArg_ParseTuple(args, "s*", &devname)) ++ if (PyArg_ParseTuple(args, "s", &devname)) + err = send_command(cmd, devname, value); + + return err; +@@ -567,7 +567,7 @@ + struct ethtool_value eval; + const char *devname; + +- if (!PyArg_ParseTuple(args, "s*i", &devname, &eval.data)) ++ if (!PyArg_ParseTuple(args, "si", &devname, &eval.data)) + return -1; + + return send_command(cmd, devname, &eval); +@@ -752,7 +752,7 @@ + const char *devname; + PyObject *dict; + +- if (!PyAr
Bug#857346: Segmentation Fault when trying to use get_hwaddr()
On Fri, Mar 17, 2017 at 08:11:18PM +0100, Reiner Herrmann wrote: > On Fri, Mar 17, 2017 at 07:45:49PM +0100, Evgeni Golov wrote: > > It's now on > > https://fedorapeople.org/cgit/dsommers/public_git/python-ethtool.git/ > > Is that the official repository? It looks outdated (version 0.12 is > missing there). It is at least the same repo (but a different url, cgit instead of gitweb) as before. I could not find any newer version or repo yet. > > I am currently looking into #845323 and wonder if that is related to this. > > It's very likely the same issue: > > $ grep -r ethtool > ovirt-guest-agent/GuestAgentLinux2.py: import ethtool > ovirt-guest-agent/GuestAgentLinux2.py: 'hw': > self.ethtool.get_hwaddr(dev)}) Yepp, but I wanted to be sure ;)
Bug#857346: Segmentation Fault when trying to use get_hwaddr()
Ohai, On Wed, Mar 15, 2017 at 01:30:01PM +0100, Reiner Herrmann wrote: > The reason for the segmentation faults is that the arguments > passed to several functions are parsed incorrectly in the C > library. > They use the format string "s*" instead of "s", which would > require a Py_buffer structure instead of a C string. > > The attached patch fixes this everywhere arguments are parsed > into a C string. Yepp, I can confirm that the patch fixes the issue. > And btw. the upstream homepage seems to have disappeared, > so I don't know where to forward the patch to. It's now on https://fedorapeople.org/cgit/dsommers/public_git/python-ethtool.git/ I am currently looking into #845323 and wonder if that is related to this. I'd upload an NMU if bzed does not scream too loud tomorrow. Greets Evgeni
Bug#857089: Fix dh_installinit options
On Sun, Mar 12, 2017 at 06:30:52PM +0100, Wolfgang Schweer wrote: > On Sun, Mar 12, 2017 at 06:04:00PM +0100, Evgeni Golov wrote: > > On Sun, Mar 12, 2017 at 05:42:34PM +0100, Wolfgang Schweer wrote: > > > One point: > > > For the d/NEWS file to be actually shipped, at least for me this > > > additional patch was needed: > > > > Uh? It should be automatically installed by dh_installchangelogs. > > And happens here (it gets installed as > > /usr/share/doc/thinkfan/NEWS.Debian.gz). > > Wonder why this did not work for you. > > Maybe due to a different build tool; I used 'debuild -- binary'. Weird. I do build with gbp, but that also uses debuild under the hood. Anyways, let's see what RT thinks about the diff. > > Btw, are you interested in co-maintaining thinkfan? The package could > > certainly use another pair of eyes :) > > Well, that would be beyond my skills; but I can try to do testing and > give feedback. Will be around in MG-Wickradt next Saturday, I guess. Cool. See you there :) I would pay you some $favouritedrinks for all the testing, but I guess my ex-employeer is paying anyways ;)
Bug#857089: Fix dh_installinit options
Hey, On Sun, Mar 12, 2017 at 05:42:34PM +0100, Wolfgang Schweer wrote: > On Sun, Mar 12, 2017 at 09:16:46AM +0100, Evgeni Golov wrote: > > I went a bit further, droped that code, and migrated the setting > > to update-rc.d on upgrade. See attached patchset. > > > > What do you think? > > Looks awesome. > > Tested all possible variants using both systemd and sysv related > commands. Seems to work like expected in all cases. Thanks for testing! > One point: > For the d/NEWS file to be actually shipped, at least for me this > additional patch was needed: Uh? It should be automatically installed by dh_installchangelogs. And happens here (it gets installed as /usr/share/doc/thinkfan/NEWS.Debian.gz). Wonder why this did not work for you. Btw, are you interested in co-maintaining thinkfan? The package could certainly use another pair of eyes :) Gruesse Evgeni
Bug#857089: Fix dh_installinit options
Hi,
On Sat, Mar 11, 2017 at 10:03:34PM +0100, Wolfgang Schweer wrote:
> > There is still one thing left: in the SysV case, the user will have to
> > issue update-rc.d thinkfan enable AND edit /etc/default/thinkfan.
> >
> > Thinking how to fix that.
>
> I guess it would be sufficient to add a line to /etc/default/thinkfan,
> so that it's like this:
>
> # Should thinkfan be started automatically on boot?
> # Only say "yes" when you know what you are doing, have configured
> # thinkfan correctly for *YOUR* machine and loaded thinkpad_acpi
> # with fan_control=1 (if you have a ThinkPad).
> # Also, running 'update-rc.d thinkfan enable' is needed.
> START=no
I went a bit further, droped that code, and migrated the setting
to update-rc.d on upgrade. See attached patchset.
What do you think?
>From b5d70ee07a27b4baae726c36786b78725dec0a5a Mon Sep 17 00:00:00 2001
From: Evgeni Golov
Date: Sat, 11 Mar 2017 14:58:59 +0100
Subject: [PATCH 1/4] call update-rc.d thinkfan disable on fresh installs
Closes: #758579
---
debian/thinkfan.lintian-overrides | 3 +++
debian/thinkfan.postinst | 44 +++
2 files changed, 47 insertions(+)
create mode 100644 debian/thinkfan.lintian-overrides
create mode 100644 debian/thinkfan.postinst
diff --git a/debian/thinkfan.lintian-overrides b/debian/thinkfan.lintian-overrides
new file mode 100644
index 000..62ce724
--- /dev/null
+++ b/debian/thinkfan.lintian-overrides
@@ -0,0 +1,3 @@
+# pre-deployment of a disabled service as dh_installinit is
+# not capable to do so for us.
+thinkfan: duplicate-updaterc.d-calls-in-postinst thinkfan
diff --git a/debian/thinkfan.postinst b/debian/thinkfan.postinst
new file mode 100644
index 000..c385313
--- /dev/null
+++ b/debian/thinkfan.postinst
@@ -0,0 +1,44 @@
+#!/bin/sh
+# postinst script for thinkfan
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#* `configure'
+#* `abort-upgrade'
+#* `abort-remove' `in-favour'
+#
+#* `abort-remove'
+#* `abort-deconfigure' `in-favour'
+#`removing'
+#
+# for details, see https://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+
+case "$1" in
+configure)
+if [ -x "/etc/init.d/thinkfan" ] && [ -z "$2" ]; then
+# Disable the service by default on new installations
+update-rc.d thinkfan defaults >/dev/null || true
+update-rc.d thinkfan disable >/dev/null || true
+ fi
+;;
+
+abort-upgrade|abort-remove|abort-deconfigure)
+;;
+
+*)
+echo "postinst called with unknown argument \`$1'" >&2
+exit 1
+;;
+esac
+
+# dh_installdeb will replace this with shell code automatically
+# generated by other debhelper scripts.
+
+#DEBHELPER#
+
+exit 0
--
2.11.0
>From 38cb2ac4448044f40931ec97065c7a7f8b4fd54c Mon Sep 17 00:00:00 2001
From: Evgeni Golov
Date: Sun, 12 Mar 2017 08:39:33 +0100
Subject: [PATCH 2/4] migrate old installations to a properly disabled sysv
service too
---
debian/thinkfan.lintian-overrides | 4
debian/thinkfan.preinst | 43 +++
2 files changed, 47 insertions(+)
create mode 100644 debian/thinkfan.preinst
diff --git a/debian/thinkfan.lintian-overrides b/debian/thinkfan.lintian-overrides
index 62ce724..292b9cd 100644
--- a/debian/thinkfan.lintian-overrides
+++ b/debian/thinkfan.lintian-overrides
@@ -1,3 +1,7 @@
# pre-deployment of a disabled service as dh_installinit is
# not capable to do so for us.
thinkfan: duplicate-updaterc.d-calls-in-postinst thinkfan
+
+# only called for upgrades from older versions to migrate
+# enabled/disabled state
+thinkfan: preinst-calls-updaterc.d thinkfan
diff --git a/debian/thinkfan.preinst b/debian/thinkfan.preinst
new file mode 100644
index 000..da9ed04
--- /dev/null
+++ b/debian/thinkfan.preinst
@@ -0,0 +1,43 @@
+#!/bin/sh
+# preinst script for thinkfan
+#
+# see: dh_installdeb(1)
+
+set -e
+
+# summary of how this script can be called:
+#* `install'
+#* `install'
+#* `upgrade'
+#* `abort-upgrade'
+# for details, see https://www.debian.org/doc/debian-policy/ or
+# the debian-policy package
+
+
+case "$1" in
+install|upgrade)
+if [ -n "$2" ] && dpkg --compare-versions "$2" lt "0.9.3-2~" && [ -r /etc/default/thinkfan ]; then
+. /etc/default/thinkfan
+if [ "${START}" != "yes" ]; then
+ # Disable the service if it was disabled via /e/d/thinkfan
+ update-rc.d thinkfan defaults >/dev/null || true
+ update-rc.d thinkfan disable >/dev/null || true
+fi
+f
Bug#857089: Fix dh_installinit options
Hi, On Sat, Mar 11, 2017 at 08:58:23PM +0100, Wolfgang Schweer wrote: > On Sat, Mar 11, 2017 at 03:12:48PM +0100, Evgeni Golov wrote: > > But with the help of fsateler and the postinst of src:puppet, I think I now > > have a working solution. Just call update-rc.d disable on a fresh install. > > > > Can you please test the attached patch? > > Tested on an up-to-date stretch system. With systemd I guess? > Fresh install: ok (no errors during installation, disabled like > expected; works after providing a working config file and running > service thinkfan enable/start). > > Upgrade from version currently in stretch: > a) previously disabled: ok (no errors, still disabled). > b) previously enabled/running: ok (no errors, still running. > > Good job, congrats! Thanks! There is still one thing left: in the SysV case, the user will have to issue update-rc.d thinkfan enable AND edit /etc/default/thinkfan. Thinking how to fix that. Regards
Bug#857089: Fix dh_installinit options
Hi, On Sat, Mar 11, 2017 at 02:35:20PM +0100, Wolfgang Schweer wrote: > > To recap, the behaviour should be as follows (IMHO): > > on fresh install, the service is disabled and not started > > on upgrade > > * if the service was enabled, it remains enabled and gets restarted > > * if the service was disabled, it remains so and is not started > > Yeah; good summary. > If the half-broken --no-start option would be used (to fix the RC bug) > then maybe a NEWS.Debian file could be shipped to inform about the steps > to take in case of upgrades. Agreed. But with the help of fsateler and the postinst of src:puppet, I think I now have a working solution. Just call update-rc.d disable on a fresh install. Can you please test the attached patch? Regards Evgeni >From 87320b76e2d7c7e055eb6ae85828d22c90d02442 Mon Sep 17 00:00:00 2001 From: Evgeni Golov Date: Sat, 11 Mar 2017 14:58:59 +0100 Subject: [PATCH] call update-rc.d thinkfan disable on fresh installs Closes: #758579 --- debian/thinkfan.lintian-overrides | 3 +++ debian/thinkfan.postinst | 21 + 2 files changed, 24 insertions(+) create mode 100644 debian/thinkfan.lintian-overrides create mode 100644 debian/thinkfan.postinst diff --git a/debian/thinkfan.lintian-overrides b/debian/thinkfan.lintian-overrides new file mode 100644 index 000..62ce724 --- /dev/null +++ b/debian/thinkfan.lintian-overrides @@ -0,0 +1,3 @@ +# pre-deployment of a disabled service as dh_installinit is +# not capable to do so for us. +thinkfan: duplicate-updaterc.d-calls-in-postinst thinkfan diff --git a/debian/thinkfan.postinst b/debian/thinkfan.postinst new file mode 100644 index 000..7ea8f60 --- /dev/null +++ b/debian/thinkfan.postinst @@ -0,0 +1,21 @@ +#!/bin/sh +# postinst script for thinkfan +# +# see: dh_installdeb(1) + +set -e + +if [ "$1" = "configure" ]; then + if [ -x "/etc/init.d/thinkfan" ] && [ -z "$2" ]; then + # Disable the service by default on new installations + update-rc.d thinkfan defaults >/dev/null || true + update-rc.d thinkfan disable >/dev/null || true + fi +fi + +# dh_installdeb will replace this with shell code automatically +# generated by other debhelper scripts. + +#DEBHELPER# + +exit 0 -- 2.11.0
Bug#857089: Fix dh_installinit options
Hi Wolfgang, On Sat, Mar 11, 2017 at 01:57:47PM +0100, Wolfgang Schweer wrote: > Hi Evgeni, > > On Sat, Mar 11, 2017 at 12:34:18PM +0100, Evgeni Golov wrote: > > > override_dh_installinit: > > > - dh_installinit --onlyscripts > > > + dh_installinit --only-scripts --no-start > > > > Sadly, it is not that easy. --no-start implies that the daemon also won't be > > re-started on upgrades. And you really want that ;) > > Right; saw it too late. Maybe it would be an idea to generate d/postinst > manually to have more options (compared to dh_*) for the upgrade case? > I tried that, but w/o success so far. I'd rather use the half-broken --no-start or rip out sysv support than writing my own postinst (it just asks for doing something wrong :/). Anyways. I actually think that writing "our own" postinst would not work either. update-rc.d just does not give us enough support to do so. #705254 update-rc.d: Provide "is-enabled" command #857452 update-rc.d: please provide a defaults-disabled option To recap, the behaviour should be as follows (IMHO): on fresh install, the service is disabled and not started on upgrade * if the service was enabled, it remains enabled and gets restarted * if the service was disabled, it remains so and is not started For fresh install this is easy, just ommit the update-rc.d thinkfan defaults call in postinst and be done (invoke-rc.d should behave properly) For upgrades, we'd need something like: if update-rc.d thinkfan is-enabled; update-rc.d thinkfan defaults fi or update-rc.d thinkfan defaults-desabled Again, trusting that invoke-rc.d will behave properly afterwards. But we don't have these commands :(
Bug#857089: Fix dh_installinit options
Hi Wolfgang,
On Wed, Mar 08, 2017 at 11:45:45PM +0100, Wolfgang Schweer wrote:
> the attached patch seems to work for me.
> Please test.
Thanks for the patch!
> override_dh_installinit:
> - dh_installinit --onlyscripts
> + dh_installinit --only-scripts --no-start
Sadly, it is not that easy. --no-start implies that the daemon also won't be
re-started on upgrades. And you really want that ;)
And the typo is not really one. dh accepts both:
"o" => \$dh{ONLYSCRIPTS},
"onlyscripts" => \$dh{ONLYSCRIPTS},
"only-scripts" => \$dh{ONLYSCRIPTS},
(from /usr/share/perl5/Debian/Debhelper/Dh_Getopt.pm)
But given the hyphen-version is the one documented in the manpage,
we probably still should switch.
Regards
Evgeni
Bug#855208: [pkg-go] Bug#855208: runc: 1.0 release candidate breaks docker 1.11 - oci runtime error: flag provided but not defined: -bundle
Hi Tim, On Mon, Feb 20, 2017 at 11:38:29PM +, Potter, Tim wrote: > On 18 Feb 2017, at 5:33 AM, Evgeni Golov wrote: > > Can we in the meantime have proper Breaks in place, so that people don't > > accidentally update runc without docker/containerd/etc? > > Hi Evgeni. Thanks for the reply. I had totally missed the fact that people > could be > doing individual package upgrades of runc (also containerd) and this would > muck up > the docker.io package. > > What particular Break lines would you think appropriate for this situation? > My initial > guess would have been adding Depends = in docker.io, containerd and runc to > ensure that everything is upgraded in lockstep, but I don't see where Breaks > can > be applied. I would have suggested adding "Breaks: docker.io (<< 1.12)" to both runc and containerd, as upgrading both (separately and together) breaks Docker in sid atm. Not sure how you want to add a Depends with = here, as that would mean you need to maintain those entries on each and every upload of the packages, which does not seem practicable (and would not fix the current docker.io package in sid). Regards Evgeni
Bug#855208: [pkg-go] Bug#855208: runc: 1.0 release candidate breaks docker 1.11 - oci runtime error: flag provided but not defined: -bundle
Hi Tim, On Wed, Feb 15, 2017 at 10:52:22PM +, Potter, Tim wrote: > > I can reproduce this. Downgrading to 0.1.1+dfsg1-2 fixed this for me. > > Hi everyone. This upload is part of updated build dependencies for Docker > 1.13.0. > Currently the pipeline is stalled while a few things sit in the NEW queue. > When > that's all sorted out everything should build again. Can we in the meantime have proper Breaks in place, so that people don't accidentally update runc without docker/containerd/etc? Thanks Evgeni
Bug#837582: yabause: FTBFS with bindnow and PIE enabled
On Mon, Sep 12, 2016 at 04:43:31PM +0200, Balint Reczey wrote: > src/gtk/CMakeFiles/yabause-gtk.dir/build.make:713: recipe for target > 'src/gtk/yabause-gtk' failed > make[3]: *** [src/gtk/yabause-gtk] Error 1 > ... 08:36 < Zhenech> Guillaume, debian enabled PIE and bindnow for all builds 08:36 < Zhenech> and yabause fails now :( 08:36 < Zhenech> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837582 08:37 < Guillaume> ah yeah 08:37 < Guillaume> you need to disable the dynarec 08:37 < Guillaume> -DSH2_DYNAREC=OFF 08:37 < Zhenech> also happens with .15 (tried yesterday) 08:38 < Zhenech> what is dynarec? :) 08:38 < Guillaume> the dynamic recompiler version of SH2 08:38 < Guillaume> faster, but... 08:39 < Guillaume> not maintained 08:39 < Guillaume> and it's using a hardcoded pointer
Bug#819487: yabause: stack smashed
control: severity -1 important control: tags -1 + unreproducible moreinfo Hi, On Tue, Mar 29, 2016 at 07:44:28AM -0500, Richard Jasmin wrote: > current packaged version causes stack to be smashed, and there doesnt seem to > be a fix. > -was it compiled before stack smashing detection code? > > pulling upstream code results in '-fPIC' reccomendeation due to ip relocation > from 64 to 32 bits with dynamic compilation. There is no way to force static > build. > > If someone can figure out how to use auto tools, lemme know. as-is I cant seem > to trigger them. CMake is forced. > > This causes this app to be useless. You cant do anything with it once the BIOS > finishes booting. > > This is for sure a debian bug. Fedora has a working copy.I know because Ive > tested a Sonic 3D beta with it. Uhm, can you provide more info how you crash Yabause? A basic test with http://vieille.merde.free.fr/floupix.html worked fine here. Are you using the GTK or Qt frontend? Are you using a BIOS? Greets Evgeni
Bug#819676: ansible: CVE-2016-3096: Code execution vulnerability in ansible lxc_container
Ohai, On Fri, Apr 01, 2016 at 03:15:48PM +0200, Salvatore Bonaccorso wrote: > There are now a partial fix > > https://github.com/ansible/ansible-modules-extras/commit/da84e2e9b83be6ebebbfd3be6776f391622c02fe > > and more in pull request at > > https://github.com/ansible/ansible-modules-extras/pull/1941 Both have been pushed to all relevant stable branches of Ansible now. FWIW, if you are already shipping updates to lxc_container.py, you might consider also including https://github.com/ansible/ansible-modules-extras/commit/6bfd2846f853b9beaeb01da6206d8ffa4abe7a4c Greets Evgeni
Bug#804319: package split missing proper brekas/replaces
Source: pyflakes Version: 1.0.0-2 Severity: serious Ohai, during the upgrade to 1.0.0-2 in sid, I saw the following error: Unpacking python-pyflakes (1.0.0-2) ... dpkg: error processing archive /var/cache/apt/archives/python-pyflakes_1.0.0-2_all.deb (--unpack): trying to overwrite '/usr/lib/python2.7/dist-packages/pyflakes/test/test_other.py', which is also in package pyflakes 1.0.0-1 Selecting previously unselected package python3-pyflakes. Preparing to unpack .../python3-pyflakes_1.0.0-2_all.deb ... Unpacking python3-pyflakes (1.0.0-2) ... dpkg: error processing archive /var/cache/apt/archives/python3-pyflakes_1.0.0-2_all.deb (--unpack): trying to overwrite '/usr/lib/python3/dist-packages/pyflakes/test/test_other.py', which is also in package pyflakes 1.0.0-1 I think the new packages miss a proper Replaces: oldname (<< 2.0-1~) Breaks: oldname (<< 2.0-1~) or similar. regards Evgeni -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- no debconf information
Bug#801833: desmume: Desmume crashes when starting
Hi, On Wed, Oct 14, 2015 at 10:26:07PM -0300, Alejandro Carrazzoni wrote: > When I run desmume, it crashes right after starting, with the following error: > > (desmume:6776): Gdk-CRITICAL **: IA__gdk_cairo_create: assertion > 'GDK_IS_DRAWABLE (drawable)' failed > Violación de segmento Thanks for reporting this bug! I can reproduce it on my machine and am happy to tell you that it is fixed in the next upstream release I will be uploading shortly. Thanks again Evgeni -- Bruce Schneier can read and understand Perl programs.
Bug#791540: FTBFS: undefined reference to symbol 'SDL_UnlockSurface'
Hi, On Fri, Aug 14, 2015 at 01:46:06PM +0100, James Cowgill wrote: > This was intriguing me so I had a bit of a look at it :) Cool! > However, autoconf-archive also has a (different) implementation of > AX_CHECK_GLU which gets used instead if the package is installed. This > version has a bug in it which trashes the LIBS variable (#795479) where > -lSDL had already been specified. Indeed, installing autoconf-archive triggers the FTBFS for me. > -C_DEFUN([AX_CHECK_GLU], > +AC_DEFUN([AX_CHECK_GLU], Looks sane, I'd upload that to unstable if noone objects in the next days. Thanks a lot for your debugging! Evgeni -- Bruce Schneier can read and understand Perl programs.
Bug#791540: FTBFS: undefined reference to symbol 'SDL_UnlockSurface'
Hi, On Thu, Aug 13, 2015 at 09:05:41PM +0200, Fabian Greffrath wrote: > Am Donnerstag, den 13.08.2015, 20:05 +0200 schrieb Evgeni Golov: > > > > -lSDL_image -lSDL_mixer > > > Is there anything special in your setup that would trigger this? > > It seems to link against both SDL_image and SDL_mixer, but not against > SDL itself! Good catch! But both, my local build and the one on asachi contain -lSDL. All weird. Evgeni -- Bruce Schneier can read and understand Perl programs.
Bug#791540: FTBFS: undefined reference to symbol 'SDL_UnlockSurface'
control: tags -1 + unreproducible Hi tbm! On Sun, Jul 05, 2015 at 07:08:14PM -0400, Martin Michlmayr wrote: > gnujump fails to build in unstable: > > > sbuild (Debian sbuild) 0.64.1 (13 Oct 2013) on m400-c3n1.hlinux.usa.hp.com > ... > > /bin/bash ../libtool --tag=CC --mode=link gcc -I/usr/include/libdrm -g > > -DPREFIX=\"/usr\" -DDATA_PREFIX=\"/usr/share/games\" -Wl,--as-needed -o > > gnujump game.o game-input.o game-output.o game-logic.o game-tools.o > > game-timer.o main.o menu.o menu-system.o records.o SDL_2dgl.o > > SDL_rotozoom.o setup.o SFont.o sprite.o surface.o tools.o replay.o > > effects-trail.o effects-blur.o -lm -lGL -lGLU -lGL -lSDL_image > > -lSDL_mixer > > libtool: link: gcc -I/usr/include/libdrm -g -DPREFIX=\"/usr\" > > -DDATA_PREFIX=\"/usr/share/games\" -Wl,--as-needed -o gnujump game.o > > game-input.o game-output.o game-logic.o game-tools.o game-timer.o main.o > > menu.o menu-system.o records.o SDL_2dgl.o SDL_rotozoom.o setup.o SFont.o > > sprite.o surface.o tools.o replay.o effects-trail.o effects-blur.o -lm > > -lGLU -lGL -lSDL_image -lSDL_mixer > > /usr/bin/ld: SDL_rotozoom.o: undefined reference to symbol > > 'SDL_UnlockSurface' > > //usr/lib/aarch64-linux-gnu/libSDL-1.2.so.0: error adding symbols: DSO > > missing from command line > > collect2: error: ld returned 1 exit status > > make[4]: *** [gnujump] Error 1 I can't reproduce this neither on my amd64 laptop, nor on asachi.d.o (arm64 porterbox). Is there anything special in your setup that would trigger this? Regards Evgeni -- Bruce Schneier can read and understand Perl programs.
Bug#794361: FTBFS with GCC5
Package: sysdig Version: 0.1.101-2 Severity: serious Tags: upstream Justification: fails to build from source (but built successfully in the past) While prparing 0.1.102, I noticed that it will not build on current unstable. This also applies to 0.1.101-2 as in the archive. Build log: Linking CXX executable csysdig cd /tmp/buildd/sysdig-0.1.101/obj-x86_64-linux-gnu/userspace/sysdig && /usr/bin/cmake -E cmake_link_script CMakeFiles/csysdig.dir/link.txt --verbose=1 /usr/bin/c++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 -Wall -ggdb --std=c++0x -Wl,-z,relro CMakeFiles/csysdig.dir/fields_info.cpp.o CMakeFiles/csysdig.dir/csysdig.cpp.o -o csysdig -rdynamic ../libsinsp/libsinsp.a -lncurses -lform ../libscap/libscap.a -lz -ljsoncpp -lluajit-5.1 -ldl .../libsinsp/libsinsp.a(container.cpp.o): In function `sinsp_container_manager::parse_docker(sinsp_container_info*)': /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:339: undefined reference to `Json::Reader::parse(std::__cxx11::basic_string, std::allocator > const&, Json::Value&, bool)' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:346: undefined reference to `Json::Value::asString[abi:cxx11]() const' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:347: undefined reference to `Json::Value::asString[abi:cxx11]() const' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:353: undefined reference to `Json::Value::asString[abi:cxx11]() const' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:360: undefined reference to `Json::Value::getMemberNames[abi:cxx11]() const' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:371: undefined reference to `Json::Value::operator[](std::__cxx11::basic_string, std::allocator > const&)' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:378: undefined reference to `Json::Value::asString[abi:cxx11]() const' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/container.cpp:379: undefined reference to `Json::Value::asString[abi:cxx11]() const' .../libsinsp/libsinsp.a(event.cpp.o): In function `sinsp_evt::render_fd_json(Json::Value*, long, char const**, sinsp_evt::param_fmt)': /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/event.cpp:584: undefined reference to `Json::Value::Value(std::__cxx11::basic_string, std::allocator > const&)' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/event.cpp:595: undefined reference to `Json::Value::Value(std::__cxx11::basic_string, std::allocator > const&)' .../libsinsp/libsinsp.a(event.cpp.o): In function `sinsp_evt::get_param_as_json(unsigned int, char const**, sinsp_evt::param_fmt)': /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/event.cpp:890: undefined reference to `Json::Value::Value(std::__cxx11::basic_string, std::allocator > const&)' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/event.cpp:908: undefined reference to `Json::Value::Value(std::__cxx11::basic_string, std::allocator > const&)' /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/event.cpp:950: undefined reference to `Json::Value::Value(std::__cxx11::basic_string, std::allocator > const&)' .../libsinsp/libsinsp.a(event.cpp.o):/tmp/buildd/sysdig-0.1.101/userspace/libsinsp/event.cpp:964: more undefined references to `Json::Value::Value(std::__cxx11::basic_string, std::allocator > const&)' follow .../libsinsp/libsinsp.a(eventformatter.cpp.o): In function `sinsp_evt_formatter::tostring(sinsp_evt*, std::__cxx11::basic_string, std::allocator >*)': /tmp/buildd/sysdig-0.1.101/userspace/libsinsp/eventformatter.cpp:270: undefined reference to `Json::FastWriter::write[abi:cxx11](Json::Value const&)' collect2: error: ld returned 1 exit status userspace/sysdig/CMakeFiles/csysdig.dir/build.make:120: recipe for target 'userspace/sysdig/csysdig' failed make[3]: *** [userspace/sysdig/csysdig] Error 1 Regards Evgeni -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages sysdig depends on: ii libc62.19-19 ii libgcc1 1:5.1.1-14 ii libjsoncpp0 0.10.2-4 ii libluajit-5.1-2 2.0.3+dfsg-3 ii libncurses5 5.9+20150516-2 ii libstdc++6 5.1.1-14 ii libtinfo55.9+20150516-2 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages sysdig recommends: ii sysdig-dkms 0.1.101-2 sysdig suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788543: bareos-sd will silently corrupt backups when using multi-volume disk-based jobs
On Mon, Jul 20, 2015 at 07:42:25PM +0200, Felix Geyer wrote: > Hi, > > On 20.07.2015 19:03, Evgeni Golov wrote: > > Hi > > > > I actually have an almost ready 14.2.5 in git that would just fix > > everything. I'll try to get that done until the weekend. Does that sound ok > > for you? > > Sounds greats :) > Are you also going to take care of fixing bareos in jessie? After the fix has migrated to Stretch: yes. If you want to have it earlier (and discuss details with SRM): feeld free to do a team upload of your backported patch :) Greets Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788543: bareos-sd will silently corrupt backups when using multi-volume disk-based jobs
Hi
I actually have an almost ready 14.2.5 in git that would just fix everything.
I'll try to get that done until the weekend. Does that sound ok for you?
Greets
Evgeni
On July 20, 2015 6:32:40 PM GMT+02:00, Felix Geyer wrote:
>Hi,
>
>On 13.06.2015 01:32, Felix Geyer wrote:
>> Hi,
>>
>> On Fri, 12 Jun 2015 17:30:51 +0200 Michael Renner
>wrote:
>>> Package: bareos
>>> Version: 14.2.1+20141017gitc6c5b56-4
>>> Severity: critical
>>> Justification: causes serious data loss
>>>
>>> In March 2015 bareos fixed a bug which caused silent corruption of
>>> backups when the following conditions are met:
>>>
>>> * backups are written to disk (tape backups are not affected)
>>> * autolabelling is enabled
>>> * a backup spans over multiple volumes
>>> * the additional volumes are newly created and labeled during the
>backup.
>>>
>>> Bug: https://bugs.bareos.org/view.php?id=437
>>> Announcement:
>http://www.bareos.com/en/company_news/items/Bareos-14.2.4-published.html
>>> Fix for 14.2:
>https://github.com/bareos/bareos/commit/263240eaa911563a8468ecdaf7d4957201b41426
>>>
>>> Given that the above conditions are met in most bareos installations
>>> I've tagged this as critical.
>>>
>>>
>>> While I'm at it I'd like to point out that Joerg Steffens, an
>upstream maintainer,
>>> employee and/or partner of bareos.com and co-maintainer of this
>>> package in Debian, hasn't found the time to inform the Debian
>community of this issue, lest
>>> providing a patched package.
>>
>> Attached is a debdiff that contains a backport of the upstream fix.
>
>How about reverting the fix for #769536 ("circular dependency hell")
>until there is a proper
>solution for it?
>That way we can get this bug fixed and bareos back into testing.
>I've prepared those changes in the attached debdiff.
>
>What do you think?
>
>Cheers,
>Felix
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788945: libjsoncpp.so.0: cannot open shared object file: No such file or directory
Control: tags -1 + patch On Tue, Jun 16, 2015 at 10:34:35PM +0200, Evgeni Golov wrote: > Most probably causing commit is: > > https://anonscm.debian.org/cgit/collab-maint/libjsoncpp.git/commit/debian?id=21f33b218735398db17c50e09b46d7fefa39bec8 Either of these will fix the issue: diff -Nru libjsoncpp-0.10.2/debian/shlibs libjsoncpp-0.10.2/debian/shlibs --- libjsoncpp-0.10.2/debian/shlibs 2015-06-12 11:51:38.0 +0200 +++ libjsoncpp-0.10.2/debian/shlibs 1970-01-01 01:00:00.0 +0100 @@ -1 +0,0 @@ -libjsoncpp 0 diff -Nru libjsoncpp-0.10.2/debian/shlibs libjsoncpp-0.10.2/debian/shlibs --- libjsoncpp-0.10.2/debian/shlibs 2015-06-12 11:51:38.0 +0200 +++ libjsoncpp-0.10.2/debian/shlibs 2015-06-16 23:18:42.0 +0200 @@ -1 +1 @@ -libjsoncpp 0 +libjsoncpp 0 libjsoncpp0 I prefer the first version, as the shlibs file is not strictly needed (dh_makeshlibs will generate exactly that file) if you do not want to force any specific depends. See [1] for the file format. Please remember that all packages built against the broken version need a binNMU to get the new dependency right. Regards Evgeni [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-shlibs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#788945: libjsoncpp.so.0: cannot open shared object file: No such file or directory
Hi, reassigning to libjsoncpp, as it is generating it shlibs wrongly it seems. On Tue, Jun 16, 2015 at 03:17:57PM +0200, Michael Prokop wrote: > # sysdig > sysdig: error while loading shared libraries: libjsoncpp.so.0: cannot open shared object file: No such file or directory > > When installing libjsoncpp0 manually it works as intended. This is new since at least libjsoncpp 0.10.2-3. It worked fine with the version in jessie. Most probably causing commit is: https://anonscm.debian.org/cgit/collab-maint/libjsoncpp.git/commit/debian?id=21f33b218735398db17c50e09b46d7fefa39bec8 Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771870: [Pkg-bareos-devel] Bug#771870: bareos-database-common: fails to install: bareos-database-common.config: /usr/sbin/bareos-dbcheck: not found
Hi,
On 12/05/2014 08:27 PM, Julien Cristau wrote:
> On Fri, Dec 5, 2014 at 12:19:12 +0100, Evgeni Golov wrote:
>
>> Dear RT, do you think this is a RC bug in bareos and should be fixed by
>> reverting the previous fix (or restructuring the package, but that is
>> probably out of scope at this time of the freeze)? Or is this something
>> we could ignore for jessie (the package is not designed to be installed
>> by itself anyways)? Or should we move the can of worms over to
>> dbconfig-common?
>>
> You seem to assume we know what "the previous fix" refers to...
Yeah, sorry. The context would have existed in the unblock request, but
not here.
So there we are, the previous fix is for #769536,
https://github.com/evgeni/bareos/commit/adb0528f5e450bf1347afe776beb76af7e9bce21,
which for this bug here can be reduced to:
@@ -96,7 +96,7 @@
Package:bareos-database-common
Architecture: any
Pre-Depends:debconf (>= 1.4.30) | debconf-2.0
-Depends:bareos-database-postgresql (= ${binary:Version}) |
bareos-database-mysql (= ${binary:Version}) | bareos-database-sqlite3 (=
${binary:Version}), bareos-common (= ${binary:Version}),
dbconfig-common, lsb-base (>= 3.2-13), ${shlibs:Depends}, ${misc:Depends}
+Depends:bareos-common (= ${binary:Version}), dbconfig-common,
lsb-base (>= 3.2-13), ${shlibs:Depends}, ${misc:Depends}
Description: Backup Archiving Recovery Open Sourced - common catalog files
Bareos is a set of programs to manage backup, recovery and verification of
data across a network of computers of different kinds.
Greets
Evgeni
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771870: [Pkg-bareos-devel] Bug#771870: bareos-database-common: fails to install: bareos-database-common.config: /usr/sbin/bareos-dbcheck: not found
[ CCing -release@ whether this should be treated as a bug in bareos-database-common or dbconfig-common or not-at-all ] On 12/05/2014 09:58 AM, Evgeni Golov wrote: > The funny part is: there is no database at all, so dbconfig-common > should have just silently died in a corner. Chasing this now. Yeah, should... dbconfig-common ships with an example: db-test-multidbtype-2.0, which behaves fine if no databases are installed and install is called with DEBIAN_FRONTEND=noninteractive: root@nana:~# DEBIAN_FRONTEND=noninteractive dpkg -i /tmp/db-test-multidbtype_2.0_all.deb Selecting previously unselected package db-test-multidbtype. (Reading database ... 254799 files and directories currently installed.) Preparing to unpack .../db-test-multidbtype_2.0_all.deb ... Unpacking db-test-multidbtype (2.0) ... Setting up db-test-multidbtype (2.0) ... dbconfig-common: writing config to /etc/dbconfig-common/db-test-multidbtype.conf Creating config file /etc/dbconfig-common/db-test-multidbtype.conf with new version warning: database package not installed? sanity check failed for createuser. error encountered creating user: No pgsql createuser to execute. (have you installed postgresql-client? dbconfig-common: db-test-multidbtype configure: noninteractive fail. dbconfig-common: db-test-multidbtype configure: ignoring errors from here forwards populating database via sql... done. dbconfig-common: flushing administrative password However, if I modify its config file like this: --- a/debian/config +++ b/debian/config @@ -6,7 +6,10 @@ set -e . /usr/share/debconf/confmodule if [ -f /usr/share/dbconfig-common/dpkg/config ]; then - dbc_dbtypes="mysql, pgsql" + dbc_dbtypes="" + # let's assume we try to populate dbc_dbtypes dynamically here + # e.g. by looking for files from recommended packages or something + # but we come empty in the end dbc_authmethod_user="password" . /usr/share/dbconfig-common/dpkg/config dbc_go db-test-multidbtype $@ It will fail the very same way bareos-database-common fails: root@nana:~# DEBIAN_FRONTEND=noninteractive dpkg -i /tmp/db-test-multidbtype_2.1_all.deb Selecting previously unselected package db-test-multidbtype. (Reading database ... 254799 files and directories currently installed.) Preparing to unpack .../db-test-multidbtype_2.1_all.deb ... Unpacking db-test-multidbtype (2.1) ... Setting up db-test-multidbtype (2.1) ... dpkg: error processing package db-test-multidbtype (--install): subprocess installed post-installation script returned error exit status 10 Errors were encountered while processing: db-test-multidbtype I can't find a real answer in the dbconfig-common documentation, but the variables overview says: "database types supported by the package, in order of maintainers' preference (defaults to: empty)" So I would think having an empty dbc_dbtypes sometimes is valid. Not sure how to continue from here, the real fix seems to be reverting the "dependency loop" fix, which is not my favorite right now. Let's ask the RT: Dear RT, do you think this is a RC bug in bareos and should be fixed by reverting the previous fix (or restructuring the package, but that is probably out of scope at this time of the freeze)? Or is this something we could ignore for jessie (the package is not designed to be installed by itself anyways)? Or should we move the can of worms over to dbconfig-common? Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771870: [Pkg-bareos-devel] Bug#771870: bareos-database-common: fails to install: bareos-database-common.config: /usr/sbin/bareos-dbcheck: not found
On 12/05/2014 09:36 AM, Evgeni Golov wrote: > Hi Joerg, > > On 12/04/2014 03:10 PM, Jörg Steffens wrote: >> while the missing dependency is certainly a problem, I don't think the >> missing bareos-dbcheck causes the problem here. >> >> I guess it is related to another problem. This have been fixed in master >> and today also published to bareos-14.2 and bareos-14.2-debian: >> >> https://github.com/bareos/bareos/commit/2abb036aced9eba36a4b7e3aa942028caa77156e > > This sadly does not fix the problem. > The install still will fail with DEBIAN_FRONTEND=noninteractive, > probably because it tries to configure the database with > dbconfig-common, but there is no database available. dbc_get_admin_pass() . + printf dbc_get_admin_pass() .\n + db_fget bareos-database-common//admin-pass seen + _db_cmd FGET bareos-database-common//admin-pass seen + _db_internal_IFS= + IFS= + printf %s\n FGET bareos-database-common//admin-pass seen + IFS= + IFS= read -r _db_internal_line + RET=10 bareos-database-common//admin-pass doesn't exist + return 10 dpkg: error processing package bareos-database-common (--configure): The funny part is: there is no database at all, so dbconfig-common should have just silently died in a corner. Chasing this now. Greets Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771870: [Pkg-bareos-devel] Bug#771870: bareos-database-common: fails to install: bareos-database-common.config: /usr/sbin/bareos-dbcheck: not found
Hi Joerg, On 12/04/2014 03:10 PM, Jörg Steffens wrote: > while the missing dependency is certainly a problem, I don't think the > missing bareos-dbcheck causes the problem here. > > I guess it is related to another problem. This have been fixed in master > and today also published to bareos-14.2 and bareos-14.2-debian: > > https://github.com/bareos/bareos/commit/2abb036aced9eba36a4b7e3aa942028caa77156e This sadly does not fix the problem. The install still will fail with DEBIAN_FRONTEND=noninteractive, probably because it tries to configure the database with dbconfig-common, but there is no database available. Greets Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#771870: [Pkg-bareos-devel] Bug#771870: bareos-database-common: fails to install: bareos-database-common.config: /usr/sbin/bareos-dbcheck: not found
Hi,
On 12/03/2014 04:10 AM, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
Thanks. This is what you get when you try to solve dependency loops :/
>>From the attached log (scroll to the bottom...):
>
> Selecting previously unselected package bareos-database-common.
> (Reading database ... 9220 files and directories currently installed.)
> Preparing to unpack
> .../bareos-database-common_14.2.1+20141017gitc6c5b56-4_amd64.deb ...
> Unpacking bareos-database-common (14.2.1+20141017gitc6c5b56-4) ...
> Setting up bareos-database-common (14.2.1+20141017gitc6c5b56-4) ...
> /var/lib/dpkg/info/bareos-database-common.config: 1:
> /var/lib/dpkg/info/bareos-database-common.config: /usr/sbin/bareos-dbcheck:
> not found
> Warning: failed to get "dbname" from config, using default value "bareos",
> see /tmp/bareos-config.11958.log
> /var/lib/dpkg/info/bareos-database-common.config: 1:
> /var/lib/dpkg/info/bareos-database-common.config: /usr/sbin/bareos-dbcheck:
> not found
> Warning: failed to get "dbuser" from config, using default value "bareos",
> see /tmp/bareos-config.11958.log
> (config) dbc_go() bareos-database-common configure.
bareos-database-common is not designed to be installed alone, yet it
triggers the above bug in that situation.
We could add a layer of "[ -x /usr/sbin/bareos-dbcheck ]" around the
calls to it (it's in bareos-database-tools).
Or we re-add bareos-database-tools to bareos-database-common depends,
but remove bareos-database-{postgresql,mysql,sqlite} from -tools depends
(which is also wrong, as dbcheck won't work then in all cases).
Joerg, any ideas? I'd go for the silly -x one.
Greets
Evgeni
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767819: bareos-*: modifies conffiles (policy 10.7.3): /etc/bareos/bareos-*.conf
On 11/04/2014 12:43 AM, Jörg Steffens wrote: >> How about that? >> https://github.com/credativ/bareos/commit/a3817bfc181cbe9352e2b9c7f52e125f598bcbae > > looks very good. > From my point of view, this fixes the problem. Thanks for the review! I have added a few postrm scripts to remove the configs when the package is purged: https://github.com/credativ/bareos/commit/2a76988eced8a56972801787f3dd77ee6410c7b2 I would upload in my lunch-break if you do not object ;) Greets Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767819: [Pkg-bareos-devel] Bug#767819: Bug#767819: bareos-*: modifies conffiles (policy 10.7.3): /etc/bareos/bareos-*.conf
Hi, On Mon, Nov 03, 2014 at 12:16:24PM +0100, Evgeni Golov wrote: > I have a half-working patch on my disk for that. You might want to try > that as a base, I'll push it to git soon and let you know. How about that? https://github.com/credativ/bareos/commit/a3817bfc181cbe9352e2b9c7f52e125f598bcbae Greets Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767819: [Pkg-bareos-devel] Bug#767819: bareos-*: modifies conffiles (policy 10.7.3): /etc/bareos/bareos-*.conf
Hi Joerg, On 11/03/2014 11:33 AM, Jörg Steffens wrote: > thank you for this detailed information. > Bareos only substitutes template variables on initial installation (or > the database backend if somebody reconfigures dbconfig-common). > > I'll change the behavior, so that the template configuration files get > installed to /usr/share/bareos... and copied to /etc/bareos/ during > postinst, if the config file do not already exist. > > This will take a while, because the current behavior must continue to > work for other plattforms (eg. RPM based). I have a half-working patch on my disk for that. You might want to try that as a base, I'll push it to git soon and let you know. Greets Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#767584: segfaults when a dot is used in the config as part of the hostname
Package: apt-dater
Version: 1.0.1-1
Severity: grave
Hi,
after the upgrade to 1.0.0 I first what surprised by a new configuration, w/o
an import of my old one, thanks :/
After rewriting the config, apt-dater segfaults on me.
Minimal config to reproduce the issue (based on your example):
Hosts:
{
localnet:
{
Title="local hosts";
localhost: {}
node1.ibh.net: {}
}
}
GDB backtrace:
evgeni@nana ~ % gdb apt-dater
GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Bug#764327: thinfan: Startup Fails On PostInstall
control: severity -1 normal Hi Stephen, On 10/07/2014 11:41 AM, Stephen Allen wrote: >>From the applicaiton log: > > # journalctl -xn > -- Logs begin at Mon 2014-10-06 22:36:18 EDT, end at Tue 2014-10-07 05:35:40 > EDT. -- > Oct 07 05:35:40 Jessie systemd[1]: Starting simple and lightweight fan > control program... > -- Subject: Unit thinkfan.service has begun with start-up > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel ... As written by Alex, you need fan_control=1 for thinkfan to work. postinst does not start thinkfan after a fresh install because of that, you seem to have enabled the service youself before configuring your environment properly. Please reconfigure and retry. I have downgraded this bug to normal, as the most I can see here is a possible improvement of documentation what has to be done for a working thinkfan setup. Input highly welcome! Greets Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764129: thinkfan sends strange char sequence to tp_fan after service restart"
control: severity -1 important
On Sun, Oct 12, 2014 at 06:58:21PM +0200, Marco wrote:
> Thanks for the reply I was giving up hope :)
>
> > My guess would be that thinkfan gets corrupted data from 'somewhere',
> > and then some lack of bounds or type checking messes up other internal
> > variables and leads to corrupt data being written out.
So would be mine. Could you try with the generic (non-IBM) interface as
described in the thinkfan.conf.complex? As this uses a different parser,
it should "just" work. Yet we should fix the issue you are facing (but I
downgraded the bug to "only" important, as it does not happen to every
user and I'd love to keep thinkfan in Jessie)
> To be more 'scientific' I tried first to make thinkfan print cur_lvl
> value when workign, so I patched system.c code like this:
>
> diff --git a/system.c b/system.c
> index 43d7515..86eb492 100644
> --- a/system.c
> +++ b/system.c
> @@ -127,6 +127,7 @@ void setfan_ibm() {
> errcnt |= ERR_FAN_SET;
> }
> else {
> + report(LOG_INFO, LOG_INFO, "cur_lvl = %s\n", cur_lvl);
> if (unlikely(write(ibm_fan, cur_lvl, l) < l)) {
> prefix = "\n";
> report(LOG_ERR, LOG_ERR, MSG_ERR_FANCTRL);
>
> And the result is (as expected), something like this:
>
> sleeptime=5, tmax=96, last_tmax=96, biased_tmax=96 -> fan="level 3"
> cur_lvl = level 3
> cur_lvl = level 3
> cur_lvl = level 3
> sleeptime=5, tmax=71, last_tmax=104, biased_tmax=71 -> fan="level 7"
> cur_lvl = level 7
> cur_lvl = level 7
> cur_lvl = level 7
> sleeptime=2, tmax=104, last_tmax=70, biased_tmax=155 -> fan="level 3"
> cur_lvl = level 3
>
> While when thinkfan is 'broken' the output is something like this:
>
> cur_lvl = ??
>
> Cleaning up and resetting fan control.
>
> cur_lvl = ?D
>
> Cleaning up and resetting fan control.
>
> cur_lvl = ?d
>
> Cleaning up and resetting fan control.
>
> cur_lvl = ??
>
> Cleaning up and resetting fan control.
>
> cur_lvl = ?T
>
> Cleaning up and resetting fan control.
>
> These are all from different runs since thinkfan crashes each time
> (strange charachters may look different on may terminal, but I think the
> point is that cur_lvl points to sequence of bytes all messed up).
Yeah, looks like a weird read, for some reason.
> > Can you try to monitor /proc/acpi/ibm/thermal with
> > a script or so and see if anything weird is going on?
Could you also monitor "/proc/acpi/ibm/fan", as this containts the
fan-settings?
> I'm diving now a little more into thinkfan source code (slowly, because it
> is a long time I don't read C). I will see if I can spot the source of
> those strange chars.
Thanks!
Evgeni
--
Bruce Schneier can read and understand Perl programs.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763050: [Pkg-geany-team] Bug#763050: geany: Does not start, "Attempt to unlock mutex that was not locked" instead
Hi, On Mon, Oct 13, 2014 at 01:30:26PM +0400, Vlad Orlov wrote: > I suggest making a debdiff from this patch so the maintainers would be > able to include it in the package. It will be faster than waiting for the > upstream to release a new version. If you need some info about making > a debdiff, check this article: Thanks for the suggestion, but we (maintainers) are on it, just waiting for upstream to ACK the patch. Greets Evgeni, on behalf of pkg-geany -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#764129: thinkfan sends strange char sequence to tp_fan after service restart"
Hi Marco,
On 10/05/2014 06:46 PM, Marco wrote:
> When I restart thinkfan or reboot the whole machine, thinkfan dies with the
> following message:
>
> setfan_ibm: Error writing to /proc/acpi/ibm/fan: Invalid argument
> Cleaning up and resetting fan control.
Never seen this before.
> I tryed to recompile thinkfan with some more log messages in setfan_ibm() and
> I noticed that the string it tries to write to /proc/acpi/ibm/fan is
> unreadeable, while (if I got it right) should be something like "level 3".
Anything static? Or random?
> I have
> options thinkpad_acpi fanc_control=1
I hope it actually reads "fan_control" ;)
> and the demon starts and works correctly after a clean boot.
So it only fails after a reboot or a thinkfan restart?
> /etc/thinkfan.conf changed:
> tp_fan /proc/acpi/ibm/fan
> tp_thermal /proc/acpi/ibm/thermal
> { "level 0"
> (0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0) # LOWER limit
> (54 . 54 . . . . . . . . . . . . .) # UPPER limit
> }
> { "level 1"
> (46 . 46 . . . . . . . . . . . . .)
> (58 . 58 . . . . . . . . . . . . .)
> }
> { "level 2"
> (52 . 52 . . . . . . . . . . . . .)
> (62 . 62 . . . . . . . . . . . . .)
> }
> { "level 3"
> (56 . 56 . . . . . . . . . . . . .)
> (66 . 66 . . . . . . . . . . . . .)
> }
> { "level 7"
> (63 . 63 . . . . . . . . . . . . .)
> (99 . 99 . . . . . . . . . . . . .)
> }
Could you try running thinkfan with the default config? Without the
level adjustments?
Greets
Evgeni
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758579: thinkfan: Post Installation, Start Script fails to Initialize
control: severity -1 important control: tags -1 + unreproducible On Wed, Aug 20, 2014 at 06:10:08PM +0200, Evgeni Golov wrote: > After reading a bug report one expects to understand what the problem is > - maybe content related? :) > > No, seriously, what is your system, what happens if you try to start > thinkfan? Do you have any logs? Had you time to get us some debug info? thinkfan works fine here (on a systemd system, though). And it worked just fine before I installed systemd, so I do not think there is a general problem here, thus downgrading the severity. Greets Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758579: thinkfan: Post Installation, Start Script fails to Initialize
control: tags -1 + moreinfo Dear submitter, On Mon, Aug 18, 2014 at 06:09:11PM -0400, Stephen Allen wrote: > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > After installation one expects the start script to function - maybe systemd > related? After reading a bug report one expects to understand what the problem is - maybe content related? :) No, seriously, what is your system, what happens if you try to start thinkfan? Do you have any logs? Greets Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#755362: sysdig: FTBFS on kfreebsd-*: scap.c:1015: undefined reference to `scap_readbuf'
control: forwarded -1 https://github.com/draios/sysdig/pull/212 control: tags -1 + fixed-upstream patch Mraw! On Sat, Jul 19, 2014 at 11:27:37PM +0200, Cyril Brulebois wrote: > your package no longer builds on kfreebsd-*: Yepp, I fixed that upstream [1], but was not motivated enough to reupload just because of this. Upstream is usually quick with new releases, so maybe they will just release a fixed version. :) Greets Evgeni [1] https://github.com/draios/sysdig/commit/257b75ffdf99137dde5a73ae7f57a419ff5996a7 -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744229: qpdfview FTBFS synctex/synctex_parser.c:275:20: fatal error: zlib.h: No such file or directory
On Mon, Apr 28, 2014 at 09:37:06PM +0200, Benjamin Eltzner wrote: > as the my regular sponsor for the qpdfview package currently does not > have much time, would you still be willing to check my package and > upload it to unstable? It would be much appreciated. Sure, uploaded! Greets Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745599: src:libkolabxml: FTBFS with undefined reference to symbol '_ZTVN5boost6detail16thread_data_baseE'
On Sun, Apr 27, 2014 at 05:20:34PM +0200, Ondřej Surý wrote: > Cool, so it's simple Build-Conflicts: then I guess... Yeah, or an actual fix ot the tests ;) See the uploaded nmu diff. Greets -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745599: libkolabxml: diff for NMU version 0.8.4-5.1
control: tags 746160 + patch pending
control: tags 745599 + patch pending
Dear maintainer,
I've prepared an NMU for libkolabxml (versioned as 0.8.4-5.1) and
uploaded it to DELAYED/10.
Regards.
diff -Nru libkolabxml-0.8.4/debian/changelog libkolabxml-0.8.4/debian/changelog
--- libkolabxml-0.8.4/debian/changelog 2013-07-11 20:56:39.0 +0200
+++ libkolabxml-0.8.4/debian/changelog 2014-04-27 16:17:16.0 +0200
@@ -1,3 +1,13 @@
+libkolabxml (0.8.4-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix linking of tests when they are built.
+Closes: #745599
+ * Explicitely use Python 2, even when Python 3 is installed.
+Closes: #746160
+
+ -- Evgeni Golov Sun, 27 Apr 2014 15:54:06 +0200
+
libkolabxml (0.8.4-5) unstable; urgency=low
* Fix parallel build issue
diff -Nru libkolabxml-0.8.4/debian/patches/fix-test-link-error.patch libkolabxml-0.8.4/debian/patches/fix-test-link-error.patch
--- libkolabxml-0.8.4/debian/patches/fix-test-link-error.patch 1970-01-01 01:00:00.0 +0100
+++ libkolabxml-0.8.4/debian/patches/fix-test-link-error.patch 2014-04-27 15:53:56.0 +0200
@@ -0,0 +1,13 @@
+Index: libkolabxml-0.8.4/tests/CMakeLists.txt
+===
+--- libkolabxml-0.8.4.orig/tests/CMakeLists.txt 2013-04-11 11:35:34.0 +0200
libkolabxml-0.8.4/tests/CMakeLists.txt 2014-04-27 15:53:53.449105536 +0200
+@@ -18,7 +18,7 @@
+
+ QT4_AUTOMOC(conversiontest.cpp)
+ add_executable(conversiontest conversiontest.cpp ${CMAKE_CURRENT_BINARY_DIR}/${CONVERSIONTEST_MOC})
+-target_link_libraries(conversiontest ${QT_QTTEST_LIBRARY} ${QT_QTCORE_LIBRARY} kolabxml ${XERCES_C})
++target_link_libraries(conversiontest ${QT_QTTEST_LIBRARY} ${QT_QTCORE_LIBRARY} kolabxml ${XERCES_C} ${Boost_LIBRARIES})
+ add_test(conversiontest ${CMAKE_CURRENT_BINARY_DIR}/conversiontest)
+
+ QT4_AUTOMOC(parsingtest.cpp)
diff -Nru libkolabxml-0.8.4/debian/patches/series libkolabxml-0.8.4/debian/patches/series
--- libkolabxml-0.8.4/debian/patches/series 2013-07-11 20:56:39.0 +0200
+++ libkolabxml-0.8.4/debian/patches/series 2014-04-27 16:11:48.0 +0200
@@ -3,3 +3,5 @@
xcardconversions-spelling-error.patch
fix-race-condition.patch
fix-parallel-build.patch
+fix-test-link-error.patch
+use-python2-only.patch
diff -Nru libkolabxml-0.8.4/debian/patches/use-python2-only.patch libkolabxml-0.8.4/debian/patches/use-python2-only.patch
--- libkolabxml-0.8.4/debian/patches/use-python2-only.patch 1970-01-01 01:00:00.0 +0100
+++ libkolabxml-0.8.4/debian/patches/use-python2-only.patch 2014-04-27 16:14:57.0 +0200
@@ -0,0 +1,12 @@
+Index: libkolabxml-0.8.4/src/python/CMakeLists.txt
+===
+--- libkolabxml-0.8.4.orig/src/python/CMakeLists.txt 2013-04-11 11:35:34.0 +0200
libkolabxml-0.8.4/src/python/CMakeLists.txt 2014-04-27 16:14:55.440665955 +0200
+@@ -3,6 +3,7 @@
+
+ # Compile Python Bindings
+
++set(PythonLibs_FIND_VERSION 2.7)
+ find_package(PythonLibs REQUIRED)
+
+ if (NOT PYTHONLIBS_FOUND)
Bug#746160: FTBFS when both python2 and python3 development headers are installed
Source: libkolabxml Version: 0.8.4-5 Severity: serious Hi, libkolabxml will FTBFS when python3-dev is installed: dh_install --fail-missing make[1]: Leaving directory `/tmp/buildd/libkolabxml-0.8.4' dh_installdocs -O--parallel dh_installchangelogs -O--parallel dh_python2 -O--parallel E: dh_python2:433: extension linked to libpython3.3 and shipped in python2.7's dist-packages: _kolabformat.so make: *** [binary] Error 7 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Most probably the same issue as #745598 Regards Evgeni -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745599: src:libkolabxml: FTBFS with undefined reference to symbol '_ZTVN5boost6detail16thread_data_baseE'
On 04/27/2014 03:08 PM, Ondřej Surý wrote: > I can reproduce the build failure with following packages installed > (installed-packages.txt). > > I have also attached full build log from my cowbuilder. Ok, I found the problem. You have libqt4-dev installed, this triggers the build of the tests (they are not build otherwise) and this fails. Looking into the actual problem now I can cleanly reproduce the issue. Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745599: src:libkolabxml: FTBFS with undefined reference to symbol '_ZTVN5boost6detail16thread_data_baseE'
control: tags -1 + moreinfo unreproducible Hi, On Wed, Apr 23, 2014 at 09:32:19AM +0200, Ondřej Surý wrote: > while doing the package recompilation with PHP 5.6 your package failed > to build: > > Linking CXX executable conversiontest > cd /tmp/buildd/libkolabxml/libkolabxml-0.8.4/obj-x86_64-linux-gnu/tests && > /usr/bin/cmake -E cmake_link_script CMakeFiles/conversiontest.dir/link.txt > --verbose=1 > /usr/bin/c++ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -D_FORTIFY_SOURCE=2 -Wall -fpermissive > -Wl,--no-undefined -Wl,-z,relro "-Wl,--as-needed" > CMakeFiles/conversiontest.dir/conversiontest.cpp.o -o conversiontest > -rdynamic -lQtTest -lQtCore ../src/libkolabxml.so.0.8.4 -lxerces-c > -Wl,-rpath,/tmp/buildd/libkolabxml/libkolabxml-0.8.4/obj-x86_64-linux-gnu/src > /usr/bin/ld.bfd.real: CMakeFiles/conversiontest.dir/conversiontest.cpp.o: > undefined reference to symbol '_ZTVN5boost6detail16thread_data_baseE' > //usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0: error adding symbols: > DSO missing from command line > collect2: error: ld returned 1 exit status > make[3]: *** [tests/conversiontest] Error 1 > make[3]: Leaving directory > `/tmp/buildd/libkolabxml/libkolabxml-0.8.4/obj-x86_64-linux-gnu' > make[2]: *** [tests/CMakeFiles/conversiontest.dir/all] Error 2 > make[2]: Leaving directory > `/tmp/buildd/libkolabxml/libkolabxml-0.8.4/obj-x86_64-linux-gnu' > make[1]: *** [all] Error 2 > make[1]: Leaving directory > `/tmp/buildd/libkolabxml/libkolabxml-0.8.4/obj-x86_64-linux-gnu' > dh_auto_build: make -j1 returned exit code 2 > make: *** [build] Error 2 > dpkg-buildpackage: error: debian/rules build gave error exit status 2 This builds fine for me, both in a clean sid cowbuilder, and when pulling in PHP 5.6 from Experimental. Did you do anything more to produce this? Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744917: luajit: diff for NMU version 2.0.3+dfsg-2.1
On 04/25/2014 09:42 PM, Evgeni Golov wrote: > As the Makefile defines "LDCONFIG=ldconfig", and not > "LDCONFIG?=ldconfig", I can not :/ > > We could add the PATH in debian/rules instead. Shall we cancel the NMU for this fix? Greets -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745598: libkolab: diff for NMU version 0.4.2-7.1
tags 745598 + patch tags 745598 + pending thanks Dear maintainer, The problem is that cmake finds Python 3 and prefers that over Python 2 when building the extension. Build-Conflicting python3-dev would be a solution. Or we could tell cmake to use Python 2.7, which I prefer, as Build-Conflics are ugly ;) I've prepared an NMU for libkolab (versioned as 0.4.2-7.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should cancel it, if you want the conflicts fix instead. Regards. diff -Nru libkolab-0.4.2/debian/changelog libkolab-0.4.2/debian/changelog --- libkolab-0.4.2/debian/changelog 2013-08-28 20:21:32.0 +0200 +++ libkolab-0.4.2/debian/changelog 2014-04-27 13:16:32.0 +0200 @@ -1,3 +1,11 @@ +libkolab (0.4.2-7.1) unstable; urgency=medium + + * Non-maintainer upload. + * Build explicitely against Python 2.7, even if 3.x is installed. +Closes: #745598 + + -- Evgeni Golov Sun, 27 Apr 2014 13:15:28 +0200 + libkolab (0.4.2-7) unstable; urgency=low * Fix saving of pictures to kabc resources (Closes: #721099) diff -Nru libkolab-0.4.2/debian/patches/series libkolab-0.4.2/debian/patches/series --- libkolab-0.4.2/debian/patches/series 2013-08-28 20:21:32.0 +0200 +++ libkolab-0.4.2/debian/patches/series 2014-04-27 13:13:14.0 +0200 @@ -3,3 +3,4 @@ simpler_cmake_test.patch libkolab-0.3.1-php-paths.patch add-linker-flags.patch +use-python2-only.patch diff -Nru libkolab-0.4.2/debian/patches/use-python2-only.patch libkolab-0.4.2/debian/patches/use-python2-only.patch --- libkolab-0.4.2/debian/patches/use-python2-only.patch 1970-01-01 01:00:00.0 +0100 +++ libkolab-0.4.2/debian/patches/use-python2-only.patch 2014-04-27 13:24:36.0 +0200 @@ -0,0 +1,12 @@ +Index: libkolab-0.4.2/CMakeLists.txt +=== +--- libkolab-0.4.2.orig/CMakeLists.txt 2014-04-27 12:29:12.0 +0200 libkolab-0.4.2/CMakeLists.txt 2014-04-27 13:24:32.599020139 +0200 +@@ -62,6 +62,7 @@ + find_package(KdepimLibs 4.8 REQUIRED) + endif() + ++set(PythonLibs_FIND_VERSION 2.7) + find_package(SWIG) + + #Show summary of found libraries
Bug#742515: blktap-dkms: diff for NMU version 2.0.93-0.2
tags 742515 + patch tags 742515 + pending thanks Dear maintainer, I've prepared an NMU for blktap-dkms (versioned as 2.0.93-0.2) and uploaded it directly to the archive as discussed on IRC. Regards. diff -Nru blktap-dkms-2.0.93/debian/changelog blktap-dkms-2.0.93/debian/changelog --- blktap-dkms-2.0.93/debian/changelog 2013-11-18 15:37:48.0 +0100 +++ blktap-dkms-2.0.93/debian/changelog 2014-04-27 12:13:50.0 +0200 @@ -1,3 +1,11 @@ +blktap-dkms (2.0.93-0.2) unstable; urgency=medium + + * Non-maintainer upload. + * Add patch from upstream to support Linux kernels >= 3.7. +Closes: #742515 + + -- Evgeni Golov Sun, 27 Apr 2014 12:10:36 +0200 + blktap-dkms (2.0.93-0.1) unstable; urgency=high * Non-maintainer upload. diff -Nru blktap-dkms-2.0.93/debian/patches/fix-vm-reserved.patch blktap-dkms-2.0.93/debian/patches/fix-vm-reserved.patch --- blktap-dkms-2.0.93/debian/patches/fix-vm-reserved.patch 1970-01-01 01:00:00.0 +0100 +++ blktap-dkms-2.0.93/debian/patches/fix-vm-reserved.patch 2014-04-27 12:10:30.0 +0200 @@ -0,0 +1,43 @@ +From: Vincent Bernardoff +Date: Tue, 26 Feb 2013 16:03:35 + +Origin: upstream, https://github.com/xen-org/blktap-dkms/commit/3bd35d662de12139b7ed5b6dc1076a231a651d10 +Bug-Debian: https://bugs.debian.org/742515 +Subject: [PATCH] Changed flag VM_RESERVED to VM_DONTDUMP to provide + compatibility with Linux 3.7 onwards. + +Index: blktap-dkms-2.0.93/ring.c +=== +--- blktap-dkms-2.0.93.orig/ring.c 2014-04-27 12:10:05.858102759 +0200 blktap-dkms-2.0.93/ring.c 2014-04-27 12:10:05.854102721 +0200 +@@ -28,6 +28,13 @@ + #include + #include + ++/* VM_RESERVED has disappeared starting from Linux 3.7 and has been ++ * replaced by VM_DONTDUMP since then. ++ */ ++#ifndef VM_DONTDUMP ++#define VM_DONTDUMP VM_RESERVED ++#endif ++ + #include "blktap.h" + + int blktap_ring_major; +@@ -436,7 +443,7 @@ + } + + vma->vm_flags |= VM_DONTCOPY; +- vma->vm_flags |= VM_RESERVED; ++ vma->vm_flags |= VM_DONTDUMP; + + return 0; + } +@@ -472,7 +479,7 @@ + vma->vm_private_data = tap; + + vma->vm_flags |= VM_DONTCOPY; +- vma->vm_flags |= VM_RESERVED; ++ vma->vm_flags |= VM_DONTDUMP; + + vma->vm_ops = &blktap_ring_vm_operations; + diff -Nru blktap-dkms-2.0.93/debian/patches/series blktap-dkms-2.0.93/debian/patches/series --- blktap-dkms-2.0.93/debian/patches/series 2013-11-18 15:27:56.0 +0100 +++ blktap-dkms-2.0.93/debian/patches/series 2014-04-27 12:07:43.0 +0200 @@ -1 +1,2 @@ fixes-DEST_MODULE_LOCATION-in-dkms.conf.patch +fix-vm-reserved.patch
Bug#744229: qpdfview FTBFS synctex/synctex_parser.c:275:20: fatal error: zlib.h: No such file or directory
On 04/25/2014 09:44 PM, Benjamin Eltzner wrote: > I uploaded a tentative new package to mentors: > http://mentors.debian.net/package/qpdfview > would you check whether it compiles in your build environment? Yes, works fine now, thanks! >> > Please ping me, if you need a sponsor :) > I think, I will ask the regular sponsor for my qpdfview packages but > thanks for the offer. Ok :) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745691: django-classy-tags: FTBFS: Sphinx documentation not found
Hi, On Wed, Apr 23, 2014 at 10:58:49PM -0400, Aaron M. Ucko wrote: > Source: django-classy-tags > Version: 0.3.4.1-1 Did you mean 0.5.1-1? > Builds of django-classy-tags covering only its main > architecture-dependent binary package (as on the autobuilders) have > been failing: > >fakeroot debian/rules binary-arch > dh binary-arch --with python2,sphinxdoc > ... > dh_sphinxdoc -a > dh_sphinxdoc: Sphinx documentation not found > make: *** [binary-arch] Error 2 > > This is arguably a case of dh_sphinxdoc being too strict (reported as > #745690); until and unless that changes, though, please arrange to > supply --with sphinxdoc only when actually building the -doc package. There is a -2 in SVN, which makes the package arch:all and thus should fix this issue? Greets -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744917: luajit: diff for NMU version 2.0.3+dfsg-2.1
Hi, On 04/25/2014 09:24 PM, Enrico Tassi wrote: > On Fri, Apr 25, 2014 at 08:25:16PM +0200, Evgeni Golov wrote: >> tags 744917 + patch >> tags 744917 + pending >> thanks >> >> Dear maintainer, >> >> I've prepared an NMU for luajit (versioned as 2.0.3+dfsg-2.1) and >> uploaded it to DELAYED/2. Please feel free to tell me if I >> should delay it longer. > > Can't you just call make passing LDCONFIG=/sbin/ldconfig ? > I don't like having patches around, expecially for this software. The > upstream dislikes it and in this case it does not seem necessary. As the Makefile defines "LDCONFIG=ldconfig", and not "LDCONFIG?=ldconfig", I can not :/ We could add the PATH in debian/rules instead. But I dislike workarounding upstream issues in debian/rules, tbh ;) Greets from the Salzburg BSP Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744917: luajit: diff for NMU version 2.0.3+dfsg-2.1
tags 744917 + patch tags 744917 + pending thanks Dear maintainer, I've prepared an NMU for luajit (versioned as 2.0.3+dfsg-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. diff -Nru luajit-2.0.3+dfsg/debian/changelog luajit-2.0.3+dfsg/debian/changelog --- luajit-2.0.3+dfsg/debian/changelog 2014-04-08 19:58:31.0 +0200 +++ luajit-2.0.3+dfsg/debian/changelog 2014-04-25 19:56:09.0 +0200 @@ -1,3 +1,11 @@ +luajit (2.0.3+dfsg-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * call ldconfig with explicit /sbin in $PATH +Closes: #744917 + + -- Evgeni Golov Fri, 25 Apr 2014 19:53:24 +0200 + luajit (2.0.3+dfsg-2) unstable; urgency=medium * Fix multilib value in .pc file (Closes: #743762) diff -Nru luajit-2.0.3+dfsg/debian/patches/0005-call-ldconfig-with-explicit-sbin-in-PATH.patch luajit-2.0.3+dfsg/debian/patches/0005-call-ldconfig-with-explicit-sbin-in-PATH.patch --- luajit-2.0.3+dfsg/debian/patches/0005-call-ldconfig-with-explicit-sbin-in-PATH.patch 1970-01-01 01:00:00.0 +0100 +++ luajit-2.0.3+dfsg/debian/patches/0005-call-ldconfig-with-explicit-sbin-in-PATH.patch 2014-04-25 19:24:00.0 +0200 @@ -0,0 +1,26 @@ +From d151fa7e0187b8ac4392e667f3661743c6ac7318 Mon Sep 17 00:00:00 2001 +From: Evgeni Golov +Date: Fri, 25 Apr 2014 19:07:16 +0200 +Subject: [PATCH] call ldconfig with explicit /sbin in $PATH for calling it as + a user + +--- + Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/Makefile b/Makefile +index b23b648..2dfff68 100644 +--- a/Makefile b/Makefile +@@ -73,7 +73,7 @@ SYMLINK= ln -sf + INSTALL_X= install -m 0755 + INSTALL_F= install -m 0644 + UNINSTALL= $(RM) +-LDCONFIG= ldconfig -n ++LDCONFIG= PATH=/sbin:$$PATH ldconfig -n + SED_PC= sed -e "s|^prefix=.*|prefix=$(PREFIX)|" \ + -e "s|^multilib=.*|multilib=$(MULTILIB)|" + +-- +2.0.0.rc0 + diff -Nru luajit-2.0.3+dfsg/debian/patches/series luajit-2.0.3+dfsg/debian/patches/series --- luajit-2.0.3+dfsg/debian/patches/series 2014-04-08 19:58:31.0 +0200 +++ luajit-2.0.3+dfsg/debian/patches/series 2014-04-25 19:47:22.0 +0200 @@ -0,0 +1 @@ +0005-call-ldconfig-with-explicit-sbin-in-PATH.patch
Bug#744300: missing dependency on dh-python
control: tags -1 - moreinfo unreproducible control: severity -1 wishlist On Fri, Apr 25, 2014 at 04:51:19PM +0200, Evgeni Golov wrote: > On Sun, Apr 13, 2014 at 12:32:23AM +0800, Thomas Goirand wrote: > > The package is missing a dependency on dh-python, and therefore, it did > > FTBFS on my automated build system. Please fix it. > > The package builds fine in a clean uptodate sid chroot. > Can you please provide more info? This dependency is only needed when building backports for wheezy. As this is just to ease the backporters work, downgrading dependency to wishlist. Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744300: missing dependency on dh-python
control: tags -1 + moreinfo unreproducible Hi! On Sun, Apr 13, 2014 at 12:32:23AM +0800, Thomas Goirand wrote: > The package is missing a dependency on dh-python, and therefore, it did > FTBFS on my automated build system. Please fix it. The package builds fine in a clean uptodate sid chroot. Can you please provide more info? Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744229: qpdfview FTBFS synctex/synctex_parser.c:275:20: fatal error: zlib.h: No such file or directory
Hi, On Sat, Apr 12, 2014 at 01:26:07AM +0200, Benjamin Eltzner wrote: > Hi Peter, thanks a lot for the information. I will include zlib1g-dev as > build dependency in future versions of the package. However, as there > will probably be releases of qpdfview before the Jessie freeze and no > FTBFS occured yet on the debian builders, I would rather not provide an > updated package 0.4.9-2. Is that acceptable? I just tried your package in a clean sid cowbuilder, and it failed with the reported problem. I would suggest uploading a fix, as such FTBFS can hinder people fixing other bugs in your package. Please ping me, if you need a sponsor :) Regards Evgeni -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741806: pygresql: diff for NMU version 1:4.0-3.1
tags 741806 + patch
tags 741806 + pending
thanks
Dear maintainer,
I've prepared an NMU for pygresql (versioned as 1:4.0-3.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
Regards.
diff -u pygresql-4.0/setup.py pygresql-4.0/setup.py
--- pygresql-4.0/setup.py
+++ pygresql-4.0/setup.py
@@ -92,13 +92,12 @@
os.rmdir('include')
pg_include_dir = pg_config('includedir')
-#pg_include_dir_server = pg_config('includedir-server')
+pg_include_dir_server = pg_config('includedir-server')
#rm_include()
#mk_include()
-#include_dirs = ['include', pg_include_dir, pg_include_dir_server]
-include_dirs = ['include', pg_include_dir]
+include_dirs = ['include', pg_include_dir, pg_include_dir_server]
pg_libdir = pg_config('libdir')
library_dirs = [pg_libdir]
diff -u pygresql-4.0/debian/control pygresql-4.0/debian/control
--- pygresql-4.0/debian/control
+++ pygresql-4.0/debian/control
@@ -2,7 +2,7 @@
Section: python
Priority: optional
Maintainer: Debian QA Group
-Build-Depends: debhelper (>= 7), python-all-dev (>= 2.6.6-14), python-all-dbg, libpq-dev, libssl-dev
+Build-Depends: debhelper (>= 7), python-all-dev (>= 2.6.6-14), python-all-dbg, libpq-dev, postgresql-server-dev-all, libssl-dev
Build-Conflicts: python-setuptools
XS-Python-Version: all
Standards-Version: 3.9.1
diff -u pygresql-4.0/debian/changelog pygresql-4.0/debian/changelog
--- pygresql-4.0/debian/changelog
+++ pygresql-4.0/debian/changelog
@@ -1,3 +1,12 @@
+pygresql (1:4.0-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add B-D on postgresql-server-dev-all.
+ * Add includedir-server to includes.
+Closes: #741806
+
+ -- Evgeni Golov Fri, 25 Apr 2014 15:15:25 +0200
+
pygresql (1:4.0-3) unstable; urgency=low
* Orphan the package.
Bug#744917: FTBFS when /sbin is not in $PATH
Source: luajit Version: 2.0.3+dfsg-2 Severity: serious Tags: upstream Hi, when building LuaJIT as a normal user (even when using fakeroot), LuaJIT will FTBFS: fakeroot debian/rules binary dh --with quilt binary dh_testroot dh_prep debian/rules override_dh_auto_install make[1]: Entering directory `/tmp/luajit-2.0.3+dfsg' make install PREFIX=/usr DESTDIR=$PWD/debian/tmp/ MULTILIB=lib/x86_64-linux-gnu make[2]: Entering directory `/tmp/luajit-2.0.3+dfsg' Installing LuaJIT 2.0.3 to /usr mkdir -p /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/bin /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/include/luajit-2.0 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/share/man/man1 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/pkgconfig /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/share/luajit-2.0.3/jit /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/share/lua/5.1 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/lua/5.1 cd src && install -m 0755 luajit /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/bin/luajit-2.0.3 cd src && test -f libluajit.a && install -m 0644 libluajit.a /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/libluajit-5.1.a || : rm -f /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/bin/luajit /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2.0.3 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/libluajit-5.1.so /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/libluajit-5.1.so cd src && test -f libluajit.so && \ install -m 0755 libluajit.so /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/libluajit-5.1.so.2.0.3 && \ ldconfig -n /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu && \ ln -sf libluajit-5.1.so.2.0.3 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/libluajit-5.1.so && \ ln -sf libluajit-5.1.so.2.0.3 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/libluajit-5.1.so || : /bin/sh: 3: ldconfig: not found cd etc && install -m 0644 luajit.1 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/share/man/man1 cd etc && sed -e "s|^prefix=.*|prefix=/usr|" -e "s|^multilib=.*|multilib=lib/x86_64-linux-gnu|" luajit.pc > luajit.pc.tmp && \ install -m 0644 luajit.pc.tmp /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/lib/x86_64-linux-gnu/pkgconfig/luajit.pc && \ rm -f luajit.pc.tmp cd src && install -m 0644 lua.h lualib.h lauxlib.h luaconf.h lua.hpp luajit.h /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/include/luajit-2.0 cd src/jit && install -m 0644 bc.lua v.lua dump.lua dis_x86.lua dis_x64.lua dis_arm.lua dis_ppc.lua dis_mips.lua dis_mipsel.lua bcsave.lua vmdef.lua /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/share/luajit-2.0.3/jit ln -sf luajit-2.0.3 /tmp/luajit-2.0.3+dfsg/debian/tmp//usr/bin/luajit Successfully installed LuaJIT 2.0.3 to /usr make[2]: Leaving directory `/tmp/luajit-2.0.3+dfsg' sed -i 's?^multilib=.*?multilib=lib/x86_64-linux-gnu?' \ debian/tmp/usr/lib/x86_64-linux-gnu/pkgconfig/*.pc make[1]: Leaving directory `/tmp/luajit-2.0.3+dfsg' dh_install dh_install: libluajit-5.1-dev missing files (usr/lib/*/libluajit-5.1.so), aborting make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 The crucial part is: /bin/sh: 3: ldconfig: not found The Makefile defines: LDCONFIG= ldconfig -n But ldconfig is in /sbin and this is not in the $PATH of a normal user. Regards Evgeni -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743128: [Pkg-utopia-maintainers] Bug#743128: network-manager: NM does not work (without systemd)
On Mon, Mar 31, 2014 at 11:40:41AM +0200, Ralf Jung wrote: > However, interesting enough, just *installing* systemd (without using > it) already improves the situation a lot: "nmcli c" works as expected, > and the KDE plasma-nm applet shows the available and stored connections. > However, for some reason, automatically connecting to a network does not > work in this mode. After startup, I have to click "Connect" in the > applet to initiate a wireless connection. And after resume, I have to > click "Disconnect" and then "Connect" again for NM to re-establish my > wireless connection. To make things more interesting... :) I am running LightDM with Xfce, systemd is installed, but currently not used. systemd-logind is running (204-7, as my machine was not rebooted for a while). NM 0.9.8.8-5 works just fine as long I am logged in. When I put my machine to sleep (s2ram) or just lock it for an extended period of time, NM will tell me that my networking is completely disabled, service network-manager restart fixes this, and I can connect to WiFi, 3G and Ethernet just fine. Is this the said magic in systemd 204, which is gone in 208? Greets Evgeni, who likes systemd but would prefer NM not depending on it being PID 1 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#725563: python-naturalsort: diff for NMU version 1.0.3-1.1
tags 725563 + patch tags 725563 + pending thanks Dear maintainer, I've prepared an NMU for python-naturalsort (versioned as 1.0.3-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. diff -Nru python-naturalsort-1.0.3/debian/changelog python-naturalsort-1.0.3/debian/changelog --- python-naturalsort-1.0.3/debian/changelog 2013-09-19 14:47:15.0 +0200 +++ python-naturalsort-1.0.3/debian/changelog 2014-03-28 20:43:12.0 +0100 @@ -1,3 +1,10 @@ +python-naturalsort (1.0.3-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add python-setuptools to Build-Depends. (Closes: #725563) + + -- Evgeni Golov Fri, 28 Mar 2014 20:42:21 +0100 + python-naturalsort (1.0.3-1) unstable; urgency=low * Initial release (closes: #723742). diff -Nru python-naturalsort-1.0.3/debian/control python-naturalsort-1.0.3/debian/control --- python-naturalsort-1.0.3/debian/control 2013-09-19 14:33:50.0 +0200 +++ python-naturalsort-1.0.3/debian/control 2014-03-28 20:42:18.0 +0100 @@ -4,6 +4,7 @@ Section: python Priority: optional Build-Depends: python-all (>= 2.6.6-3), +python-setuptools, debhelper (>= 7) Standards-Version: 3.9.4
Bug#732963: ssh fails with OpenSSL version mismatch. Built against 1000105f, you have 10001060
Package: libssl1.0.0 Version: 1.0.1e-5 Severity: critical Hi, with the recent libssl upgrade, my openssh client stoped working. e.g.: % ssh pinky.die-welt.net OpenSSL version mismatch. Built against 1000105f, you have 10001060 Running openssh with -vvv does not bring any more light. If this is intended (is it?), the ABI should have been bumped. Regards Evgeni -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libssl1.0.0 depends on: ii debconf [debconf-2.0] 1.5.52 ii libc6 2.17-97 ii multiarch-support 2.17-97 libssl1.0.0 recommends no packages. libssl1.0.0 suggests no packages. -- debconf information: libssl1.0.0/restart-services: libssl1.0.0/restart-failed: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726012: orange: depends on librapi2, libsynce which are to be removed
reassign -1 ftp.debian.org retitle -1 RM: orange -- RoM On Wed, Oct 16, 2013 at 03:48:03PM +0200, Michael Biebl wrote: > I'm bumping the severity to serious, since this is blocking the removal > of hal which we should get rid of sooner rather then later. then let's drop orange too. Neither me nor upstream is heavily interested in it anyways. Greets Evgeni -- Bruce Schneier can read and understand Perl programs. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713474: desmume: FTBFS: ld: cannot find -lzzip
Hi David,
On Sat, Jun 22, 2013 at 01:57:45PM +0200, David Suárez wrote:
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
Thanks for the rebuild and the checks of Debian's quality!
> Relevant part:
Sadly, it isn't.
> > configure:5713: checking for zzip_open in -lzzip
> > configure:5738: gcc -o conftest -g -O2 -fstack-protector
> > --param=ssp-buffer-size=4 -Wformat -Werror=format-security
> > -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,defs -Wl,--as-needed conftest.c
> > -lzzip -lz >&5
> > /usr/bin/ld: cannot find -lzzip
> > collect2: error: ld returned 1 exit status
Usual autoconf foo. It is looking for libzzip and does not find it. Pretty
normal.
> The full build log is available from:
>
> http://aws-logs.debian.net/ftbfs-logs/2013/06/20/desmume_0.9.9-1_unstable.log
This shows the actuall error:
> checking for GTKGLEXT... no
> configure: error: Package requirements ("gtkglext-1.0") were not met:
>
> Package pangox was not found in the pkg-config search path.
> Perhaps you should add the directory containing `pangox.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'pangox', required by 'GdkGLExt', not found
Which is http://bugs.debian.org/709554, so not a bug in desmume.
I am leaving this bug open to document that desmume *does*
ftbfs in sid at the moment.
David, would it be possible to improve your scripts to catch the
atuall error-source? :)
Regards
Evgeni
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707412: [Pkg-ayatana-devel] Bug#707412: FTBFS: error: expected start element of `parameter'
On 05/13/2013 10:59 AM, Evgeni Golov wrote: > On 05/13/2013 10:49 AM, Emilio Pozuelo Monfort wrote: >>> The ftbfs bugs caused by vala and a new gobject-introspection can >>> easily be >>> fixed (at least in most cases) by switching to valac-0.20 which just >>> got its way >>> into unstable. I just fixed bug #707378 this way by switching the build >>> dependency accordingly. >> >> BTW it's preferred to switch to 'valac (>= 0.20)' instead of >> 'valac-0.20' if possible so that we can seamlessly switch the vala >> interpreter in the future. > > But valac in unstable is still 0.16, at least according to my rmadisson? > Wouldn't this trigger FTBFS (until there is a proper valac) too? My bad. apt says there is 0.20. rmadisson seems broken then :/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707412: [Pkg-ayatana-devel] Bug#707412: FTBFS: error: expected start element of `parameter'
On 05/13/2013 10:49 AM, Emilio Pozuelo Monfort wrote: >> The ftbfs bugs caused by vala and a new gobject-introspection can >> easily be >> fixed (at least in most cases) by switching to valac-0.20 which just >> got its way >> into unstable. I just fixed bug #707378 this way by switching the build >> dependency accordingly. > > BTW it's preferred to switch to 'valac (>= 0.20)' instead of > 'valac-0.20' if possible so that we can seamlessly switch the vala > interpreter in the future. But valac in unstable is still 0.16, at least according to my rmadisson? Wouldn't this trigger FTBFS (until there is a proper valac) too? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
