Bug#1073188: dxvk: FTBFS on arm64 due to x86_64-w64-mingw32-gcc using -mbranch-protection=standard
Quack, Thanks for your help. The upload is coming. \_o< -- Marc Dequènes
Bug#1061421: Fails to start after an upgrade
Quack, On 2024-05-08 09:40, Marc Dequènes wrote: Not sure this is the same problem but I would say it's worth a try. I'll prepare the package and let you know how it goes. I packaged and uploaded 0.5.0 and this bug is fixed for me now, but I'd like to hear from you all before closing this bug. I'm still not sure 0.5.0 fixes this bug and I do not have time to explore all possibilities. As Peter found in #1065506 building with newer wayland and smithay versions can cause problems because there's important changes in newer versions and that may be the real source of this problem. Until upstream works on bumping the deps they are now locked. It's annoying to keep multiple versions around but there's no way around it at the moment. I'm using greetd 0.10.0 as upstream bumped the requirement for the greetd_ipc component. I don't think that's necessary to have such combination according to what changed in 0.10 and I left the link between both packages loose as before. Tell me if you encounter any problem. Regards. \_o< -- Marc Dequènes
Bug#1061421: Fails to start after an upgrade
Quack, On 2024-04-22 00:44, Jeremy Bícha wrote: There have been a huge amount of changes, but most of those changes were in Unstable and haven't reached Testing yet. I can confirm the problem is still there in latest unstable. Marc, there is a fix for sway 1.9 in wlgreet 0.5. Do you want to try if that improves anything here? Not sure this is the same problem but I would say it's worth a try. I'll prepare the package and let you know how it goes. Regards. \_o< -- Marc Dequènes
Bug#1061421: Fails to start after an upgrade
Control: tag -1 +help Quack, On 2024-01-24 19:04, Arto Jantunen wrote: After a semi-recent upgrade (I'm not sure which one, as I don't reboot or restart my session after each one) of testing wlgreet no longer starts. Here is what I get when trying to start it under a manually launched sway session: Thanks for the report. I stumbled onto the same problem but so far was not able to identify what's going on. Rebuilding the package does not help. I guess it's related to libraries that are loaded dynamically, possibly mesa, but it does not seem like an ABI breakage. I'll try to dig deeper but l’m open to suggestion. Regards. \_o< -- Marc Dequènes
Bug#1050769: dh-cargo: should provide a build() method
Quack, Sorry for the lag, I really lacked time and energy recently but I'll try to upload a fix soon. On 2023-10-07 04:09, Jeremy Bícha wrote: No, greetd needs to build itself correctly regardless of whether there are helper functions available. You're right and I did not realize nocheck would be used for real in this package. I never saw this as a perfect solution but until debcargo implements what's needed that seemed fine. https://salsa.debian.org/debian/greetd/-/merge_requests/4 It looks fine but that's precisely what I wanted to avoid: I do not want to maintain the build steps and have to update the calls and flags when cargo or any other piece of tooling changes. Maybe that won't change often but that's still silly to implement that in each and every leaf package and as a consequence there's no unified policy. Unfortunately I do not have the bandwidth to propose debcargo changes. So I guess I'll apply the patch you kindly provided but I'm thinking about handing over the maintainership of wlgreet and greetd to people who really have time to do it properly, or… maybe comaint. Anyway, thanks for the report and patch everyone. \_o< -- Marc Dequènes
Bug#1032289: libdiplay-info: Keep out of the Bookworm release
Quack, On 2023-07-08 01:30, Jeremy Bícha wrote: Could you upload the version from Experimental to Unstable? I just got back Pond and checked if there was a new version first; no luck with that but I uploaded the version in experimental in unstable and it just got ACCEPTED, enjoy. \_o< -- Marc Dequènes
Bug#1032914: phog: ships /etc/pam.d/greetd
Quack Arnaud, greetd was unblocked today. Thanks for your help :-). \_o< -- Marc Dequènes
Bug#1032914: phog: ships /etc/pam.d/greetd
Quack, On 2023-03-24 18:24, Arnaud Ferraris wrote: Well yes, it was only supposed to be transitional waiting for https://lists.sr.ht/~kennylevinsen/greetd/patches/36264 to land upstream, but I went a bit too optimistic on that one, my bad... That's fine. The greeter PAM config drops the gnome-keyring/kwallet bits in order to be a bit lighter at runtime (those lines cause at least "gnome-keyring-daemon" to be started for user "_greetd", which is basically useless as it's a system user with no actual use of a keyring). Therefore I feel it's best to keep both config separate, but I'd be fine with a single config if you prefer it that way. Ok, makes sense, I was not aware it spawned anything. Thanks for the comments, I'm attaching the updated patches. Thanks for your work. I just merged it and will be uploading shortly. Regards. \_o< -- Marc Dequènes
Bug#1032914: phog: ships /etc/pam.d/greetd
Quack, On 2023-03-21 18:49, Arnaud Ferraris wrote: @duck, any comment on the above? Thanks for the contribution. Honestly when I read the title I really wondered how phog could have ended-up shipping this file. I forgot it initially, was asked about it and added it quickly, so it's not like I would have rejected the idea. Anyway, back to the patch itself. First I wonder if it's useful to ship the second PAM config since in the code (greetd/src/server.rs#211) it simply use the base greetd PAM configuration as a fallback; this is not a blocker though. Then I would prefer if the changelog entries were shipped with the corresponding changes and not in a lump afterwards. Also the "debian:" and "d/*:" prefixes are not the style I use. Maybe I'm missing why some people still use it but with the VCS taking care of remembering which files have been changed I don't feel the need to add this anymore and it's not very non-DD friendly. I like your comments to clearly explain the rationale. Regards. \_o< -- Marc Dequènes
Bug#1032289: Keep out of the Bookworm release
Source: libdisplay-info Severity: serious The library is new and just starting to be stable, with no rdepends yet, so even if the binary is useful to get info I'm not sure it's worth maintaining a full release cycle. \_o< -- Marc Dequènes
Bug#1030047: ruby-sanitize: CVE-2023-23627
Quack Salvatore, Thanks for the patch, it looks good. I'm in the Ruby team but not involved in this particular package but I think we can let your NMU flow. It's causing havoc on other packages so the sooner the better :-). Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, I just packaged DXVK 2.0 which brings lots of improvements. It is the first time since I took over that the requirements were bumped and the bar is high: Wine 7.1 and Mesa3d 22.0 (minimum version, not recommended): https://github.com/doitsujin/dxvk/wiki/Driver-support With the current lag of the Wine packaging it is not sufficient to use wine-stable at the moment. I'm not closing this bug but I really think that if someone really wants DXVK with stable then a dxvk-stable package would be needed. As stated before I'm not interested in maintaining such package but if someone would step up then we could sync our packages and collaborate. Regards. \_o< -- Marc Dequènes
Bug#1025872: installing greetd immediately reboots and prevents any logins
Quack, On 2022-12-11 09:20, Johannes Schauer Marin Rodrigues wrote: 1. do not start the greetd service by default installing a package should not result into logging out the currently active user I only tested greetd in the console after having started my previous login manager and did not hit this problem but that's indeed an unpleasant behavior. I had a quick look at lightdm and gdm3 and I don't see anything preventing them from doing the same thing. Not starting is an option but I'd like to look around a little bit more before making a decision. 2. provide a sensible default. Using $SHELL makes no sense when the default shell of the user running greetd is /usr/sbin/nologin. Maybe replace $SHELL with /bin/bash? I tested agreety but did not check it again before the upload. I'll try it with dash first, maybe we do not need a dependency on bash. Thanks for the report, I hope to have this sorted out soon. Regards. \_o< -- Marc Dequènes
Bug#1022340: redmine: FTBFS: Could not find gem 'csv (~> 3.2.0)' in cached gems or installed locally. The source contains the following gems matching 'csv': csv-3.1.9
Quack, Thanks for the report. When I first read the logs I could not fathom what was going on: we B-D on ruby-csv (>= 3.2.0) and it's not even installed! So it happens that libruby3.0 provides ruby-csv but it explicitly specify ruby-csv (= 3.1.9). I seems the resolver is confused by the fact libruby3.0 also has to be present to satisfy another dep. I'm going to open a BR to get some help. Regards. \_o< -- Marc Dequènes
Bug#1011443: faker,ruby-faker: error when trying to install together
Quack, On 2022-07-06 06:18, Antonio Terceiro wrote: I just did that. Remember that you need to add Breaks:/Replaces: on your package for upgrades to work. Thanks Antonio. The initial report did not have this analysis and I did not did not have time to dig into it. Regards. \_o< -- Marc Dequènes
Bug#1010941: python-argcomplete salvaging and possible team (re)join
Quack, On 2022-05-14 04:03, Yaroslav Halchenko wrote: I have just uploaded to --delayed 5 a workaround fix for #1010941 (FTBFS). The diff is attached Thanks for the workaround. I'm going to proceed with the salvaging soon now that the delay has passed. Please give me a few days without NMUs so I can bring it up to shape. would also be nice to add tags (may be original from Marco?) for prior upstream/debian releases. When I made my previous upload I did not realize everything was not in the VCS and unfortunately removed past changes. I plan to recreate history and add the tags but commits you made will have to be recreated on top of them and won't have the same id. Regards. \_o< -- Marc Dequènes
Bug#1009208: ruby-i18n breaks ruby-faker autopkgtest: FrozenError: can't modify frozen Array
Quack, Indeed, I failed to see it was assigned to both, thanks for the fix. \_o< -- Marc Dequènes
Bug#1009891: hexchat locks up hard when connecting to bip server
Quack Seven, I'm involved with bip packaging and upstream and we wondered what version of bip you are using. Did you upgrade bip recently? We have yet no reason to think that it could be triggered by a bug in bip, just checking. Clearly hexchat should behave better anyway. Can you reproduce this problem by connecting directly to the IRC server? Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, On 2022-03-11 21:52, Adrian Bunk wrote: dxvk should have an RC bug documenting why it is not in testing, and this bug in dxvkshould be fixed by using the non-development version of wine. I agree documenting is nice but this is not my decision. It is unlikely that wine maintainers would change their mind and push -devel in a stable release but if that were to happen then this package would needlessly be blocked by this bug now. The fact that it does not work with wine-stable is another matter entirely. As for the use of wine-stable as stated previously I have no idea what are the consequences of building with an old version and using it with the -devel one. Creating a dxvk-stable would be safer but since I never use wine-stable I would not wish to maintain it. I do not have any knowledge of the DXVK or wine code and did not have time to look into it or ask upstream about it, but if you do then I'll be happy to hear about it (you seem to be sure that's the obvious solution so I guess you do). For testing migration of dxvk this does not make a difference, but it highlights that there is a bug in dxvk that needs fixing. This is a new feature of the package, thus "wishlist" severity. And I'm not going to skip over this BR just because the severity is not RC. Anyway, that does not change much but I find it very annoying when people play with severity without explaining why. I think mixing the not-in-stable and does-not-work-with_wine-stable questions is confusing. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Btw, Adrian could you clarify with you bumped the severity? wine-development was already blocked from entering Bullseye and that blocked dxvk as well, so no need to add a RC bug just for that. Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Could you please test the changes in branch 'br982159' on Salsa and tell me if it works for you? Regards. \_o< -- Marc Dequènes
Bug#991384: libwine-development fails to install on arm*: head: cannot open '/usr/aarch64-w64-mingw32/lib/zlib*.dll' for reading: No such file or directory
Quack, Could you have a look at this bug please? I'm trying to fix cross-compilation problems on dxvk but cannot even get a test build to run because of this issue: https://salsa.debian.org/aviau/dxvk/-/jobs/2455425 Regards. \_o< -- Marc Dequènes
Bug#982159: dxvk: Dependency on development version of WINE might not be justified
Quack, Sorry for the late reply. You're right DXVK can now handle wine-stable version (5.0.3). I have not tested it but upstream claims 3.10 as the minimum version needed. That still won't let this package into testing though as it is built against libwine-development-dev that will never reach testing. Without making two separate packages I don't think that would work. Also, with the important gap between stable and devel versions I'm wondering how DXVK is going to perform. Again without another package built with libwine I don't see how we can be sure that's not gonna break. I personally stopped using the Debian packaged wine-development because they are unable to keep up with the release frequency (and also did not seem willing to accept me in their team to contribute) and I've been using the packages provided on winehq and that never broke so far. That is to say I may have overestimated the risk. I'm not really interested in creating another package for stable knowing I would never use it myself and thus would not be able to test it, but I'm ok to remove the restrictions on dxvk-setup. I'll schedule that for the next upload. Regards. \_o< -- Marc Dequènes
Bug#993994: vulkan-validationlayers: Requesting VK_LAYER_KHRONOS_validation crash with undefined symbol: _Z14GetEnvironmentB5cxx11PKc
Quack, There has been no response for almost a month and this breaks the sole usage of this package, therefore I just made an NMU. You can find my changes on Salsa: https://salsa.debian.org/xorg-team/vulkan/vulkan-validationlayers/-/merge_requests/1 Thanks Kienan for providing a link to the patch. Regards. \_o< -- Marc Dequènes
Bug#992385: x11-common: use of deprecated tempfile breaks login
Package: x11-common Version: 1:7.7+22 Severity: grave Quack, Since debianutils has dropped the deprecated `tempfile` in 5.0-1 /etc/X11/Xsession fails around the WRITE_TEST and this breaks graphical login completely. Commenting this section allowed me to log in. There is another call line 85 that needs to be changed too. Regards. \_o< -- Marc Dequènes
Bug#969206: Info received (redmine: Could not find gem 'rails (~> 5.2.2)' in any of the gem sources listed in your Gemfile)
Control: affects -1 redmine-plugin-custom-css Quack, I finished packaging 4.2.1 a few days ago and I can confirms this totally does not work. Upstream had piled on many patches and now targeting Rails 6.1. Unfortunately this is not over and 5.0 has many tasks assigned which are not done. \_o< -- Marc Dequènes
Bug#987331: ruby-mysql2: flaky autopkgtest
Version: 0.5.3-3 I forgot to close it in the changelog, sorry. -- Marc Dequènes
Bug#969206: redmine: Could not find gem 'rails (~> 5.2.2)' in any of the gem sources listed in your Gemfile
Quack, Indeed we'll have to wait for 5.0. I had hope for 4.2 but it was pushed back and despite interesting fixes planned for this release that's most probably not going to work. It's unfortunate Redmine's development is going so slowly. Anyway we plan to provide a package in backports whenever possible. \_o< -- Marc Dequènes
Bug#980437: libdqlite-dev: missing dependency on libsqlite3-dev
Package: libdqlite-dev Version: 1.6.0-1+b1 Severity: serious Quack, Similarly as libdqlite0 depends on libsqlite3-0 this dependency is needed too. Regards. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
Quack, On 2020-12-05 05:00, Michael Biebl wrote: hidepid is known to cause problems and no longer a supported configuration: https://www.debian.org/releases/stable/amd64/release-notes/ch-information.de.html#hidepid-unsupported Thanks for pointing this out, I did not know it was officially unsupported. I was already using the workaround for logind for quite a while and it is working fine. As for the polkit workaround it requires polkit from experimental. I tried (with systemd 246.6-5) but it seems the client also do things of its own and that is not sufficient. I then disabled hidepid and polkit is now working with 246.6-5. Switching back to 247.1-3 I'm hitting the same problem. If a polkit agent is absolutely necessary then I'm not sure how it's supposed to work since it is launched (in the recommended sway config) after a graphical session is created by sway and it's already too late (the error messages came from sway initializing inputs). I cannot run the polkit agent before because it complains there is no display and quit. I have no idea how desktop environments handle this. I could not find anyone using sway doing differently but 247 is fairly recent. Would you have any idea? Anything to experiment? Regards. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
On 2020-12-04 17:04, Michael Biebl wrote: Is policykit-1 installed and working? I dug a little bit more on this front and I am affected by this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860040 which then made the polkit agent quit on start. I have not tested yet if removing hidepid would be sufficient but polkit's behavior is really annoying. -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
On 2020-12-04 17:04, Michael Biebl wrote: Control: tags -1 + moreinfo Am 04.12.20 um 07:00 schrieb Marc Dequènes (duck): After upgrade from 246.6-5 to 247.1-3 I experienced impossibility to use my keyboard after login on graphical session. I'm using Lightdm + Sway and could input with my usual keyboard for encrypted disk passphrase, GRUB, and lightdm login screen too. Console also was working fine. But after login on lightdm I could not input anything in Sway while the mouse worked fine (but I could not do much). I wonder if this is related to https://github.com/systemd/systemd/issues/17473 Is policykit-1 installed and working? Is libpam-systemd installed and enabled? They are both installed. libpam-systemd seems to be enabled properly: $ rgrep pam_systemd.so /etc/pam.d/ /etc/pam.d/lightdm-greeter:session optional pam_systemd.so /etc/pam.d/runuser-l:-session optionalpam_systemd.so /etc/pam.d/common-session:session optionalpam_systemd.so [with 246.6-5] I got a XDG_SESSION_ID defined and /run/user/ is properly created too. As for policykit, the polkit service is running. How can I test it works well? Regards. \_o< -- Marc Dequènes
Bug#976366: Upgrade to 247 broke keyboard input on Wayland session
Package: systemd Version: 247.1-3 Severity: critical Justification: breaks graphical session input Control: affects -1 sway Quack, After upgrade from 246.6-5 to 247.1-3 I experienced impossibility to use my keyboard after login on graphical session. I'm using Lightdm + Sway and could input with my usual keyboard for encrypted disk passphrase, GRUB, and lightdm login screen too. Console also was working fine. But after login on lightdm I could not input anything in Sway while the mouse worked fine (but I could not do much). I was able to capture this error in sway log: 00:00:00.142 [ERROR] [backend/session/logind.c:75] Failed to take device '/dev/input/event5': No such device 00:00:00.143 [ERROR] [backend/session/logind.c:75] Failed to take device '/dev/input/event6': No such device These files existed and were using the usual root:input rw/rw/- permissions. These are devices for my keyboard and LightDM X session enumerates them properly: [31.282] (II) config/udev: Adding input device ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB (/dev/input/event5) [31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: Applying InputClass "evdev pointer catchall" [31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: Applying InputClass "evdev keyboard catchall" [31.282] (II) Using input driver 'evdev' for 'ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB' [31.282] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: always reports core events [31.282] (**) Option "config_info" "udev:/sys/devices/virtual/input/input27/event5" [31.282] (II) XINPUT: Adding extended input device "ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB" (type: KEYBOARD, id 12) [31.282] (**) Option "xkb_rules" "evdev" [31.282] (**) Option "xkb_model" "pc105" [31.282] (**) Option "xkb_layout" "us" [31.282] (**) Option "xkb_variant" "altgr-intl" [31.282] (**) Option "xkb_options" "compose:menu,level3:ralt_switch" [31.283] (II) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: initialized for relative axes. [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) keeping acceleration scheme 1 [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) acceleration profile 0 [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) acceleration factor: 2.000 [31.283] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vKB: (accel) acceleration threshold: 4 [31.284] (II) config/udev: Adding input device ckb1: Corsair Gaming K70 LUX RGB Keyboard vM (/dev/input/event6) [31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Applying InputClass "evdev pointer catchall" [31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Applying InputClass "evdev keyboard catchall" [31.284] (II) Using input driver 'evdev' for 'ckb1: Corsair Gaming K70 LUX RGB Keyboard vM' [31.284] (**) ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: always reports core events [31.284] (**) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Device: "/dev/input/event6" [31.284] (--) evdev: ckb1: Corsair Gaming K70 LUX RGB Keyboard vM: Vendor 0x1b1c Product 0x1b33 [31.284] (**) Option "config_info" "udev:/sys/devices/virtual/input/input28/event6" [31.284] (II) XINPUT: Adding extended input device "ckb1: Corsair Gaming K70 LUX RGB Keyboard vM" (type: KEYBOARD, id 13) My /etc/systemd/logind.conf is unaltered from the default. I did not find any apparmor denial. I could not find anything meaningful in systemd logs or others. Then I checked what packages were upgraded recently and gave it a try downgrading to 246.6-5, and after a reboot it worked. Tell me if I can provide any other information. Regards. \_o< -- Marc Dequènes
Bug#816640: ruby-eventmachine: FTBFS under pbuilder with USENETWORK=no: TestResolver fails (no implicit conversion of nil into String)
Quack, Andreas, could you explain to me why you reopened this ticket? Did you stumble on another test using the network? I built the package locally and on Salsa and it seemed to be fixed. Also I don't understand why you merged it with #919085 which seem to address a broader problem. I see one test failing on mipsel and other failures in non-releasing arches, but it seems the situation is different from the original report. I'm not sure how to fix this test yet. Regards. \_o< -- Marc Dequènes
Bug#956365: redmine: unmet dependencies
Control: severity -1 normal Control: tag -1 + unreproducible Quack, I just made a fresh install on today's unstable and cannot reproduce your installation problem. Involed libraried are: Setting up ruby-roadie-rails (1.3.0-2) ... Setting up ruby-roadie (4.0.0-1) ... Setting up ruby-actionpack-xml-parser (2.0.1-3) ... So maybe something was amiss in unstable at the time, or your gitlab installation added local gems, but this worked when I uploaded and it works now too. Did you install gitlab using the package? Could you see if this still a problem now? As for 4.1 I don't see the relationship. Anyway I need to wait in order to get buster-bpo in order and then either 4.1 or 4.2 would come in. Regards. -- Marc Dequènes
Bug#935339: ruby-svg-graph: depends on ancient 'parsedate' Ruby core library
package: ruby-svg-graph version: 1.0.5-3 severity: serious Quack, Sorry for the bad news but this library is not fit for release in this state. It depends on parsedate which was last seen in Ruby core in 1.8.7: /usr/lib/ruby/vendor_ruby/SVG/Graph/TimeSeries.rb 4: require 'parsedate' 197:arr = ParseDate.parsedate(time) /usr/lib/ruby/vendor_ruby/SVG/Graph/Schedule.rb 4: require 'parsedate' 169: arr = ParseDate.parsedate( data[:data][i] ) 187: arr = ParseDate.parsedate( value ) There is a patch, and a fix for the original path, here: http://www.redmine.org/issues/11290 I did not have time to test it yet, but if we want to keep this library around I think this is worth a try. Also Buster is affected so we should plan a backport when we have a working solution. I'm part of the Ruby team but in case I don't have time to look at it later here are the details I could collect. Regards. \_o< -- Marc Dequènes
Bug#924110: redmine-plugin-local-avatars: fails to install: NoMethodError: undefined method `to_prepare' for ActionDispatch::Callbacks:Class
Quack, This PR may help: https://github.com/ncoders/redmine_local_avatars/pull/21 There is a typo though: s/prepere/prepare/ You may wish to give it a try. At the moment I'm going to add a conflict on the current version from the redmine package to avoid migration failures. Regards. \_o< -- Marc Dequènes
Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)
Quack, On 2019-03-04 19:08, Stuart Caie wrote: How odd, but yes, I have a system where size_t = unsigned int, so it went unnoticed. I've fixed it and tested it on both the 32bit system and a 64bit system. Maybe gcc is too picky, I have no idea. I've released libmspack 0.10.1 Thanks a lot :-). \_o< -- Marc Dequènes
Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)
Quack, On 2019-03-04 10:40, Stuart Caie wrote: I've released libmspack 0.10 and cabextract 1.9.1. They contain only fixes. Thanks a lot for being so fast. Unfortunately there is a build problem: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./mspack -I./test -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Wno-unused-parameter -Wno-unused-result -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -c mspack/oabd.c -fPIC -DPIC -o mspack/.libs/oabd.o mspack/oabd.c:375:12: error: conflicting types for ‘copy_fh’ static int copy_fh(struct mspack_system *sys, struct mspack_file *infh, ^~~ mspack/oabd.c:37:12: note: previous declaration of ‘copy_fh’ was here static int copy_fh(struct mspack_system *sys, struct mspack_file *infh, ^~~ Indeed `bytes_to_copy` is not of the same type. Regards. -- Marc Dequènes
Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)
Quack, On 2018-12-04 19:02, Stuart Caie wrote: This is fixed in the repository, it just hasn't been released. I'll release it in the near future. I was myself busy and we missed the Debian freeze deadline. Maybe there is still some hope to convince the release team for an exception, as long as we push fixes only. Any plan to release shortly? \_o< -- Marc Dequènes
Bug#914794: libmspack fails tests on big endian architectures (s390x, mips)
Quack, Hello Stuart, here is a problem you might want to look at: On 2018-11-27 20:09, Matthias Klose wrote: Package: src:libmspack Version: 0.9.1-1 Severity: serious Tags: sid buster libmspack fails tests on big endian architectures (s390x, mips) make check-TESTS make[2]: Entering directory '/<>' make[3]: Entering directory '/<>' FAIL: test/cabd_test PASS: test/chmd_test PASS: test/kwajd_test libmspack 0.9.1alpha: ./test-suite.log # TOTAL: 3 # PASS: 2 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test/cabd_test /<>/test/test_files/cabd/bad_nofolders.cab: no folders in cabinet. /<>/test/test_files/cabd/bad_nofiles.cab: no files in cabinet. ERROR; file "2" cannot be extracted, cabinet set is incomplete cabd_extract_test_03:391 FAILED memcmp(md5_string, "940cba86658fbceb582faecd2b5975d1", 33) == 0 FAIL test/cabd_test (exit status: 1) Testsuite summary for libmspack 0.9.1alpha # TOTAL: 3 # PASS: 2 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to ky...@cabextract.org.uk make[3]: *** [Makefile:1278: test-suite.log] Error 1 make[3]: Leaving directory '/<>' make[2]: *** [Makefile:1386: check-TESTS] Error 2 make[2]: Leaving directory '/<>' make[1]: *** [Makefile:1607: check-am] Error 2 make[1]: Leaving directory '/<>' dh_auto_test: make -j2 check VERBOSE=1 returned exit code 2 make: *** [debian/rules:7: build-arch] Error 2 You can see full logs here: https://buildd.debian.org/status/package.php?p=libmspack Regards. \_o< -- Marc Dequènes
Bug#912806: redmine: Could not find public_suffix error with current testing packages
Control: severity -1 normal Control: tags -1 + unreproducible Quack, I just created a testing environment and was able to install and run Redmine 3.4.6-1 without any problem. Also debCI did not either catch such problem. ruby-public-suffix is an indirect dependency of Redmine, and in my test environment I also had 3.0.3+ds-1 installed. Bundler did not complain. So I'm sorry but I was not able to reproduce your problem. Did you have any plugins installed? \_o< -- Marc Dequènes
Bug#907118: error:141a318a:ssl routines:tls_process_ske_dhe:dh key too small
Control: -1 severity important Quack, This problem is solved in unstable and should not prevent this package from entering testing. \_o< -- Marc Dequènes
Bug#907528: synergy: low grade TLS certificate generation, now unusable in unstable
Package: synergy Version: 1.8.8-stable+dfsg.1-1.1 Severity: grave Tags: security Quack, With recent openssl upgrade (1.1.0h-4 -> 1.1.1~~pre9-1) the client fails to connect with error routines:SSL_CTX_use_certificate:ee key too small. The following script is used to generate the key: /usr/share/synergy/gen_ssl_pem.sh This script creates a 1024 bits RSA key, which is too small to be secure. This means it is security issue in all Debian suites. Regards. -- Marc Dequènes
Bug#906119: Gratuitous sexual references
Control: tag -1 wontfix Control: severity -1 wishlist Quack, A decision has already been made: http://lists-archives.com/debian-devel/230825-should-the-weboob-package-stay-in-debian.html I have added a warning in the description but I believe renaming is a major loss of time and energy for no interesting result. I cannot change the homepage URL and prevent people from going to the website, which is needed to have more info on the various modules, so this would not help. Also I believe hiding things from our sights is not a solution: if you want upstream to change their attitude, then have them convinced. At least now some limits are clear and if, for example, they reintroduce insults in the software's messages or source code the new version will not make it in Debian and later result in removal. From what I've seen while at DebConf woman's opinion on this topic does not match what self-appointed male knights have presented in the thread. Also renaming is not seen as a perfect solution either. So I'm sorry to say that you only represent your own personal opinion here. As for asking the release team, and while I value their input, this has never been their role. De facto ftpmaster has taken this burden and in the past has accepted, and later reaccepted this package. As for calling for a GR, this is not the goal of a GR as you have no general rule to suggest. While taking my decision I have tried to gather argumented criteria which I believe could rule out harmful content (despite a large grey zone), but noone wanted to discuss them, they were seen as mere excuses. So there is not even a beginning of discussion on this front. You anyway cannot use a GR for settling disagreements. If you wish to challenge my decision, then you should contact the technical committee (you were once part of this body but you must have forgotten). Looking at the prerequisite though it seems to me you have failed at « try to understand the other person's point of view » (and my experience at DebConf does not make me very optimistic). Regards. \_o< -- Marc Dequènes
Bug#897474: closed by Marc Dequènes (duck) (reply to d...@duckcorp.org) (Re: kwalify: FTBFS: ERROR: Test "ruby2.5" failed.)
sbuild-ing using the archive redownloaded source package also works fine. signature.asc Description: OpenPGP digital signature
Bug#904111: [Pkg-clamav-devel] Bug#904111: clamav-daemon causing deadlocks/blocking I/O
Quack, On 2018-07-24 15:18, Sebastian Andrzej Siewior wrote: On 2018-07-23 17:54:44 [+0900], Marc Dequènes wrote: Quack, Hi, I just upgraded and cannot reproduce this problem. I'm not using the ScanOnAccess feature. just to confirm: you can not reproduce the problem. I did not try to switch on ScanOnAccess on my production system, but with my configuration, which is not that different, I do not have the problem. I just tried loading Adam's configuration on another system to test the ScanOnAccess, copied a clamav test file in one of the protected directory and hit the problem. After that the whole machine becomes totally unresponsive in a few seconds. Jul 25 11:35:14 elwing kernel: [3112805.231170] clamd (13840): Using fanotify permission checks may lead to deadlock; tainting kernel Jul 25 11:36:24 elwing kernel: [3112875.408154] kauditd_printk_skb: 7 callbacks suppressed Jul 25 11:36:24 elwing kernel: [3112875.408155] audit: type=1400 audit(1532486184.205:794): apparmor="ALLOWED" operation="capable" profile="/usr/sbin/clamd" pid=13564 comm="clamd" capability=2 capname="dac_read_search" Jul 25 11:38:37 elwing kernel: [3113009.136000] INFO: task nfsd:20284 blocked for more than 120 seconds. I am using kernel 4.16.16-2~bpo9+1 on this machine. \_o< -- Marc Dequènes
Bug#904111: clamav-daemon causing deadlocks/blocking I/O
Quack, I just upgraded and cannot reproduce this problem. I'm not using the ScanOnAccess feature. Follows collected config info. \_o< -- Package-specific info: --- configuration --- Checking configuration files in /etc/clamav Config file: clamd.conf --- BlockMax disabled PreludeEnable disabled PreludeAnalyzerName = "ClamAV" LogFile = "/var/log/clamav/clamav.log" LogFileUnlock disabled LogFileMaxSize = "4294967295" LogTime = "yes" LogClean disabled LogSyslog disabled LogFacility = "LOG_LOCAL6" LogVerbose disabled LogRotate = "yes" ExtendedDetectionInfo = "yes" PidFile disabled TemporaryDirectory disabled DatabaseDirectory = "/var/lib/clamav" OfficialDatabaseOnly disabled LocalSocket disabled LocalSocketGroup disabled LocalSocketMode disabled FixStaleSocket = "yes" TCPSocket = "3310" TCPAddr disabled MaxConnectionQueueLength = "15" StreamMaxLength = "10485760" StreamMinPort = "1024" StreamMaxPort = "2048" MaxThreads = "10" ReadTimeout = "180" CommandReadTimeout = "5" SendBufTimeout = "200" MaxQueue = "100" IdleTimeout = "30" ExcludePath disabled MaxDirectoryRecursion = "15" FollowDirectorySymlinks disabled FollowFileSymlinks disabled CrossFilesystems = "yes" SelfCheck = "3600" DisableCache disabled VirusEvent disabled ExitOnOOM = "yes" AllowAllMatchScan = "yes" Foreground disabled Debug disabled LeaveTemporaryFiles disabled User = "clamav" Bytecode = "yes" BytecodeSecurity = "TrustSigned" BytecodeTimeout = "6" BytecodeUnsigned disabled BytecodeMode = "Auto" DetectPUA disabled ExcludePUA disabled IncludePUA disabled AlgorithmicDetection = "yes" ScanPE = "yes" ScanELF = "yes" DetectBrokenExecutables disabled ScanMail = "yes" ScanPartialMessages disabled PhishingSignatures = "yes" PhishingScanURLs = "yes" PhishingAlwaysBlockCloak disabled PhishingAlwaysBlockSSLMismatch disabled PartitionIntersection disabled HeuristicScanPrecedence = "yes" StructuredDataDetection disabled StructuredMinCreditCardCount = "3" StructuredMinSSNCount = "3" StructuredSSNFormatNormal = "yes" StructuredSSNFormatStripped disabled ScanHTML = "yes" ScanOLE2 = "yes" OLE2BlockMacros disabled ScanPDF = "yes" ScanSWF = "yes" ScanXMLDOCS = "yes" ScanHWP3 = "yes" ScanArchive = "yes" ArchiveBlockEncrypted disabled ForceToDisk disabled MaxScanSize = "104857600" MaxFileSize = "26214400" MaxRecursion = "16" MaxFiles = "1" MaxEmbeddedPE = "10485760" MaxHTMLNormalize = "10485760" MaxHTMLNoTags = "2097152" MaxScriptNormalize = "5242880" MaxZipTypeRcg = "1048576" MaxPartitions = "50" MaxIconsPE = "100" MaxRecHWP3 = "16" PCREMatchLimit = "1" PCRERecMatchLimit = "5000" PCREMaxFileSize = "26214400" ScanOnAccess disabled OnAccessMountPath disabled OnAccessIncludePath disabled OnAccessExcludePath disabled OnAccessExcludeRootUID disabled OnAccessExcludeUID disabled OnAccessMaxFileSize = "5242880" OnAccessDisableDDD disabled OnAccessPrevention disabled OnAccessExtraScanning disabled DevACOnly disabled DevACDepth disabled DevPerformance disabled DevLiblog disabled DisableCertCheck disabled Config file: freshclam.conf --- LogFileMaxSize = "4294967295" LogTime disabled LogSyslog disabled LogFacility = "LOG_LOCAL6" LogVerbose disabled LogRotate = "yes" PidFile disabled DatabaseDirectory = "/var/lib/clamav/" Foreground disabled Debug disabled UpdateLogFile = "/var/log/clamav/freshclam.log" DatabaseOwner = "clamav" Checks = "24" DNSDatabaseInfo = "current.cvd.clamav.net" DatabaseMirror = "db.local.clamav.net", "database.clamav.net" PrivateMirror disabled MaxAttempts = "5" ScriptedUpdates = "yes" TestDatabases = "yes" CompressLocalDatabase disabled ExtraDatabase disabled DatabaseCustomURL disabled HTTPProxyServer disabled HTTPProxyPort disabled HTTPProxyUsername disabled HTTPProxyPassword disabled HTTPUserAgent disabled NotifyClamd = "/etc/clamav/clamd.conf" OnUpdateExecute disabled OnErrorExecute disabled OnOutdatedExecute disabled LocalIPAddress disabled ConnectTimeout = "30" ReceiveTimeout = "30" SafeBrowsing disabled Bytecode = "yes" clamav-milter.conf not found Software settings - Version: 0.100.0 Optional features supported: MEMPOOL IPv6 FRESHCLAM_DNS_FIX AUTOIT_EA06 BZIP2 LIBXML2 PCRE ICONV JSON JIT Database information Database directory: /var/lib/clamav/ WARNING: freshclam.conf and clamd.conf point to different database directories [3rd Party] phishtank.ndb: 30797 sigs [3rd Party] bofhland_malware_attach.hdb: 1835 sigs [3rd Party] winnow_bad_cw.hdb: 1 sig [3rd Party] jurlbl.ndb: 14183 sigs [3rd Party] bofhland_malware_URL.ndb: 4 sigs [3rd Party] spamattach.hdb: 14 sigs [3rd Party] winnow_malware_links.ndb: 4623 sigs [3rd Party] doppelstern.hdb: 1 sig [3rd Party] winnow_malware.hdb: 293 sigs [3rd Party] winnow_extended_malware.hdb: 245 sigs [3rd Party] sanesecurity.ftm: 170 sigs [3rd Party] rogue.hdb: 4678 sigs [3rd Party] porcupine.ndb: 3341 sigs [3rd Party] phish.ndb: 27408 sigs [3rd Party] crdfam.clamav.hdb: 1 sig [3rd Party]
Bug#851093: bip: diff for NMU version 0.8.9-1.2
Quack, On 01/23/2018 07:45 AM, Sebastian Andrzej Siewior wrote: > I've prepared an NMU for bip (versioned as 0.8.9-1.2) and > uploaded it to DELAYED/4. Please feel free to tell me if I > should delay it longer. I was away for FOSDEM and other events. It seems fine, thanks. We've been late working on a release :-/. Hope we have more time for bip this year. \_o< signature.asc Description: OpenPGP digital signature
Bug#882315: marked as pending
tag 882315 pending thanks Hello, Bug #882315 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-ruby-extras/kwalify.git/commit/?id=53f33c3 --- commit 53f33c37c4885c9daf84aefba0a690ec93fb9704 Author: Marc Dequènes (Duck) <d...@duckcorp.org> Date: Mon Dec 25 16:17:23 2017 +0900 Updated patch to fix tests diff --git a/debian/changelog b/debian/changelog index 9f88b91..077c0b0 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,9 @@ +kwalify (0.7.2-5) UNRELEASED; urgency=medium + + * Updated patch to fix tests (Closes: #882315). + + -- Marc Dequènes (Duck) <d...@duckcorp.org> Mon, 25 Dec 2017 16:17:12 +0900 + kwalify (0.7.2-4) unstable; urgency=medium [ Marc Dequènes ]
Bug#868955: marked as pending
tag 868955 pending thanks Hello, Bug #868955 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-ruby-extras/redmine.git/commit/?id=854a82f --- commit 854a82fd70901defe33f8655dc656352b93bdd1b Author: Marc Dequènes (Duck) <d...@duckcorp.org> Date: Mon Nov 20 20:08:48 2017 +0900 Do not fail is manual database installation is selected diff --git a/debian/changelog b/debian/changelog index cf56df1..93948a7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -16,6 +16,8 @@ redmine (3.4.2-1) UNRELEASED; urgency=medium * Pass instance list to postrm to ensure removal works when things are broken (found in #868955). * Support dbconfig-no-thanks. + * Do not fail is manual database installation is selected (Closes: +#868955). [ Lucas Kanashiro ] * debian/copyright: fix path of redcloth3.rb file
Bug#881749: redmine: creates world-writable tempdir /tmp/bundler/home
Control: reassign -1 ruby-bundler
Control: tags -1 + security
Quack,
This repository is created by bundler, and there is no code in the
redmine package specifying this repository, so this is using the default
Bundler behavior.
In fact someone already reported about this directory being created and
left over in #796383, without seeing the security implications.
Also I looked into the code and in /usr/lib/ruby/vendor_ruby/bundler.rb
you can read the 'tmp_home_path' method:
path = Pathname.new(Dir.tmpdir).join("bundler", "home")
SharedHelpers.filesystem_access(path) do |tmp_home_path|
unless tmp_home_path.exist?
tmp_home_path.mkpath
tmp_home_path.chmod(0o777)
This is really horrible and I wonder how it was not found out earlier.
Anyway, reassigning and thanks for findind this out.
\_o<
--
Marc Dequènes
Bug#868955: redmine: buster - broken install, package cannot be removed
Quack, Thanks a lot for reporting and taking all this time to investigate. Antonio is stepping down and we need some time to take over properly. As for "redmine failed to preconfigure, with exit status 10", I guess this is a debconf problem. I'll try to have a look. As for your second attempt: Bundler will use `/tmp/bundler/home/hedges' as your home directory temporarily. I wonder how it get that path; are you using sudo without updating the HOME environment variable? I guess the directory does not exist, which would explain the failure. Also it says: `/var/www` is not writable. How can this be so if you're root? It would help if you could answer these questions. Regards. \_o< -- Marc Dequènes
Bug#872595: closed by Norbert Preining <prein...@debian.org> (Bug#872595: fixed in calibre 3.7.0+dfsg-1)
Control: -1 reopen Quack, Upstream ported the patch which fixes this one-off security problem, very well. Unfortunately this bug report is not about it, even if it was an example of how harmful having a copy of the code is. So it seems you don't get me right and I would encourage you to read the Debian Policy section 4.13 about this problem. Calibre has no good reason to borrow code from a maintained and packaged library. This library is lightweight and does not drag any other dependency, so upstream should not be shy about it. I'm adding the security team so they don't miss this problem and how this package (all versions) is affected by the libmspack security issues (part of). Regards. \_o< -- Marc Dequènes
Bug#870253: clamav-milter: disengaging debconf management destroys config
Quack, On 08/27/2017 04:56 AM, Sebastian Andrzej Siewior wrote: > I am going to drop that part where the debconf created file gets > overwritten with the sample file. Need to test before I commit it… Thanks. I can help you test if you provide a test package. \_o< signature.asc Description: OpenPGP digital signature
Bug#870253: clamav-milter: disengaging debconf management destroys config
Quack, On 08/21/2017 01:53 AM, Sebastian Andrzej Siewior wrote: > So if I modify the .conf file only with debconf and then (later) tell > debconf not to handle it then the "old" .conf file will be replaced with > upstream's default one. That's precisely what I did not expect. I can find this upstream example in /usr/share/doc by myself, so I don't see the point in switching to it. It's not like it represents my previous version of the configuration saved when debconf took over (as there was none, first installation). One may wish to use debconf to draft a configuration and then disengage debconf to customize it but it's not possible directly. This may be what people using ucf expect, and in this case you might probably close the bug, but I don't find this a nice behavior. To me disengaging debconf mean: leave as it is, I'll take care of it from now on. I should at least have a choice even if the file was not modified manually yet. The only change which I find legitimate is to remove the "managed by debconf" header. Hope this is clearer. \_o< signature.asc Description: OpenPGP digital signature
Bug#872595: calibre: please use system libmspack instead of embedded copy
Source: calibre Version: 3.4.0+dfsg-1 Severity: grave Tags: security upstream X-Debbugs-CC: t...@security.debian.org Quack, Sorry for the bad news, but Calibre embed a very old version of libmspack to build a plugin: /usr/lib/calibre/calibre/plugins/lzx.so Unfortunately, this library had a few security issues over time, and recently: https://security-tracker.debian.org/tracker/source-package/libmspack So this means Calibre is affected (all versions is Debian) by these two security bugs and probably other older ones. The proper solution would be to use the libmspack library which has been fixed with all the fixes backported to stable and oldstable. It is defined in 'setup/extensions.json' but I have no idea how to make it use the system library so I have no patch to suggest. Btw it seems 'src/calibre/utils/' contains a lot of borrowed code which might lead to security problems too, so I would suggest to have a look and work things out with upstream to at least have build flags to use system libraries when available. Regards. -- Marc Dequènes
Bug#868956: libmspack: CVE-2017-11423
Quack, On 08/07/2017 04:22 AM, Sebastian Andrzej Siewior wrote: > Marc do plan you upload something to unstable/security soon, wait for a > new release or would you prefer someone else to NMU it with this > change? I was at DebConf in Canada, so I was busy meeting people :-). It should be done before or after flying back home. \_o< signature.asc Description: OpenPGP digital signature
Bug#868150: imapproxy: fails to start
Quack, On 08/08/2017 02:12 PM, Richard Laager wrote: > I have prepared the changes and submitted the required bug for > stable-proposed-updates here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871451 > > I assume I need to hear some sort of ACK on that bug before I (ask my > sponsor to) upload. I was in DebConf in Canada and going back home tomorrow. I cannot build for stable now and check your patch, but will be able to do so at the end of the week. \_o< signature.asc Description: OpenPGP digital signature
Bug#870253: clamav-milter: disengaging debconf management destroys config
Package: clamav-milter Version: 0.99.2+dfsg-6+b1 Severity: serious Quack, I configured this package using debconf and it worked nicely. I then wanted to handle the file via configuration management and to do so I disengaged debconf, replying "no" to the question "Handle the configuration file automatically?" when doing a dpkg-reconfigure. The resulting message was: Replacing config file /etc/clamav/clamav-milter.conf with new version The configuration file previously created via debconf was simply replaced without any backup, so all my config was lost (thanks backup). In accordance with the Debian Policy a package should not destroy user's config. In this case the headers saying this file is managed automatically should be removed but the configuration directives be preserved. You may also give a choice via a debconf question. Regards. -- Marc Dequènes
Bug#868956: libmspack: CVE-2017-11423
Quack, I added libmspack's upstream author in case he could give a hand. Here is the bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868956 On 2017-07-20 05:15, Salvatore Bonaccorso wrote: Unfortunately the upstream bug [1] is locked-down. Thanks for reporting it. Unfortunately I don't see how I can solve this problem. If all information are hidden on a related but not upstream bug tracker (which really should have one), if there's no patch or new release either, then I'm honestly at a loss. If I happen to create an account on the ClamAV's bug tracker, would you be able to give me access? Regards. \_o< -- Marc Dequènes
Bug#868150: imapproxy: fails to start
Quack, On 2017-07-16 16:00, Richard Laager wrote: From my first testing, it worked fine without PIDFile. Unfortunately, upon further testing, it seems to fail most of the time. Given that those errors seem harmless, I think setting PIDFile is the lesser of the two evils right now, so I'm sticking with that. I've sent the update to my sponsor. (I'm not a DD.) I've never configured a Type=forking service, so I guess I lack some knowledge. Looks like a race condition but I'm not sure. I should probably explore the idea of adding a command-line option to imapproxy that sets foreground_mode. Then, I can use that in the systemd unit, making this Type=simple instead of Type=forking. That could be useful anyway for debugging, so I think it's a good idea. Thanks for your upload :-). Nevertheless it doe not solve my problem yet because my service is on stable. I think it's important enough to ask for an upload to stable-proposed-updates. Please look at the procedure before uploading. \_o< -- Marc Dequènes
Bug#868150: imapproxy: fails to start
On 2017-07-14 12:56, Richard Laager wrote: Is the PIDFile line actually necessary for you? Can you re-test without the PIDFile line in the service? « There is indeed not [Install] section. If I add one with "WantedBy=multi-user.target" I can enable the service but still it does not start properly. » So no. I added it because I looked at the service configuration differences with other similar forking daemons and this was the only obvious one. With it everything works well without warning here. With that line, I get additional errors/warnings. Without it, systemd is still able to detect the main PID of the process. Could you paste the relevant logs? \_o< -- Marc Dequènes
Bug#868150: imapproxy: fails to start
Quack, On 2017-07-13 14:40, Richard Laager wrote: Does it still work for you with /var/run instead of /run? Please use /run, it's officially in use and the goal is to transition *to* it: https://wiki.debian.org/ReleaseGoals/RunDirectory So better would be to change the path where the pidfile is created, but you can do this when you have time. [ Marc Dequènes ] * Correct the service file (Closes: 868150) This notation is used when multiple co-maintainers contribute to the save version. Or I can let the git author default to me and just credit you textually in the commit message. Search the word "Thanks" in /usr/share/doc/dpkg/changelog.Debian.gz for plenty of examples. Also please use "Marc Dequènes (Duck)". Do you have a preference? Are you okay with "Correct the service file" or would you like to provide your own commit message for that patch? That's fine. Thanks for your prompt reply :-). \_o< -- Marc Dequènes
Bug#868150: imapproxy: fails to start
Package: imapproxy Version: 1.2.8~svn20161210-2 Severity: grave Quack, The server does not start. Trying to restart it does not change anything. Here is the systemd status: # systemctl status imapproxy ● imapproxy.service - IMAP proxy Loaded: loaded (/lib/systemd/system/imapproxy.service; static; vendor preset: enabled) Active: inactive (dead) Docs: man:imapproxyd(8) Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: main(): Internal admin commands are disabled Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: main(): Allocating 3072 IMAP connection structures. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: main(): Enabling openssl library. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: Initialising 1 pthread_mutexes Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ServerInit(): Using '/var/log/imapproxy_protocol.log' for global protocol logging file. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ServerInit(): proxying to IMAP server 'localhost'. Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ServerInit(): Proxying to IMAP port 143 Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: ParseBannerAndCapability: Attempting to parse capability string: * OK [CAPABILITY IMAP4rev1 LITERAL+ SA Jul 12 14:32:49 Orfeo in.imapproxyd[18803]: [238B blob data] Jul 12 14:32:49 Orfeo systemd[1]: Started IMAP proxy. The service is marked as "static", which is wrong in this case IIUC. Interestingly: # systemctl enable imapproxy Synchronizing state of imapproxy.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install enable imapproxy The unit files have no installation config (WantedBy, RequiredBy, Also, Alias settings in the [Install] section, and DefaultInstance for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). 4) In case of template units, the unit is meant to be enabled with some instance name specified. There is indeed not [Install] section. If I add one with "WantedBy=multi-user.target" I can enable the service but still it does not start properly. But if I use the init script directly it starts fine (and the service works fine too, so the config is all right): # /etc/init.d/imapproxy start Starting imapproxy (via systemctl): imapproxy.service. # /etc/init.d/imapproxy status ● imapproxy.service - IMAP proxy Loaded: loaded (/lib/systemd/system/imapproxy.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2017-07-12 14:40:25 CEST; 2min 37s ago Docs: man:imapproxyd(8) Process: 19772 ExecStart=/usr/sbin/imapproxyd -f /etc/imapproxy.conf (code=exited, status=0/SUCCESS) Process: 19766 ExecStartPre=/usr/share/imapproxy/prepare-chroot (code=exited, status=0/SUCCESS) Main PID: 19776 (imapproxyd) Tasks: 2 (limit: 4915) Memory: 1.6M CPU: 19ms CGroup: /system.slice/imapproxy.service └─19776 /usr/sbin/imapproxyd -f /etc/imapproxy.conf Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: ServerInit(): proxying to IMAP server 'localhost'. Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: ServerInit(): Proxying to IMAP port 143 Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: ParseBannerAndCapability: Attempting to parse capability string: * OK [CAPABILITY IMAP4rev1 …cot ready. Jul 12 14:40:25 Orfeo in.imapproxyd[19772]: [238B blob data] Jul 12 14:40:25 Orfeo systemd[1]: Started IMAP proxy. Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: BecomeNonRoot(): Process will run as uid 65534 (nobody) and gid 65534 (nogroup). Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: BecomeNonRoot(): Process chrooted in /var/lib/imapproxy/chroot Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: BecomeNonRoot(): enabled no_new_privs Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: main(): Launched ICC recycle thread with id 140509281154816 Jul 12 14:40:25 Orfeo in.imapproxyd[19776]: main(): imapproxy version 1.2.8 [SVN] normal server startup. Hint: Some lines were ellipsized, use -l to show in full. In the end, with the following patch it works fine: --- imapproxy.service.orig
Bug#746005: Problems in Lilipond and Guile -- #746005
Quack, I think the release team should have been involved much much earlier. It seems having Lilypond working with recent Guile before the release is not going to happen. Even if it built properly there would maybe have runtime bugs to solve. If people are willing to maintain Guile 1.8 into stable during another release lifetime, I guess the release team would be ok with it. Maybe it would be possible to provide a backport of Guile 2.x and newer Lilypond later (when it works) and drop Guile 1.8 and current Lilypond from stable in a subsequent point release. This could be announced in the release notes from the start, so no surprise. Anyway, I'm Cc-ing the release team so they don't discover the problem much later. \_o< -- Marc Dequènes
Bug#829175: Missing dependency on ruby-pkg-config
Package: ruby-nokogiri Version: 1.6.8-1 Severity: serious Quack, - $ vagrant up Vagrant experienced a version conflict with some installed plugins! This usually happens if you recently upgraded Vagrant. As part of the upgrade process, some existing plugins are no longer compatible with this version of Vagrant. The recommended way to fix this is to remove your existing plugins and reinstall them one-by-one. To remove all plugins: rm -r ~/.vagrant.d/plugins.json ~/.vagrant.d/gems Note if you have an alternate VAGRANT_HOME environmental variable set, the folders above will be in that directory rather than your user's home directory. The error message is shown below: Bundler could not find compatible versions for gem "pkg-config": In Gemfile: vagrant (= 1.8.4) was resolved to 1.8.4, which depends on nokogiri was resolved to 1.6.8, which depends on pkg-config (~> 1.1.7) Could not find gem 'pkg-config (~> 1.1.7)', which is required by gem 'nokogiri', in any of the sources. - Indeed installing ruby-pkg-config solves the problem. You can see the runtime dep in: /usr/share/rubygems-integration/2.3.0/specifications/nokogiri-1.6.8.gemspec but the package lacks it. \_o<
Bug#819815: stable upgrade from 3.0~20140825-5 to 3.0~20140825-8~deb8u2 failed
Package: redmine Version: 3.0~20140825-8~deb8u2 Severity: serious Quack, Migration fails with: === Setting up redmine (3.0~20140825-8~deb8u2) ... Please configure your config/database.yml first Populating database for redmine instance "dc". This may take a while. Please configure your config/database.yml first Please configure your config/database.yml first rake aborted! Gem::LoadError: Specified 'mysql2' for database adapter, but the gem is not loaded. Add `gem 'mysql2'` to your Gemfile (and ensure its version is at the minimum required by ActiveRecord). Gem::LoadError: mysql2 is not part of the bundle. Add it to Gemfile. Tasks: TOP => db:migrate => environment (See full trace by running task with --trace) Error when running rake db:migrate, check database configuration. dpkg: error processing package redmine (--configure): subprocess installed post-installation script returned error exit status 1 === After investigation, the postinst properly loops on my redmine/current-instances, so this is well, but unfortunately the new magical Gemfile is not passed the instance name, thus using "default" as default instance name. In my case I don't have a "default" instance (which is permitted via debconf), but anyway each instance could have a different adapter so this will fail in some non-exotic configurations. So it seems a different Gemfile.lock should probably be generated for each instance, with the X_DEBIAN_SITEID set by the postinst. Or maybe if there is no possible conflict have the Gemfile loop on all database config files and load all necessary adapters. Regards. -- Marc Dequènes
Bug#817011: ruby-domain-name: missing RubyGems integration, breaks other softwares like Vagrant
Package: ruby-domain-name Version: 0.5.20160216-1 Severity: grave Quack, I just installed Vagrant and got the trace you can find later in this message. After some investigation I found your package does not provide any gemspec file and tried to create a basic one like this in '/usr/share/rubygems-integration/all/specifications/domain_name-0.5.20160216.gemspec': Gem::Specification.new do |s| s.name = "domain_name" s.version = "0.5.20160216" end It fixed the problem. I'm in the team but I don't have time or tools at the moment to get into more details why this file is missing (I remember gem2deb to already have all the necessary magic and this package is using it), sorry. Regards. - $ vagrant Vagrant experienced a version conflict with some installed plugins! This usually happens if you recently upgraded Vagrant. As part of the upgrade process, some existing plugins are no longer compatible with this version of Vagrant. The recommended way to fix this is to remove your existing plugins and reinstall them one-by-one. To remove all plugins: rm -r ~/.vagrant.d/plugins.json ~/.vagrant.d/gems Note if you have an alternate VAGRANT_HOME environmental variable set, the folders above will be in that directory rather than your user's home directory. The error message is shown below: Bundler could not find compatible versions for gem "domain_name": In Gemfile: vagrant (= 1.8.1) was resolved to 1.8.1, which depends on rest-client (< 2.0, >= 1.6.0) was resolved to 1.8.0, which depends on http-cookie (< 2.0, >= 1.0.2) was resolved to 1.0.2, which depends on domain_name (~> 0.5) Could not find gem 'domain_name (~> 0.5)', which is required by gem 'http-cookie (< 2.0, >= 1.0.2)', in any of the sources. -- Marc Dequènes
Bug#803204: libiksemel: utterly insecure GNUTLS settings
Coin, On 2015-11-12 11:04, Simon Josefsson wrote: I would suggest to use gnutls_set_default_priority() instead of hard-coding a priority string into applications. Your hard coded priority string will be just as obsolete as the hard coded values you are replacing in a couple of years. You're right, this is a better way to setup priorities. Please see my patch as an urgent fix only. I asked the maintainer to review it as he should have more experience than me. Besides, when I made this patch I had the user setup in mind: the library could (and should) easily accept a string from the caller software in order to allow different restrictions if the user wishes so (and fallback to your suggestion if not provided). I also think upstream should be contacted, not sure it was done. I can't see a stable upload coming either. Regards. -- Marc Dequènes
Bug#803204: libiksemel: utterly insecure GNUTLS settings
Package: libiksemel
Version: 1.4-2
Severity: grave
tags: security
Control: affects -1 = zabbix-server-pgsql zabbix-server-mysql
Coin,
Since I changed my XMPP server, Zabbix failed to send alerts via XMPP
with "tls handshake failed". The XMPP server said "no shared cipher".
After some research to see how Zabbix do its job I ended up into this
library. I confirmed there is no way to setup the ciphers into Zabbix,
but I was then astonished to see them hardcoded and very low grade in
libiksemel:
const int protocol_priority[] = { GNUTLS_TLS1, GNUTLS_SSL3, 0 };
const int kx_priority[] = { GNUTLS_KX_RSA, 0 };
const int cipher_priority[] = { GNUTLS_CIPHER_3DES_CBC,
GNUTLS_CIPHER_ARCFOUR, 0};
const int comp_priority[] = { GNUTLS_COMP_ZLIB, GNUTLS_COMP_NULL,
0 };
const int mac_priority[] = { GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, 0 };
SSL3, 3DES, RC4, SSL compression… With this setting not only low grade
ciphers are available, but higher grades are disabled. So this is a
major security issue, also affecting stable.
The following patch fixes the security problem (and compatibility
problem with servers rejecting low grade ciphers). You should
nevertheless proofread my choices, as I'm no security expert. The patch
does not change the original priority lists because I failed somehow to
fix them all, so I replaced it by a priority string (which is a
non-obsolete method to do it anyway).
Regards.
--
Marc DequènesIndex: libiksemel-1.4/src/stream.c
===
--- libiksemel-1.4.orig/src/stream.c
+++ libiksemel-1.4/src/stream.c
@@ -63,11 +63,7 @@ tls_pull (iksparser *prs, char *buffer,
static int
handshake (struct stream_data *data)
{
- const int protocol_priority[] = { GNUTLS_TLS1, GNUTLS_SSL3, 0 };
- const int kx_priority[] = { GNUTLS_KX_RSA, 0 };
- const int cipher_priority[] = { GNUTLS_CIPHER_3DES_CBC, GNUTLS_CIPHER_ARCFOUR, 0};
- const int comp_priority[] = { GNUTLS_COMP_ZLIB, GNUTLS_COMP_NULL, 0 };
- const int mac_priority[] = { GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, 0 };
+ const char *priority_string = "SECURE256:+SECURE192:-VERS-TLS-ALL:+VERS-TLS1.2";
int ret;
if (gnutls_global_init () != 0)
@@ -80,11 +76,7 @@ handshake (struct stream_data *data)
gnutls_certificate_free_credentials (data->cred);
return IKS_NOMEM;
}
- gnutls_protocol_set_priority (data->sess, protocol_priority);
- gnutls_cipher_set_priority(data->sess, cipher_priority);
- gnutls_compression_set_priority(data->sess, comp_priority);
- gnutls_kx_set_priority(data->sess, kx_priority);
- gnutls_mac_set_priority(data->sess, mac_priority);
+ gnutls_priority_set_direct(data->sess, priority_string, NULL);
gnutls_credentials_set (data->sess, GNUTLS_CRD_CERTIFICATE, data->cred);
gnutls_transport_set_push_function (data->sess, (gnutls_push_func) tls_push);
Bug#778099: ratbox-services: diff for NMU version 1.2.4+repack-2.1
Coin, On 2015-07-24 00:01, gregor herrmann wrote: I've prepared an NMU for ratbox-services (versioned as 1.2.4+repack-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. That's very kind of you. I delayed this work because I needed a take a decision about the future of this package, and that's now done (see #793408). If you feel I'm wrong or you really like this piece of software, then feel free to adopt it :-). Regards. -- Marc Dequènes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773041: Bug#773318: clamav dies/hangs
Control: tag 773041 + pending Coin, Thanks a lot Andreas. Have a pleasant end of year time. -- Marc Dequènes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773041: Bug#773318: clamav dies/hangs
Coin, On 2014-12-21 22:16, Sebastian Andrzej Siewior wrote: On 2014-12-20 12:12:13 [+0100], Andreas Cadhalpun wrote: As it shows that clamd hangs in libmspack, I think this is bug #773041 [1]. A possible fix is mentioned in [2]. I can upload this simple fix quickly, nevertheless i did not have time to proofread it. Any comment? Is the security team aware of the various in-tree copy of this library? #67 tries / tried to track them. Joss filled #675560 tagged security. I tested the cabextract build using the library but had no reply. I wanted to have at least one real user for the lib before pinging the other related packages. I should probably have been more aggressive on this front, my bad. Regards. -- Marc Dequènes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768841: libgnutls-deb0-28: SIGABRT when loading certificates
Coin, Quoting Andreas Metzler ametz...@bebt.de: Could you check whether upgrading to 3.3.10 (just uploaded to experimental) fixes the issues you reported, too? You're right, this fixed the problem for both minbif and ircd-ratbox. PS: Looking at https://www.debian.org/Bugs/Developer.en.html#severities this seems to match a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone which would be important, not grave. I disagree. When a bug breaks other packages, this is clearly unsuitable for release and ought to be RC. It can't be critical as it does not break unrelated softwares […]. It can't be serious as it is not a matter of policy. For a library, which only use is to provide functions to other programs, to cause crashes to many rdeps is in my opinion being unusable or mostly so. Well, thanks for your help. I think the next step is ensuring this fix enters Jessie. 3.3.10 does not seem to add more than a few fixes (which at first glance seem important). It could be reasonable to discuss an unblock with the RT. Regards. -- Marc Dequènes (Duck) pgpGJk8aqjXk9.pgp Description: PGP Digital Signature
Bug#768841: libgnutls-deb0-28: SIGABRT when loading certificates
Package: libgnutls-deb0-28
Version: 3.3.8-3
Severity: grave
Justification: breaks related softwares (minbif, ircd-ratbox)
Control: affects -1 = minbif ircd-ratbox
Coin,
I had to update all my certificates because our CA is going to expire
soon. I then restarted all services with the new CA and server
certificates and it worked for all services but minbif and ircd-ratbox
(probably the only ones using gnutls). minbif fork for each connecting
user and the new process crash ; see the strace and gdb trace
attached. I was not able yet to get a core for ircd-ratbox but the
strace is similar.
Reverting the certificates (which are still valid until the end of the
month) did not help. Downgrading gnutls to 3.3.8-2 (before the rusage
patch) did not help either.
I find two things disturbing. First, fd 3 is used to read the public
key, closed, but then read again which fails and the abort is done
shortly afterwards. Second, rnd_func() fails like if there was no
entropy available, but /proc/sys/kernel/random/entropy_avail proves it
wrong (the machine has a hardware generator with rngd).
As for the timing, i uploaded ircd-ratbox on 2014-07-29 which worked
perfectly on the testing suite at that time (after a gnutls 3 patch).
Tell me if you need anything tested and thanks for your help.
Regards.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages libgnutls-deb0-28 depends on:
ii libc6 2.19-12
ii libgmp10 2:6.0.0+dfsg-4
ii libhogweed22.7.1-3
ii libnettle4 2.7.1-3
ii libp11-kit00.20.7-1
ii libtasn1-6 4.1-1
ii multiarch-support 2.19-12
ii zlib1g 1:1.2.8.dfsg-1
--
Marc Dequènes (Duck)
#0 0x7f9727650107 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 28099
selftid = 28099
#1 0x7f97276514e8 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x1631eb0, sa_sigaction =
0x1631eb0}, sa_mask = {__val = {140733327892112, 140733327890224,
140287214206471, 1, 0, 0, 140287177530664, 23280608, 140733327890224, 23290456,
140287214232357, 4294966954, 0, 23264720, 0, 0}}, sa_flags = 0, sa_restorer =
0x161a220}
sigs = {__val = {32, 0 repeats 15 times}}
#2 0x7f9728009199 in rnd_func (_ctx=0x0, length=264, data=0x7fff08045740
) at pk.c:62
No locals.
#3 0x7f97238cd346 in nettle_mpz_random_size (x=0x7fff08045910, ctx=0x0,
random=0x7f9728009169 rnd_func, bits=2112) at bignum-random.c:44
length = 264
data = 0x7fff08045740
#4 0x7f97238cd3d1 in nettle_mpz_random (x=0x7fff08045910, ctx=0x0,
random=0x7f9728009169 rnd_func, n=0x7fff08045a48) at bignum-random.c:81
No locals.
#5 0x7f97238d024a in _nettle_rsa_blind (pub=0x7fff08045a40,
random_ctx=0x0, random=0x7f9728009169 rnd_func, c=0x7fff08045a30,
ri=0x7fff08045980) at rsa-blind.c:50
r = {{_mp_alloc = 1, _mp_size = 0, _mp_d = 0x161a400}}
#6 0x7f97238cedbd in nettle_rsa_pkcs1_sign_tr (pub=0x7fff08045a40,
key=0x7fff08045a70, random_ctx=0x0, random=0x7f9728009169 rnd_func,
length=51, digest_info=0x1638500 010\r\006\t`\206H\001e\003\004\002\001\005,
s=0x7fff08045a30) at rsa-pkcs1-sign-tr.c:47
ri = {{_mp_alloc = 1, _mp_size = 0, _mp_d = 0x161a310}}
#7 0x7f972800a997 in _wrap_nettle_pk_sign (algo=GNUTLS_PK_RSA,
signature=0x7fff08045bf0, vdata=0x7fff08045b80, pk_params=0x1644680) at pk.c:566
priv = {size = 256, d = {{_mp_alloc = 33, _mp_size = 32, _mp_d =
0x1639180}}, p = {{_mp_alloc = 17, _mp_size = 16, _mp_d = 0x1639320}}, q =
{{_mp_alloc = 17, _mp_size = 16, _mp_d = 0x1638a10}}, a = {{_mp_alloc = 16,
_mp_size = 16, _mp_d = 0x16398d0}}, b = {{_mp_alloc = 16, _mp_size = 16, _mp_d
= 0x1639960}}, c = {{_mp_alloc = 17, _mp_size = 16, _mp_d = 0x1638aa0}}}
pub = {size = 256, n = {{_mp_alloc = 33, _mp_size = 32, _mp_d =
0x1639070}}, e = {{_mp_alloc = 1, _mp_size = 1, _mp_d = 0x1616800}}}
s = {{_mp_alloc = 32, _mp_size = 32, _mp_d = 0x1639e40}}
ret = 134502912
hash_len = 32767
me = 0x7f9723d44e5a
#8 0x7f9727f4176c in gnutls_privkey_sign_raw_data (key=0x1645860, flags=0,
data=0x7fff08045b80, signature=0x7fff08045bf0) at gnutls_privkey.c:909
No locals.
#9 0x7f9727f4147c in gnutls_privkey_sign_data (signer=0x1645860,
hash=GNUTLS_DIG_SHA256, flags=0, data=0x7fff08045be0, signature=0x7fff08045bf0)
at gnutls_privkey.c:788
ret = 0
digest = {data = 0x1638500
010\r\006\t`\206H\001e\003\004\002\001\005, size = 51}
me = 0x7f972824b360 hash_algorithms+96
#10 0x7f9727f2d4ad in _gnutls_check_key_cert_match (res=0x16350e0) at
gnutls_cert.c:936
test = {data
Bug#761517: calibre: Crashes at startup on sip_api_can_convert_to_type
Package: calibre Version: 2.2.0+dfsg-2 Severity: grave Justification: renders package unusable Coin, I just upgraded calibre from 1.48.0+dfsg-1 which worked pretty well, but this new version does not start: $ calibre python2.7: /tmp/buildd/sip4-4.16.3+dfsg/siplib/siplib.c:8514: sip_api_can_convert_to_type: Assertion `(((td)-td_flags 0x0007) == 0x) || (((td)-td_flags 0x0007) == 0x0002)' failed. Aborted In the meanwhile python-sip upgraded from 4.16.2+dfsg-1 to 4.16.3+dfsg-1, nevertheless reverting did not help at all. Regards. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-1-amd64 (SMP w/8 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 calibre depends on: ii calibre-bin2.2.0+dfsg-2 ii fonts-liberation 1.07.4-1 ii imagemagick8:6.8.9.6-4 ii libjs-mathjax 2.4-1 ii poppler-utils 0.26.4-1 ii python-apsw3.8.6-r1-1 ii python-beautifulsoup 3.2.1-1 ii python-chardet 2.2.1-2 ii python-cherrypy3 3.5.0-1 ii python-cssselect 0.9.1-1 ii python-cssutils0.9.10-1 ii python-dateutil1.5+dfsg-1 ii python-dbus1.2.0-2+b3 ii python-feedparser 5.1.3-2 ii python-imaging 2.5.3-1 ii python-lxml3.4.0-1 ii python-markdown2.4.1-1 ii python-mechanize 1:0.2.5-3 ii python-netifaces 0.10.4-0.1 ii python-pil 2.5.3-1 ii python-pkg-resources 5.5.1-1 ii python-pyparsing 2.0.2+dfsg1-1 ii python-pyqt5 5.3.2+dfsg-1 ii python-pyqt5.qtsvg 5.3.2+dfsg-1 ii python-pyqt5.qtwebkit 5.3.2+dfsg-1 ii python-routes 2.0-1 ii python2.7 2.7.8-7 ii xdg-utils 1.1.0~rc1+git20111210-7.1 Versions of packages calibre recommends: ii python-dnspython 1.11.1-1 calibre suggests no packages. -- no debconf information -- Marc Dequènes (Duck) pgpvqSxB7uXgK.pgp Description: PGP Digital Signature
Bug#758814: php-horde-editor: editor unusable due to broken symlink
Package: php-horde-editor Version: 2.0.4+debian0-1 Severity: grave Coin, This symlink is broken: /usr/share/horde/js/ckeditor/ckeditor_basic.js - ../../../javascript/ckeditor/ckeditor_basic.js The ckeditor package only provides: /usr/share/javascript/ckeditor/ckeditor.js Regards. -- Marc Dequènes (Duck) pgpIZHljiZr5m.pgp Description: PGP Digital Signature
Bug#758814: Acknowledgement (php-horde-editor: editor unusable due to broken symlink)
Coin, Btw, you also need to symlink ../../../javascript/ckeditor/styles.js And to be proper you can remove the now useless 'themes' symlink. Regards. -- Marc Dequènes (Duck) pgpi3yTcuUtNV.pgp Description: PGP Digital Signature
Bug#743671: Building extensions breaks resulting packages
Package: libruby2.1 Version: 2.1.1-2 Severity: grave Control: block 743664 with -1 Coin, Building extensions leaves mkmf.log files in weird places since 2.1, see #743664. I though the problem was in mkmf.rb which had changed a bit since 2.0 but after investigation it appears to be a change in rubygems/ext/ext_conf_builder.rb: 39c37,41 run cmd, results --- begin run cmd, results ensure FileUtils.mv 'mkmf.log', dest_path if File.exist? 'mkmf.log' end Commenting FileUtils.mv fixed this issue. I honestly don't understand the reason for moving the log file at all. Thanks Mr KiBi for his help :-). Regards. -- Marc Dequènes (Duck) pgpjwU0_szBm9.pgp Description: PGP Digital Signature
Bug#742423: wine-unstable is *still* unusable
Quoting Marc Dequènes (Duck) d...@duckcorp.org: You closed #742021 and #742317 in a hurry, but the logic in /usr/bin/wine-unstable is to look for the real 32/64 binaries in the same directory while you moved them into /usr/lib/wine-unstable/, thus your package is unusable. Broken analysis due to a workaround. Here is the trace of the current problem: $ winecfg + basename /usr/bin/winecfg .exe + appname=winecfg.exe + test -z + test ! -z + WINEPREFIX=/home/duck/.wine + test -e /home/duck/.wine/system.reg + wine=/usr/bin/wine + exec /usr/bin/wine winecfg.exe /usr/bin/winecfg: 36: exec: /usr/bin/wine: not found I'm not using wine directly but through playonlinux, thus there is no trace of me using wine-unstable in any reg file, this is a broken assumption. Btw you also broke using playonlinux or other tools around because they all expect a wine binary and not wine-unstable. Unless there is an alternative mechanism for choosing the default version i think using wine-unstable remains unusable (but using an alternative would probably break your current logic). -- Marc Dequènes (Duck) pgpxGTIDekmS9.pgp Description: PGP Digital Signature
Bug#742317: missing 'wine' binary in several architecture
Package: wine-unstable Version: 1.7.14-4 Severity: critical Coin, /usr/bin/wine is missing from wine-unstable in the following architectures: - i386 - kfreebsd-amd64 which means your package is unusable on this architectures. Regards. -- Marc Dequènes (Duck) pgpovX_Gwwuhr.pgp Description: PGP Digital Signature
Bug#742021: misnamed binaries, unusable
Package: wine-unstable Version: 1.7.14-4 Severity: grave Coin, /usr/bin/wine, provided by wine-unstable is looking for: wine=/usr/lib/wine-unstable/wine-unstable wine64=/usr/lib/wine-unstable/wine64-unstable Unfortunately there are no such files, see: https://packages.debian.org/sid/i386/wine32-unstable/filelist https://packages.debian.org/sid/amd64/wine64-unstable/filelist (the -unstable suffix is missing) Maybe you should test your packages a bit more before uploading… -- 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.13-1-amd64 (SMP w/8 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 wine-unstable depends on: ii file 1:5.17-1 ii wine32-unstable 1.7.14-4 wine-unstable recommends no packages. Versions of packages wine-unstable suggests: ii binfmt-support 2.1.3-2 ii clamav 0.98.1+dfsg-4 ii ttf-mscorefonts-installer 3.5 pn winbindnone pn wine-doc none -- no debconf information -- Marc Dequènes (Duck) pgpYdZKViPReK.pgp Description: PGP Digital Signature
Bug#739789: causes Apache segfaults
Package: php5-xcache Version: 3.1.0-1 Severity: grave Justification: package partially unusable, breaking (related) softwares Tags: upstream Coin, Recently i experienced blank pages on Horde on specific pages, and went down to find an Apache segfault. After some investigation, it appears xache is the culprit (see below). Deactivating the following Horde specific xcache features did not help: $conf['cache']['driver'] = 'Xcache'; $conf['cache']['use_memorycache'] = 'Xcache'; The only way to fix it was to disable xcache completely. On another machine i also experienced such kind of crashes when using other softwares (dotclear for examples) and deactivating xache fixed the problem. I made a trace on the machine where i found the problem first, which is attached. Regards. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages php5-xcache depends on: ii dpkg 1.17.6 ii libc6 2.17-97 ii php5-common [phpapi-20121212] 5.5.8+dfsg-3 php5-xcache recommends no packages. php5-xcache suggests no packages. -- Configuration Files: /etc/php5/mods-available/xcache.ini changed: ; configuration for php Xcache module [xcache-common] ;; non-Windows example: extension = xcache.so ;; Windows example: ; extension = php_xcache.dll [xcache.admin] ; Duck: conflicts with vhost access control xcache.admin.enable_auth = Off ; Configure this to use admin pages xcache.admin.user = user xcache.admin.pass = password ; xcache.admin.pass = md5($your_password) ; xcache.admin.pass = [xcache] ; ini only settings, all the values here is default unless explained ; select low level shm implemenation xcache.shm_scheme =mmap ; to disable: xcache.size=0 ; to enable : xcache.size=64M etc (any size 0) and your system mmap allows xcache.size = 64M ; set to cpu count (cat /proc/cpuinfo |grep -c processor) xcache.count = 2 ; just a hash hints, you can always store count(items) slots xcache.slots =8K ; ttl of the cache item, 0=forever xcache.ttl = 0 ; interval of gc scanning expired items, 0=no scan, other values is in seconds xcache.gc_interval = 0 ; same as aboves but for variable cache xcache.var_size =2M xcache.var_count = 2 xcache.var_slots =8K ; default value for $ttl parameter of xcache_*() functions xcache.var_ttl = 0 ; hard limit ttl that cannot be exceed by xcache_*() functions. 0=unlimited xcache.var_maxttl = 0 xcache.var_gc_interval = 300 ; mode:0, const string specified by xcache.var_namespace ; mode:1, $_SERVER[xcache.var_namespace] ; mode:2, uid or gid (specified by xcache.var_namespace) xcache.var_namespace_mode =0 xcache.var_namespace = ; N/A for /dev/zero xcache.readonly_protection = Off ; for *nix, xcache.mmap_path is a file path, not directory. (auto create/overwrite) ; Use something like /tmp/xcache instead of /dev/* if you want to turn on ReadonlyProtecti$ ; different process group of php won't share the same /tmp/xcache ; for win32, xcache.mmap_path=anonymous map name, not file path xcache.mmap_path =/dev/zero ; Useful when XCache crash. leave it blank(disabled) or /tmp/phpcore/ (writable by php) xcache.coredump_directory = ; Windows only. leave it as 0 (default) until you're told by XCache dev xcache.coredump_type = 0 ; disable cache after crash xcache.disable_on_crash =Off ; enable experimental documented features for each release if available xcache.experimental =Off ; per request settings. can ini_set, .htaccess etc xcache.cacher = On xcache.stat = On xcache.optimizer =On [xcache.coverager] ; enabling this feature will impact performance ; enabled only if xcache.coverager == On xcache.coveragedump_directory == non-empty-value ; per request settings. can ini_set, .htaccess etc ; enable coverage data collecting and xcache_coverager_start/stop/get/clean() functions xcache.coverager = Off xcache.coverager_autostart = On ; set in php ini file only ; make sure it's readable (open_basedir is checked) by coverage viewer script xcache.coveragedump_directory = -- no debconf information -- Marc Dequènes (Duck) #0 0x7f37b8d5007a in zend_hash_find (ht=0x7fff08010128, arKey=0x7f37a1506570 init, nKeyLength=5, pData=0x7fff14826a70) at /tmp/buildd/php5-5.5.8+dfsg/Zend/zend_hash.c:924 h = 210716142681 nIndex = error reading variable nIndex (Cannot access memory at address 0x7fff0801012c) p = optimized out #1 0x7f37a800f4ec in xc_restore_zend_op_array (processor=0x7fff14826c20, dst=0x7f37c22dff60, src=0x7f37a1562038
Bug#733576: phpldapadmin: broken with recent PHP
Package: phpldapadmin Version: 1.2.2-5 Severity: grave Coin, It fails with the following error: Fatal error: Cannot redeclare password_hash() in /usr/share/phpldapadmin/lib/functions.php on line 2225 This function was added in core PHP since 5.5.0. Regards. -- Marc Dequènes (Duck) pgpKxCHwQ_lNK.pgp Description: PGP Digital Signature
Bug#730488: dicoweb: broken with Django 1.4
Package: dicoweb
Version: 2.2-3
Severity: grave
With recent Django versions in Debian, dicoweb is broken.
I spotted the following problems which can be solved easily to have a
working version:
1) new-style 'url' tag (see
https://docs.djangoproject.com/en/1.5/releases/1.5/)
fix in /etc/dicoweb/templates/base.html by quoting the route name ({%
url opensearch %})
2) « ImproperlyConfigured: If set, MEDIA_URL must end with a slash »
/etc/dicoweb/settings.py needs to be fixed
3) django.conf.urls.defaults is deprecated, use django.conf.urls
/usr/share/dicoweb/urls.py needs to be fixed
Nevertheless, having a program also working on older versions would
need more work.
Regards.
--
Marc Dequènes (Duck)
pgpY5Ab4v4uyk.pgp
Description: PGP Digital Signature
Bug#730488: dicoweb: broken with Django 1.4
Quoting أحمد المحمودي aelmahmo...@sabily.org:
href={% url 'opensearch' %}
quoting, single or double (i used double in my tests).
MEDIA_URL = 'static/' ?
yes
Sorry i had no time to prepare a proper patch.
Nevertheless, having a program also working on older versions would
need more work.
Please clarify what you mean here.
I guess upstream would be willing to have conditionals in order to
support newer and older Django versions with the same code, thus a
basic patch is ok for Debian and as example, but they may have
additional work.
Regards.
--
Marc Dequènes (Duck)
pgpMsl4ay3f6O.pgp
Description: PGP Digital Signature
Bug#717312: pymsnt upload/sponsorship
Coin, Quoting Sam Morris s...@robots.org.uk: Can you make the necessary change? You've been handling this package as DM since a while, and i've been using it since a while without major problems too, so i see no reason no to reinstate your upload rights. Changes done. Nevertheless, if you need a review before upload, now or in the future, you can contact me. Regards. -- Marc Dequènes (Duck) pgpPwL1WuOUig.pgp Description: PGP Digital Signature
Bug#708863: GFDL with invariant section
Control: tags -1 + squeeze wheezy Coin This problem already has been fixed upstream and 2.2 in unstable is unaffected. We (the maintainer and me as sponsor) are discussing the matter with upstream authors to see what can be done about it. Regards. -- Marc Dequènes (Duck) pgpCsSC7OlhXX.pgp Description: PGP Digital Signature
Bug#717312: not really pending
Control: tags 717312 - pending Coin, Pending means a new upload is to be done in days not months. The provided patch is working, so i don't see any reason to delay. Do you need any help with this package? Regards. -- Marc Dequènes (Duck) pgpoWgdelOuHQ.pgp Description: PGP Digital Signature
Bug#721091: ruby-feedtools: does not work with Ruby 1.9
Coin, Quoting Antonio Terceiro terce...@debian.org: ruby-feedtools has no reverse dependencies, and judging by this bug not being reported before, no users. It also seems to be stalled upstream since Debian already has the latest upstream version: http://pkg-ruby-extras.alioth.debian.org/cgi-bin/gemwatch/feedtools That's sad :-(. I don't even remember why i packaged it in the first place. I guess ruby-feedparser or yapra can do the job fine. Maybe having 3 feed-oriented libraries was too much. Maybe we should remove it from the archive? Will do. Thanks for your time. Regards. -- Marc Dequènes (Duck) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714164: fontconfig-config: fails to purge
Package: fontconfig-config Version: 2.10.2-1 Severity: serious Coin, Installing 2.10.2-1 and purging it fails: … Selecting previously unselected package fontconfig-config. Unpacking fontconfig-config (from .../fontconfig-config_2.10.2-1_all.deb) ... … Setting up fontconfig-config (2.10.2-1) ... … Removing fontconfig-config ... rm: cannot remove '/etc/fonts/conf.avail': Is a directory dpkg: error processing fontconfig-config (--purge): subprocess installed post-removal script returned error exit status 1 Regards. -- Marc Dequènes (Duck) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709038: tex-common: fails to upgrade
Package: tex-common Version: 4.03 Severity: grave Coin, This is not the same bug as #709025. As texlive-lang is in NEW and textile-doc is not available for the 2013.20130520 version i did an upgrade instead of a dist-upgrade to avoid having them removed. It gives the following result: Setting up tex-common (4.03) ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... mtxrun --generate failed. Output has been stored in /tmp/mtxrun.968prcQ9 Please include this file if you report a bug. # cat /tmp/mtxrun.968prcQ9 /usr/bin/mtxrun:15228: attempt to index field 'loaders' (a nil value) Maybe this is due to 2012 packages still being around, but in this case either dependencies are not tight enough, either there's missing Breaks. Regards. -- Marc Dequènes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682013: fai-server: fai-setup failing on dracut setup
severity 682013 serious thanks Coin, I tried with both patches and it works like a charm. The second patch makes sense, but dunno about idmapd.conf. it probably needs more review. Nevertheless, creating a nfsroot is necessary to use FAI at all and fails with the default configuration, thus increasing severity to get something working in Wheezy. Regards. -- Marc Dequènes -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678912: dicoweb: crash since Django switch from 1.3 to 1.4
Package: dicoweb
Version: 2.2-1
Severity: grave
Coin,
The webui is totally broken with the following error message:
Traceback:
File /usr/lib/python2.7/dist-packages/django/core/handlers/base.py
in get_response
111. response = callback(request,
*callback_args, **callback_kwargs)
File /usr/share/dicoweb/views.py in index
188. 'selects': selects,})
File /usr/lib/python2.7/dist-packages/django/shortcuts/__init__.py
in render_to_response
20. return HttpResponse(loader.render_to_string(*args,
**kwargs), **httpresponse_kwargs)
File /usr/lib/python2.7/dist-packages/django/template/loader.py in
render_to_string
169. t = get_template(template_name)
File /usr/lib/python2.7/dist-packages/django/template/loader.py in
get_template
145. template, origin = find_template(template_name)
File /usr/lib/python2.7/dist-packages/django/template/loader.py in
find_template
128. loader = find_template_loader(loader_name)
File /usr/lib/python2.7/dist-packages/django/template/loader.py in
find_template_loader
101. raise ImproperlyConfigured('Error importing
template source loader %s: %s' % (loader, e))
Exception Type: ImproperlyConfigured at /
Exception Value: Error importing template source loader
django.template.loaders.filesystem.load_template_source: 'module'
object has no attribute 'load_template_source'
More details with the debug mode activated can be found here:
http://dico.duckcorp.org/
Regards.
--
Marc Dequènes (Duck)
pgphIp4TT1s5M.pgp
Description: PGP Digital Signature
Bug#647613: boswars: Crashes when loading saved game.
Coin, We still have no reply from you about your crash in Boswars. Would you please have a look at http://bugs.debian.org/647613 and reply to this mail (with the Cc) ? Regards. -- Marc Dequènes (Duck) pgpuEQdNL7MGp.pgp Description: PGP Digital Signature
Bug#675526: horde3: unusable with PHP 5.4
Package: horde3
Version: 3.3.12+debian0-2.1
Severity: grave
Tags: patch
Coin,
Since i upgraded to PHP 5.4, Horde only returned code 500.
I don't really understand what is Horde doing to error handling (empty
apache or Horde logs), but after loosing some time i found the problem:
PHP Fatal error: Cannot redeclare class SessionHandler in
/usr/share/horde3/lib/Horde/SessionHandler.php on line 21
Since PHP 5.4 a SessionHandler class is provided in the language,
conflicting with Horde's own class.
I made a patch solving this problem by simply renaming the Horde's
class, and it works like a charm. I only tested it with the pgsql
backend, so you should probably proofread the changes affecting the
other backends.
Regards.
diff -Nur /usr/share/horde3_orig/lib/Horde/SessionHandler/dbm.php /usr/share/horde3/lib/Horde/SessionHandler/dbm.php
--- /usr/share/horde3_orig/lib/Horde/SessionHandler/dbm.php 2012-04-30 07:00:13.0 +0200
+++ /usr/share/horde3/lib/Horde/SessionHandler/dbm.php 2012-06-01 23:12:16.0 +0200
@@ -1,6 +1,6 @@
?php
/**
- * SessionHandler:: implementation for DBM files.
+ * HordeSessionHandler:: implementation for DBM files.
* NOTE: The PHP DBM functions are deprecated.
*
* No additional configuration parameters needed.
@@ -13,9 +13,9 @@
* did not receive this file, see http://www.fsf.org/copyleft/lgpl.html.
*
* @author Chuck Hagenbuch ch...@horde.org
- * @package Horde_SessionHandler
+ * @package Horde_HordeSessionHandler
*/
-class SessionHandler_dbm extends SessionHandler {
+class HordeSessionHandler_dbm extends HordeSessionHandler {
/**
* Our pointer to the DBM file, if open.
@@ -25,7 +25,7 @@
var $_dbm;
/**
- * Open the SessionHandler backend.
+ * Open the HordeSessionHandler backend.
*
* @access private
*
@@ -41,7 +41,7 @@
}
/**
- * Close the SessionHandler backend.
+ * Close the HordeSessionHandler backend.
*
* @access private
*
@@ -54,7 +54,7 @@
/**
* Read the data for a particular session identifier from the
- * SessionHandler backend.
+ * HordeSessionHandler backend.
*
* @access private
*
@@ -72,7 +72,7 @@
}
/**
- * Write session data to the SessionHandler backend.
+ * Write session data to the HordeSessionHandler backend.
*
* @access private
*
@@ -88,7 +88,7 @@
/**
* Destroy the data for a particular session identifier in the
- * SessionHandler backend.
+ * HordeSessionHandler backend.
*
* @param string $id The session identifier.
*
@@ -105,7 +105,7 @@
}
/**
- * Garbage collect stale sessions from the SessionHandler backend.
+ * Garbage collect stale sessions from the HordeSessionHandler backend.
*
* @param integer $maxlifetime The maximum age of a session.
*
diff -Nur /usr/share/horde3_orig/lib/Horde/SessionHandler/ldap.php /usr/share/horde3/lib/Horde/SessionHandler/ldap.php
--- /usr/share/horde3_orig/lib/Horde/SessionHandler/ldap.php 2012-04-30 07:00:13.0 +0200
+++ /usr/share/horde3/lib/Horde/SessionHandler/ldap.php 2012-06-01 22:53:29.0 +0200
@@ -1,6 +1,6 @@
?php
/**
- * SessionHandler implementation for LDAP directories.
+ * HordeSessionHandler implementation for LDAP directories.
*
* Required parameters:pre
* 'hostspec' - (string) The hostname of the ldap server.
@@ -20,7 +20,7 @@
* @since Horde 3.1
* @package Horde_SessionHandler
*/
-class SessionHandler_ldap extends SessionHandler {
+class HordeSessionHandler_ldap extends HordeSessionHandler {
/**
* Handle for the current database connection.
@@ -70,7 +70,7 @@
/**
* Read the data for a particular session identifier from the
- * SessionHandler backend.
+ * HordeSessionHandler backend.
*
* @access private
*
@@ -86,7 +86,7 @@
}
/**
- * Write session data to the SessionHandler backend.
+ * Write session data to the HordeSessionHandler backend.
*
* @access private
*
@@ -106,7 +106,7 @@
/**
* Destroy the data for a particular session identifier in the
- * SessionHandler backend.
+ * HordeSessionHandler backend.
*
* @param string $id The session identifier.
*
@@ -119,7 +119,7 @@
}
/**
- * Garbage collect stale sessions from the SessionHandler backend.
+ * Garbage collect stale sessions from the HordeSessionHandler backend.
*
* @param integer $maxlifetime The maximum age of a session.
*
diff -Nur /usr/share/horde3_orig/lib/Horde/SessionHandler/memcache.php /usr/share/horde3/lib/Horde/SessionHandler/memcache.php
--- /usr/share/horde3_orig/lib/Horde/SessionHandler/memcache.php 2012-04-30 07:00:13.0 +0200
+++ /usr/share/horde3/lib/Horde/SessionHandler/memcache.php 2012-06-01 23:12:57.0 +0200
@@ -3,7 +3,7 @@
require_once
Bug#673577: ruby-activesupport-3.2: fails to install
Package: ruby-activesupport-3.2 Version: 3.2.3-1 Severity: serious Coin, Upgrade from 2.3 was not tested: Unpacking ruby-activesupport-3.2 (from .../ruby-activesupport-3.2_3.2.3-1_all.deb) ... dpkg: error processing /var/cache/apt/archives/ruby-activesupport-3.2_3.2.3-1_all.deb (--unpack): trying to overwrite '/usr/lib/ruby/vendor_ruby/active_support/xml_mini.rb', which is also in package ruby-activesupport-2.3 2.3.14-3 Regards. -- Marc Dequènes (Duck) pgp5xWIfda7LC.pgp Description: PGP Digital Signature
Bug#673578: ruby-activerecord: fails to upgrade
Package: ruby-activerecord Version: 3.2.3-1 Severity: serious Coin, Upgrade was not tested: Unpacking replacement ruby-activerecord ... dpkg: error processing /var/cache/apt/archives/ruby-activerecord_3.2.3-1_all.deb (--unpack): trying to overwrite '/usr/lib/ruby/vendor_ruby/active_record/fixtures.rb', which is also in package ruby-activerecord-2.3 2.3.14-1 Regards. -- Marc Dequènes (Duck) pgpF54fa3odFE.pgp Description: PGP Digital Signature
Bug#659907: texlive-binaries: fails to upgrade
Coin, I had to remove jadetex to continue upgrading my machine, and it was in fact purged. After reinstalling the problem still arise. On another machine having texlive-full and jadetex too i could not reproduce. I'm still trying to find a real different besides the architecture (i386 in this case). Quoting Hilmar Preusse hill...@web.de: I guess you can reproduce the problem by running fmtutil-sys --byfmt jadetex as root, right? Yes. I see a lot of sty files from hyperref in /usr/local/share/texmf, which are read by initex when generating the format file for jadetex. Could you (temporarily) hide them by renaming the texmf tree and rerun mktexlsr? You were right, my local extensions were at fault (and not present on the other machine). The message was not that clear, and honestly i would not have expected difficulties when upgrading to a new Debian revision. As this bug will not appear on a pure Debian installation you may well close this bug. Nevertheless avoiding such breakage when there is no new upstream release would be much better if possible. Tell me if you want to investigate more on the subject. Regards. -- Marc Dequènes (Duck) pgp98IJiPYhEV.pgp Description: PGP Digital Signature
