Bug#950096: flatpak: Flatpak fails to open SSL connections with p11-kit 0.23.19
I did a downgrade on the host system back to the version currently in testing 0.23.18 and it works again. There are some on-going discussions on the rolling release distros: https://forum.manjaro.org/t/update-2020-01-26-has-a-bug/121375/6 https://bbs.archlinux.org/viewtopic.php?id=252390 https://github.com/flathub/com.valvesoftware.Steam/issues/526 >From what I have gathered this requires a change of the runtime to interface >with the p11-kit daemon correctly. But I don't know if that is something that >can be quickly fixed on your side. Jan 29, 2020 00:05:14 Simon McVittie : > On Tue, 28 Jan 2020 at 22:50:31 +0100, Lennart Weller wrote: > > > Currently all SSL connections, probably mostly HTTPS, will fail with > > flatpak due to a major API change in p11-kit as discussed in the merge > > request[1] for p11-kit 0.23.19, cause obviously a patch-version changes > > major API endpoints. > > > > Is there something that can be done in the Flatpak executables to make > this work better, or is it a problem with the freedesktop.org reference > runtime? > > Is this triggered by the new p11-kit in the host system, or by the new > p11-kit in the runtime, or by them being on opposite sides of the 0.23.19 > version threshold, or what? > > Thanks, > smcv >
Bug#950096: flatpak: Flatpak fails to open SSL connections with p11-kit 0.23.19
Package: flatpak Version: 1.6.1-1 Severity: important Dear Maintainer, Currently all SSL connections, probably mostly HTTPS, will fail with flatpak due to a major API change in p11-kit as discussed in the merge request[1] for p11-kit 0.23.19, cause obviously a patch-version changes major API endpoints. [1] https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/merge_requests/2255?commit_id=e3361c2ddf3ecfff19908effb80d3a648e3dd75a -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (101, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/24 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=en_US:de (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages flatpak depends on: ii adduser3.118 ii bubblewrap 0.4.0-1 ii libappstream-glib8 0.7.16-1 ii libarchive13 3.4.0-1+b1 ii libc6 2.29-9 ii libdconf1 0.34.0-2 ii libfuse2 2.9.9-2 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-2 ii libglib2.0-0 2.62.4-1+b1 ii libgpgme11 1.13.1-3 ii libjson-glib-1.0-0 1.4.4-2 ii libostree-1-1 2019.6-1 ii libpolkit-agent-1-00.105-26 ii libpolkit-gobject-1-0 0.105-26 ii libseccomp22.4.2-2 ii libsoup2.4-1 2.68.2-1 ii libsystemd0244.1-1 ii libxau61:1.0.8-1+b2 ii libxml22.9.4+dfsg1-8 ii xdg-dbus-proxy 0.1.2-1 Versions of packages flatpak recommends: ii desktop-file-utils 0.24-1 ii gtk-update-icon-cache3.24.13-1 ii hicolor-icon-theme 0.17-2 ii libpam-systemd 244.1-1 ii p11-kit 0.23.19-2 ii policykit-1 0.105-26 ii shared-mime-info 1.10-1 ii xdg-desktop-portal 1.6.0-1 ii xdg-desktop-portal-gtk [xdg-desktop-portal-backend] 1.6.0-1 Versions of packages flatpak suggests: ii avahi-daemon 0.7-5 -- no debconf information
Bug#944227: (no subject)
Hello Gordon, Both pgcli and mycli are managed by me and they both wiating for the prompt_toolkit update to major version 2. The updated packages are already in the vcs but cannot be uploaded yet to unstable. I might push them to experimental in case you want to test something. Kind regards, Lennart
Bug#930010: warnings with postgresql 11
Hi Daniel, currently the package upload hangs on the fact that python-prompt-toolkit is one major version behind in testing/buster. I might look into just patching the pgcli a little bit to avoid this warning. I dont think I want to go through the process to get a new major version of i think at least 2-3 python modules into buster while in freeze. Lennart On 05.06.19 06:26, Daniel Baumann wrote: > Package: pgcli > Version: 1.9.0-1 > > Hi Lennart, > > when using pgcli in buster which has postgresql 11, I'll get the > following ugly warnings on start: > > ---snip--- > $ sudo -u postgres pgcli > Version: 1.9.1 > Chat: https://gitter.im/dbcli/pgcli > Mail: https://groups.google.com/forum/#!forum/pgcli > Home: http://pgcli.com > postgres> Exception in thread completion_refresh: > Traceback (most recent call last): > File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner > self.run() > File "/usr/lib/python3.7/threading.py", line 865, in runs-mode > Refreshing completions... > self._target(*self._args, **self._kwargs) > File "/usr/share/pgcli/pgcli/completion_refresher.py", line 68, in > _bg_refresh > refresher(completer, executor) > File "/usr/share/pgcli/pgcli/completion_refresher.py", line 146, in > refresh_functions > completer.extend_functions(executor.functions()) > File "/usr/share/pgcli/pgcli/pgcompleter.py", line 224, in > extend_functions > for f in func_data: > File "/usr/share/pgcli/pgcli/pgexecute.py", line 612, in functions > cur.execute(query) > psycopg2.ProgrammingError: column p.proisagg does not exist > LINE 8: p.proisagg is_aggregate, > ^ > HINT: Perhaps you meant to reference the column "p.prolang". > > > postgres> > > Time: 0.000s > postgres> > ---snap--- > > Regards, > Daniel
Bug#904765: looking-glass packaging questions
Hello everyone I do have some changes I want to make to the package to make it more comfortable to use. Before the first use the looking-glass host (this package) requires some changes to the libvirt-qemu abstract apparmor profile. Explicility changing "/{dev,run}/shm r," to read-write The problem is I have to either change this file or libvirts apparmor template both of which are not owned by my own package. In the later case only future VMs would have the correct option. Or I could just print a dialog saying change it yourself. What would be the preferred way here? Another possible step that could be taken is to create the shm device automatically on install i.e. with a oneshot systemd service. That would be easy and remove an additional step without much interference with the rest of the system. Does anyone know of a package which has to do something similar? The last change is something maybe for the future. The software depends on a client component for windows which currently needs to be downloaded from the authors website. I imagine one could supply a self cross-compiled windows executable on an iso that could be easily mounted into the vm and installed from there. Has anyone done something similar to this? So far I know only of virtio drivers but they are not supplied by debian anywhere as far as i can see. - Lennart
Bug#904765: closed by Bart Martens (closing RFS: looking-glass/0+a11-1 [ITP])
I recently uploaded a new version tagged 0+a12 of looking-glass. I'm still looking for sponsors. In case the use-case for this software is not clear a short description from the official website: > Looking Glass is an open source application that allows the use of a KVM > (Kernel-based Virtual Machine) configured for > VGA PCI Pass-through without an attached physical monitor, keyboard or mouse. > This is the final step required to move > away from dual booting with other operating systems for legacy programs that > require high performance graphics. It an extremly useful software for these kinds of setups. And in combination with software such as barrier (which was recently added to the repos) it makes VFIO a basically flawless experience. Happy new year, Lennart
Bug#904765:
And another upstream release before I could find a sponsor. * Package name : looking-glass Packaging link : https://salsa.debian.org/lhw-guest/looking-glass Version : 0+a12 Upstream Author : Geoffrey McRae * URL : https://github.com/gnif/LookingGlass * License : GPL2+ Programming Lang: C Description : An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough
Bug#898931: Fwd: Bug#898931: Acknowledgement (ITP: looking-glass -- An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough)
And another upstream release before I could find a sponsor. * Package name : looking-glass Packaging link : https://salsa.debian.org/lhw-guest/looking-glass Version : 0+a12 Upstream Author : Geoffrey McRae * URL : https://github.com/gnif/LookingGlass * License : GPL2+ Programming Lang: C Description : An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough
Bug#913034: (no subject)
Control: found 1.1.7-2 I had my system automatically install libasound2-plugins 1.1.7-2 coming from 1.1.6-1+b1 which was working fine. With 1.1.7-2 it is still failing on my system. Alsa shows all devices as on but Pulse in my case has no knowledge of them.
Bug#904765: RFS: looking-glass/0+a11-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "looking-glass" * Package name: looking-glass Packaging link : https://salsa.debian.org/lhw-guest/looking-glass Version : 0+a11-1 Upstream Author : Geoffrey McRae * URL : https://github.com/gnif/LookingGlass * License : GPL2+ Programming Lang: C Description : An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough Section:: admin It builds those binary packages: looking-glass-client - Low latency KVM FrameRelay implementation for VGA Passthrough To access further information about this package, please visit the following URL: https://mentors.debian.net/package/looking-glass Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/l/looking-glass/looking-glass_0+a11-1.dsc Regards, Lennart Weller
Bug#903312: innoextract: bad chunk magic: iostream error on armhf
Hey, You should still report it upstream. GOG containers are probably the most common use-case for innoextract so I assume they will be able to help with this issue. Version 1.7 was supposed to fix some issues with the newer versions of GOG Installers but maybe there are some caveats left. Lennart On 08.07.2018 20:07, Phil Morrell wrote: Package: innoextract Version: 1.6-1+b2 Severity: important Hi, I was only able to extract this particular archive on my main machine (amd64), not on the pi (armhf). I got the same results with v1.7 and I am able to extract other archives on the pi without issue. I'm guessing this is an upstream issue, but I don't know what else to provide for diagnosis, given it's commercial data. I checked the obvious things like md5sum, fresh download, free space etc. -- Phil Morrell (emorrp1) $ innoextract --version innoextract 1.6 Extracts installers created by Inno Setup 1.2.10 to 5.5.8 $ innoextract --test setup_anno_1404_gold_edition_2.01.5010_\(13111\).exe Testing "Anno 1404" - setup data version 5.5.7 (unicode) - "tmp/DirectXEULA.txt" [temp] (9.92 KiB) - overwritten - "tmp/MSVC2005EULA.txt" [temp] (5 KiB) - overwritten - "tmp/EULA.txt" [temp] (46.2 KiB) - overwritten - "app/goggame-1440426004.ico" (134 KiB) - overwritten Opening "setup_anno_1404_gold_edition_2.01.5010_(13111)-1.bin" Stream error while extracting files! └─ error reason: bad chunk magic: iostream error If you are sure the setup file is not corrupted, consider filing a bug report at http://innoextract.constexpr.org/issues Done with 1 error. -- System Information: Debian Release: 9.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages innoextract depends on: ii libboost-filesystem1.62.0 1.62.0+dfsg-4 ii libboost-iostreams1.62.01.62.0+dfsg-4 ii libboost-program-options1.62.0 1.62.0+dfsg-4 ii libboost-system1.62.0 1.62.0+dfsg-4 ii libc6 2.24-11+deb9u3 ii libgcc1 1:6.3.0-18+deb9u1 ii liblzma55.2.2-1.2+b1 ii libstdc++6 6.3.0-18+deb9u1 innoextract recommends no packages. innoextract suggests no packages. -- no debconf information
Bug#898931: Acknowledgement (ITP: looking-glass -- An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough)
A few things have changed since the initial ITP. The package had license issues which have been resolved upstream. The packaging is already finished and available at the link below. * Package name: looking-glass Packaging link : https://salsa.debian.org/lhw-guest/looking-glass Version : 0+a11 Upstream Author : Geoffrey McRae * URL : https://github.com/gnif/LookingGlass * License : GPL2+ Programming Lang: C Description : An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough
Bug#898931: ITP: looking-glass -- An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: looking-glass Version : 0+a10 Upstream Author : Geoffrey McRae * URL : https://github.com/gnif/LookingGlass/ * License : GPL2+ with OpenSSL Exception Programming Lang: C Description : An extremely low latency KVM FrameRelay implementation for guests with VGA PCI Passthrough LookingGlass enables you to use shared memory to pass rendered frames from a virtual machine back to the host system. This is exceptionally useful for IOMMU/VFIO graphics card passthrough setups.
Bug#894321: new upstream (1.9.0)
pgcli > 1.6 depends on their own version of cli_helpers which they use for pgcli and mycli. And I dont feel it would be ideal to vendorize the library in both packages. So I opened this https://mentors.debian.net/package/cli-helpers 5 months ago. If that was to go in at some point I will also update these two packages. March 29, 2018 5:39 AM, "Daniel Baumann" wrote: > Package: pgcli > Severity: wishlist > > Hi, > > thank you for maintaining pgcli in debian. However, it would be nice if > you could upgrade pgcli to the current usptream version (1.9.0). > > Regards, > Daniel
Bug#889653: netdata: missing python module 'pyyaml2'
Alright. I already found the issue in the package. I must have accidentally removed the python.d patch which I had created previously thinking it was obsolete. I'll re-add it and update the package. That should fix it again so that the netdata python modules use the system pyyaml. February 13, 2018 9:39 AM, "Thomas Leuxner" wrote: > * Guillaume Clercin 2018.02.12 13:05: > >> Hi, >> >> Finally, after copying "pyyam2" and "pyyaml3" from "python.d/python_modules" >> from git repository of netdata to >> "/usr/lib/x86_64-linux-gnu/netdata/python.d/ >> python_modules". Netdata's python modules works. > > ln -s /usr/lib/python3/dist-packages/yaml/ pyyaml3 > ln -s /usr/lib/python2.7/dist-packages/yaml/ pyyaml2 > > Does it for me. Since the packages are already installed elsewhere this is > more like a kludge. > > Regards > Thomas
Bug#889653: netdata: missing python module 'pyyaml2'
It does depend on pyyaml3. Quote from your submitted bugreport: Versions of packages netdata depends on: ii python3-yaml 3.12-1+b1 On 05/02/2018 11:53, Guillaume Clercin wrote: Package: netdata Version: 1.9.0+dfsg-1 Severity: important Dear Maintainer, After upgrading netdata, no python modules were enabled. Python modules required pyyaml2 or (pyyaml3 maybe) in order to run. These packages should be provided by netdata. They are available here: https://github.com/firehol/netdata/tree/v1.9.0/python.d/python_modules Please, package them into netdata packages. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages netdata depends on: ii adduser 3.117 ii libc62.26-6 ii libcap2-bin 1:2.25-1.2 ii libuuid1 2.30.2-0.3 ii lsb-base 9.20170808 ii netdata-data 1.9.0+dfsg-1 ii python3 3.6.4-1 ii python3-urllib3 1.22-1 ii python3-yaml 3.12-1+b1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages netdata recommends: ii curl7.58.0-2 pn fping ii nodejs 4.8.4~dfsg-1 netdata suggests no packages. -- Configuration Files: /etc/netdata/health_alarm_notify.conf changed [not included] /etc/netdata/netdata.conf changed [not included] /etc/netdata/python.d/postgres.conf changed [not included] -- no debconf information
Bug#888815: making SEND_EMAILS configurable
Hey Daniel, feel free to submit a patch. I wouldn't mind having some configuration options at install time. Also you seem to be the of the most involved person using netdata on debian. If you want we could add you as a maintainer. Lennart January 30, 2018 9:30 AM, "Daniel Baumann" wrote: > Package: netdata > Severity: wishlist > > Hi, > > netdata sends really a lot of mails by default. since this is, > especially when using on a larger amount of servers, very annoying. > > depending on the use case (if netdata is used for monitoring/reporting, > or "just" for a "graphical top"/"diagnosing problems"), it might make > sense to disable that. > > and further more, on systems that have no email setup on purpose/not > yet, these just waste cpu cycles. > > would you accept a patch that would make SEND_EMAIL in > /etc/netdata/health_alarm_notify.conf configurable via a debconf > question at package installation time (defaulting to yes i guess)? > > Regards, > Daniel
Bug#885661: ITP: cli-helpers -- Helper library for creating Python CLI applications
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: cli-helpers Version : 1.0.1 Upstream Author : Amjith Ramanujam * URL : http:github.com/dbcli/cli_helpers * License : BSD-3-clause Programming Lang: Python Description : Helper library for creating Python CLI applications A Python package that makes it easy to perform common tasks when building command-line apps. Mostly needed for the newer versions of mycli and pgcli
Bug#879765: netdata: fails to run on CPUs without SSE2 instruction set
Ah. Good old Soekris. I had a quick look through the source of netdata. The only part of netdata that makes use of the SSE instruction set is their implementation of the stats.d. Now, I didn't test this but you could try disabling just this part of the application. It shouldn't affect the charts. /etc/netdata/netdata.conf: [statsd] enabled = no I don't know if the compiler automatically used the SSE2 instruction set elsewhere, but it's worth a try. October 25, 2017 4:51 PM, "Adrian Woodley" wrote: > Package: netdata > Version: 1.6.0+dfsg-3~bpo9+1 > Severity: normal > > Dear Maintainer, > > While trying to run netdata on a Soekris Net5501 SBC, I learned that NetData > is built using the > SSE2 instruction set, and that my AMD Geode CPU doesn't implement these > instructions. > > The simple fix is to add --disable-x86-sse to dh_auto_configure, however this > is not a viable > solution as it would adversely impact the majority of users. > > Is there potential to build a second binary package for netdata which > includes this autoconf > configuration - possibly netdata-nosse2?
Bug#878890: netdata: Debian pachaged netdata fails to detect disks/partitions correctly
I assume it has something to do with our strict ReadOnly policy applied by systemd. Try changing the netdata service file (/lib/systemd/system/netdata.service) to be more lenient. e.g. Change ReadOnlyDirectories=/ to ReadWriteDirectories=/ or remove the lines completely. Don't forget to reload the service file after a change I have honestly no idea why the daemon would need write permissions on those directories but it's worth a try as there were some odd cases before. If that doesn't help you can remove some of the other security related lines and check if it helps. October 17, 2017 3:48 PM, "Skibbi" wrote: [...] > Manually installed netdata (from binaries) displays following partitions > under > Disks menu: > sda - i/o stats > / - disk space and inodes count > /dev - disk space and inodes count > /dev/shm - disk space and inodes count > /run - disk space and inodes count > /run/lock - disk space and inodes count > > Debian packaged netdata displays completely different partition configuration: > sda - i/o stats > /tmp - disk space and inodes count > /var - disk space and inodes count > /var/tmp - disk space and inodes count > > Debian packaged netdata unfortunately fails to detect correctly disks on my > servers therefore monitoring them is not very reliable and I haven't found a > way > to fix the partitions manually in netdata config.
Bug#869200: Adequate still reports netdata as having obsolete conffile , maybe an adequate bug ?
No it looks like i'm using the rm_conffile wrong. I'll have to check why this didn't work as expected. I haven't used it before. the adequate result should be correct. I'll try it out for the next release. We have some small warnings to remove anyway. August 30, 2017 7:45 AM, "shirish शिरीष" wrote: > reopen 869200 > thanks > > Dear Federico Ceratto, > Adequate still reports the obsolete conffiles even after the upgrade. > > [$] apt-cache policy netdata > > netdata: > Installed: 1.7.0+dfsg-1 > Candidate: 1.7.0+dfsg-1 > Version table: > *** 1.7.0+dfsg-1 600 > 600 http://httpredir.debian.org/debian buster/main amd64 Packages > 1 http://httpredir.debian.org/debian unstable/main amd64 Packages > 100 /var/lib/dpkg/status > > ─[$] adequate netdata | head -2 > netdata: obsolete-conffile /etc/netdata/python.d/nginx_log.conf > netdata: obsolete-conffile /etc/netdata/python.d/gunicorn_log.conf > > I have no idea whether it's adequate which is at fault or netdata. > Although would have to state that bugs/false positives for adequate > have been surprisingly small. > > -- > Regards, > Shirish Agarwal शिरीष अग्रवाल > My quotes in this email licensed under CC 3.0 > http://creativecommons.org/licenses/by-nc/3.0 > http://flossexperiences.wordpress.com > EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Bug#838056: nvidia-texture-tools: Embedded libsquish library now available in debian)
After some time away from this hogwash of builtin and modified libraries in nvtt im back to work on it. Right now I think I have to rewrite the use of libsquish in the project before i can link it with the system library, as it uses internal and deprecated header files to do colourspace compressions in DXT1 and 3. I'll try to get this in though and replace one more bundled library in exchange for three new ones added in 2.1.0 ...
Bug#861713: netdata: `service netdata restart` fails due to missing pidfile
What init do you use on your system? The creation of the pid file should have been done by the init. May 3, 2017 5:09 AM, "Daniel Ring" wrote: > Package: netdata > Version: 1.5.0+dfsg-4 > Severity: normal > > Dear Maintainer, > > The init scripts provided with this package do not seem to work properly. > I reported this bug upstream at > https://github.com/firehol/netdata/issues/2135, but the init > scripts provided with this package have been modified for Debian so I'm not > sure where the issue > first arose. > The directory "/var/run/netdata" is not created by default on my system. > Creating it and chowning > to netdata:netdata had no effect. > > Running `service netdata restart` results in the following output: > [ ok ] Stopping the netdata daemon...done (not running - there is no > /var/run/netdata/netdata.pid). > [] Starting the netdata daemon...2017-05-02 19:55:59: netdata: ERROR: > IPv4 bind() on ip > '127.0.0.1' port 1 failed. (errno 98, Address already in use) > 2017-05-02 19:55:59: netdata: ERROR: Cannot bind to ip '127.0.0.1', port 1 > 2017-05-02 19:55:59: netdata: FATAL: Cannot listen on any socket. Exiting... > # : Success > > 2017-05-02 19:55:59: netdata: INFO: Saving database... > 2017-05-02 19:55:59: netdata: INFO: netdata exiting. Bye bye... > failed. > > Running `service netdata stop` results in the following output: > [ ok ] Stopping the netdata daemon...done (not running - there is no > /var/run/netdata/netdata.pid). > > A netdata instance is running normally in the background in both cases. > Running `service netdata start` works as expected. > > -- System Information: > Debian Release: 8.7 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: i386 (i686) > > Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages netdata depends on: > ii adduser 3.113+nmu3 > ii init-system-helpers 1.22 > ii libc6 2.19-18+deb8u7 > ii libcap2-bin 1:2.24-8 > ii libuuid1 2.25.2-6 > ii lsb-base 4.1+Debian13+nmu1 > ii netdata-data 1.5.0+dfsg-4 > ii python 2.7.9-1 > ii python-yaml 3.11-2 > ii zlib1g 1:1.2.8.dfsg-2+b1 > > Versions of packages netdata recommends: > pn nodejs > > netdata suggests no packages. > > -- Configuration Files: > /etc/netdata/netdata.conf changed [not included] > > -- no debconf information
Bug#854401: AW: Bug#854401: new upstream (1.5)
It's already in our alioth git. We are currently waiting on some clarifications. But if you want to you can build it from the git already -Ursprüngliche Nachricht- Von: Daniel Baumann [mailto:daniel.baum...@progress-linux.org] Gesendet: Montag, 6. Februar 2017 18:34 An: sub...@bugs.debian.org Betreff: Bug#854401: new upstream (1.5) Package: netdata Severity: wishlist Hi, it would be nice if you could upgrade to the current upstream version (1.5) in experimental. Regards, Daniel
Bug#846750: Processed: Also add the affects
Those headers are so utterly useless. I patched the debian package for now and tested it with some examples for b64. I'll have to upstream some of these changes. The actual package as it is upstream doesn't even work. December 6, 2016 10:57 AM, ow...@bugs.debian.org wrote: > Processing commands for cont...@bugs.debian.org: > >> affects 846750 src:aseprite > > Bug #846750 [libmodpbase64-dev] aseprite: FTBFS: modp_b64.h:33:28: fatal > error: extern_c_begin.h: > No such file or directory > Added indication that 846750 affects src:aseprite >> thanks > > Stopping processing here. > > Please contact me if you need assistance. > -- > 846750: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846750 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#841612: libmodpbase64-dev: modp_stdint.h is missing
The modp_stdint.h is not installed on non-Windows systems. It just defines some standard storage names also available in stdint.h. Including it in the install seems nonsensical.
Bug#829021: pgcli: Crashes on launch
Apparently prompt-toolkit was updated again breaking all compatibility. I'll have a look the next few days to see what needs patching. On 29.06.2016 21:48, Sajith T S wrote: Package: pgcli Version: 0.20.1-3 Severity: important Upon providing password, pgcli dies with the Traceback copied below; psql continues to work normally. $ pgcli -h localhost -d -U Password: Traceback (most recent call last): File "/usr/bin/pgcli", line 9, in load_entry_point('pgcli==0.20.1', 'console_scripts', 'console')() File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__ return self.main(*args, **kwargs) File "/usr/lib/python3/dist-packages/click/core.py", line 696, in main rv = self.invoke(ctx) File "/usr/lib/python3/dist-packages/click/core.py", line 889, in invoke return ctx.invoke(self.callback, **ctx.params) File "/usr/lib/python3/dist-packages/click/core.py", line 534, in invoke return callback(*args, **kwargs) File "/usr/share/pgcli/pgcli/main.py", line 595, in cli pgcli.run_cli() File "/usr/share/pgcli/pgcli/main.py", line 278, in run_cli self.cli = self._build_cli() File "/usr/share/pgcli/pgcli/main.py", line 408, in _build_cli cli = CommandLineInterface(application=application) File "/usr/lib/python3/dist-packages/prompt_toolkit/interface.py", line 68, in __init__ assert isinstance(eventloop, EventLoop) AssertionError -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pgcli depends on: ii python3-click 6.6-1 ii python3-configobj 5.0.6-2 ii python3-pgspecial 1.3.0-1 ii python3-prompt-toolkit 1.0.2-1 ii python3-psycopg22.6.1-1+b2 ii python3-pygments2.1.3+dfsg-1 ii python3-setproctitle1.1.8-1+b2 ii python3-sqlparse0.1.18-1 pn python3:any pgcli recommends no packages. pgcli suggests no packages. -- no debconf information
Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
March 8 2016 1:52 PM, "Sergey Vojtovich" wrote: > I adjusted your patch a bit, it seem to work well for me. Could you please > verify if you're fine with the attached version and it works for you too? Well you basically dropped all the safe guards. But in the end its a logrotate script. Most people will never have the problem in the first place or know whatwent wrong on their end when they see your version of the script. So yeah fine with me. > You mean "$($MYADMIN flush-logs)" doesn't return 1? I just tested it on my > side > and got exit status 1. I'll try to find a reproducible bug some other time. But it can happen. EXIT_SUCCESS but error on stderr.
Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
On Mon, Mar 07, 2016 at 06:37:49PM +0400, Sergey Vojtovich wrote: > Existence of pid-file is a sure sign that there's mysqld running, the only > exception is mysqld crash. What do you think about skipping this check? > > I'd also suggest to turn things around and check for pid-file first and then > just run "MYADMIN flush-logs" allowing it to return error in case of failure. Yep. Switched the order for this one. But mysqladmin does not return 1 when it fails to connect. Did some additional testing. For now I put it back to the way it was in the original logrotate and just check if stdout/stderr of the command is null. This probably merits a second bug report. diff --git a/mariadb-server-10.0.mysql-server.logrotate.orig b/mariadb-server-10.0.mysql-server.logrotate index 52f1292..30d8bec 100644 --- a/mariadb-server-10.0.mysql-server.logrotate.orig +++ b/mariadb-server-10.0.mysql-server.logrotate @@ -14,14 +14,11 @@ # If this fails, check debian.conf! MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" - if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then - # Really no mysqld or in incorrect authentication in /etc/mysql/debian.cnf user? - # If this occurs and is not a error please report a bug. - if ps cax | grep -q mysqld; then - exit 1 - fi - else - $MYADMIN flush-logs + PID=$(my_print_defaults mysqld | grep -oP "pid-file=\K[^$]+") + if [ -r $PID ]; then + # If the pid-file exists and the process is mysqld it should be able to flush the logs + [ "$(ps -p $(cat $PID) -o comm=)" = "mysqld" -a -n "$($MYADMIN flush-logs 2>&1)" ] && exit 1 fi + exit 0 endscript } signature.asc Description: Digital signature
Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
On Mon, Mar 07, 2016 at 04:15:54PM +0400, Sergey Vojtovich wrote: > > March 3 2016 9:35 PM, "Otto Kekäläinen" wrote: > I consider it lesser evil. You may use my_print_defaults to get > pid-file value. > > Worth to note that I don't see any value in executing "mysqladmin ping". I attached a version of the patch using my_print_defaults with its standard locations. Not specifying any configuration files in case they change with 10.1. And the ping removed in favor of checking the exit code of flush-logs. I did some rudimentary testing. But I can't be sure that I caught all possible versions of existing files/processes and names. So there might be some corner cases with incorrect exit codes. Lennart diff --git a/mariadb-server-10.0.mysql-server.logrotate.orig b/mariadb-server-10.0.mysql-server.logrotate index 52f1292..9a2050a 100644 --- a/mariadb-server-10.0.mysql-server.logrotate.orig +++ b/mariadb-server-10.0.mysql-server.logrotate @@ -14,14 +14,13 @@ # If this fails, check debian.conf! MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" - if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then - # Really no mysqld or in incorrect authentication in /etc/mysql/debian.cnf user? - # If this occurs and is not a error please report a bug. - if ps cax | grep -q mysqld; then - exit 1 + if [ ! $($MYADMIN flush-logs 2>/dev/null) ]; then + # If the pid-file exists and the process is mysqld it should have flushed + PID=$(my_print_defaults mysqld | grep -oP "pid-file=\K[^$]+") + if [ -r $PID ]; then + test "$(ps -p $(cat $PID) -o comm=)" = "mysqld" && exit 1 + exit 0 fi - else - $MYADMIN flush-logs fi endscript } signature.asc Description: Digital signature
Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
March 3 2016 9:35 PM, "Otto Kekäläinen" wrote: > Hello Lennart! > > I asked core developers to review this and got this reply: > > It's probably alright for 10.0. But it's not completely suitable for 10.1. > As contributor mentioned himself that there's a problem with this patch: > "When mysqld is called without mysqld_safe". > > I'd rather simplify this script to something like (not tested): > if [ -x /var/run/mysqld/mysqld.pid ]; then > $MYADMIN flush-logs || exit 1 > fi > > What do you think? The line would result in some other issues. But the general idea was already tossed around here before. Assume pid file location and then check if the process running on the pid is named mysqld. I don't really see an issue with my current version either though. In case that the mysqld_safe script will be abandoned in the future a lot of the configuration files and init scripts/unit files need to be updated anyhow. And the only change here would be removing one layer in the hierachy. From: PPID=$(ps -o ppid= -p $PID) if [ $(ps -p $PPID -o comm=) = mysqld_safe ]; then test $(ps -o ppid= -p $PPID) -eq 1 && exit 1 fi To: test $(ps -o ppid= -p $PID) -eq 1 && exit 1 But if you are fine with just checking the PID file at a static location something like the attached patch should be fine. logrotate.patch Description: Binary data
Bug#799776: python-pymysql: Update package to 0.6.6 or newer to satisfy the mycli dependency
I'm currently not very invested in the upgrade to the package. I fixed mycli up to work with 0.6.2. But I obviously don't mind updating it. Just need to test it with the 0.7.2 release. But updating the pymysql is not in my hands anyway. On 4 March 2016 12:39:57 CET, Sandro Tosi wrote: >what's the status of this? 0.7.2 was released recently, and we would >start to use it pretty soon (in Jessie, so a backport will be needed, >i can handle it if you prefer). is there a plan to update pymysql >soon? > >Thanks, >-- >Sandro "morph" Tosi >My website: http://sandrotosi.me/ >Me at Debian: http://wiki.debian.org/SandroTosi >G+: https://plus.google.com/u/0/+SandroTosi
Bug#810968: [debian-mysql] Bug#810968: Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
Hey Otto, Sorry I totally forgot about this. Yes, I do have an updated patch. I actually found there to be some issues with containers which had embedded mysqld forked from the start script so I added an additional check to the 2) version. Following problems might exist in the future with this version: - When mysqld is called without mysqld_safe - Somebody managed to start mysqld as init So it shouldn't be too much of an issue in general. Lennart On Sun, Feb 21, 2016 at 03:48:38PM +0200, Otto Kekäläinen wrote: > Hello Lennart! > > Do you intend to make one more version of the patch so that it is > perfect and it is safe for me to include it in the next upload? > > Thanks for your help! > > 2016-01-26 11:13 GMT+02:00 Otto Kekäläinen : > >> 2) Check the parent process id being 1 > >>In this case parent of the parent because of mysqld_safe > >># test $(ps -o ppid= -p $(ps -o ppid= -p $PID)) -eq 1 > >>This would work in most cases I can think of. mysqld run by a user > >>or a container would not be started by the init. But seems like a > >>rather complex solution to a fairly simple problem. > > > > Option 2 seems OK. Alternatively we could check processed owned by user > > 'mysql'. > > > > Yes, the solution might be a bit complex, but I am fine with it as > > long as the bash code is well documented and as clean as possible, so > > that potential regressions/bugs in future are easy to track down and > > new people are confident in tweaking the code. Try avoiding long > > oneliners and short-cut code style (to the extend possible, it is > > after all bash scripting). diff --git a/mysql-server b/mysql-server.new index 52f1292..19b1614 100644 --- a/mysql-server +++ b/mysql-server @@ -16,10 +16,14 @@ MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then # Really no mysqld or in incorrect authentication in /etc/mysql/debian.cnf user? - # If this occurs and is not a error please report a bug. - if ps cax | grep -q mysqld; then - exit 1 - fi + for PID in $(pgrep mysqld); do + # If the parent of the parent (mysqld_safe) PID is 1 we can assume it's the system + # mysqld and it should have responded to the ping + PPID=$(ps -o ppid= -p $PID) + if [ $(ps -p $PPID -o comm=) = mysqld_safe ]; then + test $(ps -o ppid= -p $PPID) -eq 1 && exit 1 + fi + done else $MYADMIN flush-logs fi signature.asc Description: Digital signature
Bug#813335: mdadm: Upgrade from jessie to testing breaks boot with raid on lvm2
Control: found 3.3.2-5+deb8u1 It's probably the patch which was released a few months ago in testing and a few days ago also in stable as 3.3.2-5+deb8u1 is also affected. As can be seen here: http://unix.stackexchange.com/questions/258790/ Try reversing the patch locally and see if it fixes your problem: --- a/lib/udev/rules.d/64-md-raid-assembly.rules +++ b/lib/udev/rules.d/64-md-raid-assembly.rules @@ -25,6 +25,9 @@ GOTO="md_inc_end" LABEL="md_inc" +# Disable incremental assembly to fix Debian bug #784070 +GOTO="md_inc_end" + # remember you can limit what gets auto/incrementally assembled by # mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY' ACTION=="add|change", IMPORT{program}="BINDIR/mdadm --incremental --export $tempnode --offroot ${DEVLINKS}"
Bug#810968: [debian-mysql] Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
Well okay I didn't know the config files were being split up. There are two options of the top of my head: 1) As you said. Just assume the pid file location 2) Check the parent process id being 1 In this case parent of the parent because of mysqld_safe # test $(ps -o ppid= -p $(ps -o ppid= -p $PID)) -eq 1 This would work in most cases I can think of. mysqld run by a user or a container would not be started by the init. But seems like a rather complex solution to a fairly simple problem. January 26 2016 9:18 AM, "Otto Kekäläinen" wrote: > Thanks Lennart, the patch is much nicer to read now. > > It seems to rely on the fact that it should find the line 'pid-file = > /var/run/mysqld/mysqld.pid' in the file /etc/mysql/my.cnf > > However, since the new mysql/mariadb config decoupling effort (driven > by Ubuntu developers) the file /etc/mysql/my.cnf is no longer the main > config file itself, and does not contain the pid line. > > The actual line is now found in: > grep pid /etc/mysql/mariadb.conf.d/* > /etc/mysql/mariadb.conf.d/50-server.cnf:pid-file = > /var/run/mysqld/mysqld.pid > > Ironically simply assuming the exact location > /var/run/mysqld/mysqld.pid would be more reliable than grepping the > configs :) > > I am glad the fix works in your situation in Debian Jessie. > Unfortunately we need to think a bit more to come up with a universal > solution.. I am happy to review any alternative solutions/patches > anybody posts to this issue.
Bug#811612: FTBFS with GCC 6: cannot convert x to y
On 20.01.2016 18:30, Martin Michlmayr wrote This builds fine. Nice. So I either just have to add the patches for 2.0.8 or get 0ad to work with 2.1.0. I'll look into that in the next few days as time permits. Can you remind me how to generate the orig tarball? There are two source branches. upstream which is the original source imported from gcode/github and dfsg_clean which is the upstream branch minus all the propriertary libraries he for some reason still has in the source. The HEAD on both is the 2.1.0 release. To export the orig tarball you use gbp buildpackage -S or gbp buildpackage -S --git-upstream-tag=upstream/2.1.0+git20150822+dfsg Otherwise you can probably just switch to the branch and tar it right there excluding .git and have the same result. Lennart
Bug#811612: FTBFS with GCC 6: cannot convert x to y
Hey Martin, Could you also report this upstream[0]? The upstream version and the current debian version are already diverging by quite a bit and I don't want to add even more patches on top. Have you tried building the experimental branch from [1] with gcc6? It's a way more recent release but seems to break some functionality in 0ad. [0] https://github.com/castano/nvidia-texture-tools [1] http://anonscm.debian.org/cgit/collab-maint/nvidia-texture-tools.git January 20 2016 1:21 AM, "Martin Michlmayr" wrote: > Package: nvidia-texture-tools > Version: 2.0.8-1+dfsg-8 > Severity: important > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-6 gcc-6-cannot-convert > > This package fails to build with GCC 6. GCC 6 has not been released > yet, but it's expected that GCC 6 will become the default compiler for > stretch. > > Note that only the first error is reported; there might be more. You > can find a snapshot of GCC 6 in experimental. To build with GCC 6, > you can set CC=gcc-6 CXX=g++-6 explicitly. > >> sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux > > ... > >> [ 33%] Building CXX object src/nvimage/CMakeFiles/nvimage.dir/ImageIO.cpp.o >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp: In >> function >> 'nv::FloatImage* nv::ImageIO::loadFloat(const char*)': >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:138:10: >> error: cannot >> convert 'bool' to 'nv::FloatImage*' in return >> return false; >> ^ >> >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp: In >> function 'nv::Image* >> nv::ImageIO::loadTGA(nv::Stream&)': >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:236:12: >> error: cannot >> convert 'bool' to 'nv::Image*' in return >> return false; >> ^ >> >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:257:11: >> error: cannot >> convert 'bool' to 'nv::Image*' in return >> return false; >> ^ >> >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp: In >> function 'nv::Image* >> nv::ImageIO::loadPNG(nv::Stream&)': >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:624:10: >> error: cannot >> convert 'bool' to 'nv::Image*' in return >> return false; >> ^ >> >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:632:10: >> error: cannot >> convert 'bool' to 'nv::Image*' in return >> return false; >> ^ >> >> /<>/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:639:10: >> error: cannot >> convert 'bool' to 'nv::Image*' in return >> return false; >> ^ >> >> src/nvimage/CMakeFiles/nvimage.dir/build.make:134: recipe for target >> 'src/nvimage/CMakeFiles/nvimage.dir/ImageIO.cpp.o' failed > > -- > Martin Michlmayr > Linux for HPE Helion, Hewlett Packard Enterprise
Bug#810968: [debian-mysql] Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
I added some comments to the patch On Fri, Jan 15, 2016 at 08:58:29AM +0200, Otto Kekäläinen wrote: > Thanks for reporting this and supplying a patch! > > Can you please make a new version where the scipt block has some > comments? There is rather complex stuff going on and somebody > reviewing it would have an easier time if they can from the comments > see what the code is supposed to do, and then read in the code that it > progresses correctly. Thanks! diff --git b/etc/logrotate.d/mysql-server b/etc/logrotate.d/mysql-server index 01ab55e..0b2f1ad 100644 --- b/etc/logrotate.d/mysql-server +++ b/etc/logrotate.d/mysql-server @@ -16,9 +16,12 @@ MYADMIN="/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf" if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then # Really no mysqld or rather a missing debian-sys-maint user? - # If this occurs and is not a error please report a bug. - if ps cax | grep -q mysqld; then - exit 1 + # Grab the PID file location from the mysql config + MRUN=$(grep -oP "^pid-file.*= \K[^$]+" /etc/mysql/my.cnf) + if [ -e $MRUN ]; then + MPID=$(cat $MRUN) + # Check if PID is running and compare the name of the running process + kill -0 $MPID && test $(ps -p $MPID -o comm=) = mysqld || exit 1 fi else $MYADMIN flush-logs
Bug#811072: regression in apt-get source to get source when binary has extra debian version
Package: apt Version: 1.1.3 Severity: normal The apt versions since stable have a bug in which apt-get source fails to find the source package when the binary package has additional version information. E.g. the current gdb version in testing 7.10-1+b1. Here are some reproducible steps for a clean version of debian showing that stable (1.0.9) works and testing (1.1.10) does not. The bug report version 1.1.3 also has the error, so the regression happened anywhere between 1.0.9 and 1.1.3. docker -ti --rm debian:{stable,testing} Steps in both containers: echo "deb-src http://httpredir.debian.org/debian testing main" >> /etc/apt/sources.list apt-get update apt-get source gdb/testing stable: root@fd4bd6bde15f:/# apt-cache show apt Package: apt Status: install ok installed Version: 1.0.9.8.1 [...] root@ec1b1e2b13c9:/# apt-get source gdb/testing Reading package lists... Done Building dependency tree Reading state information... Done Selected version '7.10-1' (testing) for gdb NOTICE: 'gdb' packaging is maintained in the 'Git' version control system at: git://anonscm.debian.org/pkg-gdb/gdb.git Need to get 19.2 MB of source archives. Get:1 http://httpredir.debian.org/debian/ testing/main gdb 7.10-1 (dsc) [2756 B] Get:2 http://httpredir.debian.org/debian/ testing/main gdb 7.10-1 (tar) [19.1 MB] Get:3 http://httpredir.debian.org/debian/ testing/main gdb 7.10-1 (diff) [52.5 kB] Fetched 19.2 MB in 1s (13.8 MB/s) testing: root@8d2234fed551:/# apt-cache show apt Package: apt Status: install ok installed Architecture: amd64 Version: 1.1.10 [...] root@84f326c749e0:/# apt-get source gdb/testing Reading package lists... Done Building dependency tree... Done E: Can not find version '7.10-1+b1' of package 'gdb' E: Unable to find a source package for gdb Using the option --only-source works on testing. -- Package-specific info: -- (/etc/apt/preferences present, but not submitted) -- -- (/etc/apt/sources.list present, but not submitted) -- -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable'), (210, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.17.8-64+ (SMP w/32 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages apt depends on: ii adduser 3.113+nmu3 ii debian-archive-keyring 2014.3 ii gnupg 1.4.20-1 ii gnupg2 2.0.28-3 ii gpgv1.4.20-1 ii libapt-pkg5.0 1.1.3 ii libc6 2.19-22bfw1 ii libgcc1 1:5.3.1-5bfw1 ii libstdc++6 5.3.1-5bfw1 apt recommends no packages. Versions of packages apt suggests: pn apt-doc ii aptitude0.7.4-1bfw1 ii dpkg-dev1.18.4 ii python-apt 1.1.0~beta1 -- Configuration Files: /etc/logrotate.d/apt changed [not included] -- no debconf information
Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)
Package: mariadb-server-10.0 Version: 10.0.22-0+deb8u1 Severity: minor Tags: patch Dear Maintainer, The current logrotate script only checks if there is a mysqld process running which it can't connect to. If this is the case the postrotate script exists with 1 causing a mail to be send. I attached a patch which would remedy this situation by checking if the running mysqld process is actually the one we are working with in the logrotate. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (1000, 'stable'), (800, 'testing'), (700, 'unstable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server-10.0 depends on: ii adduser 3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii libaio1 0.3.110-1 ii libc6 2.19-18+deb8u1 ii libdbi-perl 1.631-3+b1 ii libpam0g 1.1.8-3.1 ii libstdc++65.2.1-23 ii lsb-base 4.1+Debian13+nmu1 ii mariadb-client-10.0 10.0.22-0+deb8u1 ii mariadb-common10.0.22-0+deb8u1 ii mariadb-server-core-10.0 10.0.22-0+deb8u1 ii passwd1:4.2-3 ii perl 5.20.2-3+deb8u1 ii psmisc22.21-2 ii zlib1g1:1.2.8.dfsg-2+b1 Versions of packages mariadb-server-10.0 recommends: ii libhtml-template-perl 2.95-1 Versions of packages mariadb-server-10.0 suggests: ii bsd-mailx [mailx] 8.1.2-0.20141216cvs-2 pn mariadb-test pn tinyca -- Configuration Files: /etc/logrotate.d/mysql-server changed [not included] -- debconf information excluded diff --git a/etc/logrotate.d/mysql-server b/etc/logrotate.d/mysql-server index 01ab55e..567c27b 100644 --- a/etc/logrotate.d/mysql-server +++ b/etc/logrotate.d/mysql-server @@ -17,8 +17,10 @@ if [ -z "`$MYADMIN ping 2>/dev/null`" ]; then # Really no mysqld or rather a missing debian-sys-maint user? # If this occurs and is not a error please report a bug. - if ps cax | grep -q mysqld; then - exit 1 + MRUN=$(grep -oP "pid-file.*= \K[^$]+" /etc/mysql/my.cnf) + if [ -e $MRUN]; then + MPID=$(cat $MRUN) + kill -0 $MPID && test $(ps -p $MPID -o comm=) = mysqld || exit 1 fi else $MYADMIN flush-logs
Bug#807310: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager
> Examples of what I mean: dz.po ug.po sl.po ro.po ps.po pa.po nb.po The files still contain the author information in the po header. They are just missing in the file header. I'll report it upstream anyway so he can add the information to the file header. > It isn't about scientific references, that is a common misconception. > > At least these fields are probably applicable: > > Bug-* > Changelog > Contact > Name > Repository > Repository-Browse > Screenshots > Security-Contact Yes. Those fields can be filled out, but technically the information is already available in debian/control and debian/copyright. Especially in cases of Github and other code hosting sites most of these entries would be the same. I added it anyway as it doesn't really require that much extra work in the end. Well. Thanks again. I have some upstream reporting to do now to get this package into better state, though I think it's already in a good enough state for debian as of now. Lennart
Bug#807310: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager
Thank you for the extensive review. I went through your suggestions/comments and either fixed them or mentioned them here. > I don't think the package descriptions should describe NetworkManager, > that is a job for the network-manager package description. Instead, > they should describe the network-manager-ssh packages. I know it's weird and somewhat unusual but all the other nm plugins do the same. So I went with it: http://anonscm.debian.org/cgit/pkg-utopia/network-manager-openvpn.git/tree/debian/control http://anonscm.debian.org/cgit/pkg-utopia/network-manager-pptp.git/tree/debian/control http://anonscm.debian.org/cgit/pkg-utopia/network-manager-vpnc.git/tree/debian/control > It would be great if there were a DEP-8 test: > > http://dep.debian.net/deps/dep8 > http://ci.debian.net This would definitely be a nice-to-have but it would require a decent test in the source package or writing one myself. As of now the test under test/ really doesn't do much. It basically just setups the env to actually start testing. So I'd say its more of a long term goal. > I always wonder if screenshots like images/*.png should be generated > at build time so they never get out of date. Screenshots don't change all that often and even if they are slightly out-of-date most people won't care. I'd say many just check the screenshots to check if its a GTK1 application last maintained in the 90s. > I wonder what "PCF" in the icon means, probably it would be better to > have "SSH" in there? The icon seems to be from nm-pptp. But even there it doesn't really make sense. So I guess the icon went x -> pptp -> openvpn -> ssh. > Upstream's po files look like they have poorly maintained or > unmaintained copyright headers. Most of them seem alright to me. A few have missing source package information but that information is available in debian/copyright anyhow. The translators seem to be attributed in all of them. > Upstream's test suite is using an IP address belonging to the USA > Department of Defence. I would strongly suggest using a proper private > IP address according to RFC 6761. > > http://tools.ietf.org/html/rfc6761 inetnum:1.1.1.0 - 1.1.1.255 netname:APNIC-LABS descr: Research prefix for APNIC Labs address:South Brisbane, QLD 4101 address:Australia e-mail: ab...@apnic.net I know you are not supposed to use these. But the test is not executed and won't be unless upstream changes it as it is useless right now. > Please add some upstream metadata: > > https://wiki.debian.org/UpstreamMetadata Following the links on the page it seems to be mostly used by scientific libraries to reference algorithms used in the packages. All the basic repository/issue/copyright information is already present in other files in my current version. > Automated checks: > > check-all-the-things: > $ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not > find or open any of the paths given.' > [properties/nm-ssh.c:1287]: (error) Possible null pointer dereference: gateway > [properties/nm-ssh.c:1289]: (error) Possible null pointer dereference: > remote_ip > [properties/nm-ssh.c:1290]: (error) Possible null pointer dereference: > local_ip > [properties/nm-ssh.c:1291]: (error) Possible null pointer dereference: netmask > [properties/nm-ssh.c:1316]: (error) Possible null pointer dereference: > preferred_authentication > $ flawfinder -Q -c . > I'll report these upstream as these check seems to be of valid concern. Not security wise but to avoid errors. Thanks again, Lennart Weller
Bug#807310: RFS: network-manager-ssh/0.9.4-1 [ITP] - ssh vpn for network manager
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "network-manager-ssh" * Package name: network-manager-ssh Version : 0.9.4-1 Upstream Author : Dan Fruehauf * URL : https://github.com/danfruehauf/NetworkManager-ssh * License : GPL-2+ Section : net It builds those binary packages: network-manager-ssh - network management framework (SSH plugin core) network-manager-ssh-gnome - network management framework (SSH plugin GNOME GUI) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/network-manager-ssh Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/network-manager-ssh/network-manager-ssh_0.9.4-1.dsc More information about hello can be obtained from https://github.com/danfruehauf/NetworkManager-ssh Changes since the last upload: * Initial release. (Closes: #725396) Regards, Lennart Weller
Bug#725396:
This sounds like a nice plugin. I would package it if nobody else is working on it.
Bug#806415: mycli: No way to execute the query
This is indeed a weird bug. It completly ignores all control characters. Even though pgcli uses almost exactly the same code and works fine. I marked the bug as critical for now as it makes mycli impossible to use. November 27 2015 10:06 AM, "François Gannaz" wrote: > Package: mycli > Version: 1.5.2-1 > Severity: important > > Dear Maintainer, > > Launching `mycli mydb` connects to the DB and I am able to write a SQL > query with proper completion. Yet I cannot execute it. > > Placing `;` at the end of the line is ineffective. Pressing Enter or > Ctrl-j has no visible consequence. I tried several times with Smart > completion off, Multiline off, and vi mode, but it had no effect on > this. > > Incidently, I could not execute "quit" so I had to kill mycli.
Bug#806400: ImportError: No module named 'pkg_resources'
Sorry. Should have been python3-pkg-resources. Haven't had my coffee yet. November 27 2015 9:41 AM, "Max Kellermann" wrote: > On 2015/11/27 09:34, Lennart Weller wrote: > >> Could you try reinstalling pkg-ressources? >> sudo apt-get install --reinstall python-pkg-resources >> >> The line from your stacktrace is not in the source code of pgcli. > > Problem persists. > > # apt-get install --reinstall python-pkg-resources > Reading package lists... Done > Building dependency tree > Reading state information... Done > 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not > upgraded. > Need to get 0 B/99.4 kB of archives. > After this operation, 0 B of additional disk space will be used. > (Reading database ... 353573 files and directories currently > installed.) > Preparing to unpack .../python-pkg-resources_18.4-2_all.deb ... > Unpacking python-pkg-resources (18.4-2) over (18.4-2) ... > Setting up python-pkg-resources (18.4-2) ... > > # pgcli > Traceback (most recent call last): > File "/usr/bin/pgcli", line 5, in > from pkg_resources import load_entry_point > ImportError: No module named 'pkg_resources'
Bug#806400: ImportError: No module named 'pkg_resources'
Could you try reinstalling pkg-ressources? sudo apt-get install --reinstall python-pkg-resources The line from your stacktrace is not in the source code of pgcli. Lennart November 27 2015 8:51 AM, "Max Kellermann" wrote: > Package: pgcli > Version: 0.20.1-1 > > # pgcli certdb > Traceback (most recent call last): > File "/usr/bin/pgcli", line 5, in > from pkg_resources import load_entry_point > ImportError: No module named 'pkg_resources'
Bug#806311: RFS: s3backer/1.4.2-1 [ITP]
Hey again, > Please help to update the license file for s3backer.spec.in. I added the license information to the copyright file. As it is not part of the final binary or included in the package itself there should be no license compatibility issues between the GPLv2 source and this APL-2 documentation file. Lennart
Bug#806311: RFS: s3backer/1.4.2-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "s3backer" * Package name: s3backer Version : 1.4.2-1 Upstream Author : Archie L. Cobbs * URL : https://github.com/archiecobbs/s3backer * License : GPL-2+ with OpenSSL exception Section : misc It builds those binary packages: s3backer - Amazon AWS S3-backed virtual hard disk device To access further information about this package, please visit the following URL: http://mentors.debian.net/package/s3backer Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/s3backer/s3backer_1.4.2-1.dsc More information about s3backer can be obtained from https://github.com/archiecobbs/s3backer Changes since the last upload: * Initial release. Regards, Lennart Weller
Bug#794250: pgcli packaging progress
Hey, I already finished the packaging a while back when pgcli didn't need pgspecial yet. I just updated my version to 0.20.1 and added a reference to your package in my git[1] and also added the git-dpm stuff. My normal sponsor is currently really busy and I myself was too, so I hadn't looked for someone else to sponsor it. I would prefer uploading it to collab-maint git and in case it is still a requirement for PAPT then do a subversion export from there. So to answer your questions. Still interested in maintaining or co-maintaining pgcli but I do need a sponsor for it. I also need one for mycli in case you are interested (same developer just mysql/mariadb). Lennart [1] https://git.ring0.de/debian/python-pgcli November 23 2015 5:15 PM, "ChangZhuo Chen" wrote: > Hi Lennart, > > Are you still interesting in pgcli packaging? I am working on its > dependency python-pgspecial [0], and it will be ready once the upstream > fix the license issue [1]. > > Please let me know if you need help or sponsor. > > [0] https://bugs.debian.org/805882 > [1] https://github.com/dbcli/pgspecial/issues/7 > > -- > ChangZhuo Chen (陳昌倬) > Debian Developer > Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D
Bug#799776: Had a look into it
It looks like MySQL 5.6 and MariaDB 10.0 are more restrictive with LOAD LOCAL INFILE. At least for 3/4 of the failing tests that will be the issue. One option seems to be adding this to the my.cnf and loading it for the tests: [client] loose-local-infile = yes For the other failure I am not certain. Seems a bit odd to me that it complains about the characters even with a string marked as unicode. October 9 2015 11:55 AM, "Thomas Goirand" wrote: > Hi Lennart, > > I had a look into updating the package. It is updated in the Git > repository, however, there's 2 unit tests that are failing. Would you > have time to look into it? > > Cheers, > > Thomas Goirand (zigo)
Bug#799776: python-pymysql: Update package to 0.6.6 or newer to satisfy the mycli dependency
Package: python-pymysql Version: 0.6.2-2 Severity: wishlist Dear Maintainer, I am currently working on getting mycli into debian. The current dependency is on version 0.6.6 or newer. I have tried some work arounds to get it to work with 0.6.2 but there seem to be some issues with connection closure which cause mycli to break. More on that in the bugtracker on Github[0]. I might be able to get this to work but the overall best solution would be the update to 0.6.6 [0] https://github.com/dbcli/mycli/issues/155 -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (1000, 'stable'), (800, 'testing'), (700, 'unstable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-pymysql depends on: ii dpkg1.17.25 ii python 2.7.9-1 python-pymysql recommends no packages. Versions of packages python-pymysql suggests: pn python-pymysql-doc -- no debconf information
Bug#794251: need to update python-pymysql ?
Potentially yes. I'm currently trying to get it to work with 0.6.2, if you want you can follow that progress on the github tracker[0]. Otherwise I will have no choice but to ask the PyMySQL-maintainers to update the debian version. Lennart [0] https://github.com/dbcli/mycli/issues/155 September 22 2015 12:30 PM, j...@free.fr wrote: > Traceback (most recent call last): > File "/usr/bin/mycli", line 5, in > from pkg_resources import load_entry_point > File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2876, in > > working_set = WorkingSet._build_master() > File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 451, in > _build_master > return cls._build_from_requirements(__requires__) > File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 464, in > _build_from_requirements > dists = ws.resolve(reqs, Environment()) > File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 639, in resolve > raise DistributionNotFound(req) > pkg_resources.DistributionNotFound: PyMySQL>=0.6.6
Bug#794452:
If I can help you out with that let me know. September 4 2015 9:55 AM, "Andrii Senkovych" wrote: > Hi, Lennart > > I'm sorry for the late reply. I'll update the packages during this > weekend. Thank you! > > 2015-09-04 10:01 GMT+03:00 Lennart Weller : > >> I keep updating the packages and newer versions now require 0.1.16. >> If you'd like I could help out with updating the package.
Bug#790317: Patch applied upstream
Are you able to check the ARM64 support somewhere? I have feedback from upstream about some of the errors and added a few "fixes" to the package since then. You can checkout the newest version of the package from alioth[1]. You can build it with gbp or just dpkg-buildpackage. Lennart [1] http://anonscm.debian.org/cgit/collab-maint/nvidia-texture-tools.git/ July 31 2015 3:21 PM, "Lennart Weller" wrote: > I upgraded my local version of the texture tools. The git Version has some > serious bugs right now. > The included test suite fails with lots of segfaults if it runs at all. > Also the current version according to the version file is 2.1.0 but there is > no such tag in the > repo. This will probably require some additional patches to get it working on > even the supported > platforms. > > I'll get back to you > > On 23 July 2015 16:56:12 CEST, Lennart Weller > wrote: > >> So far I only tested the building and compress/decompress functionality >> in a QEMU VM with arm64. But now that it is upstream I might as well >> just update the package to a newer git version. A lot of patches in the >> current package were included in the upstream version by now and >> homepage etc has changed too. >> >> On 21.07.2015 02:34, Martin Michlmayr wrote: >>> tags 790317 + fixed-upstream >>> thanks >>> >>> The patch got applied today: >> >> https://github.com/castano/nvidia-texture-tools/commit/58617584d4d2541ff9fcfe23a9a492af86b11efb >>>
Bug#794452:
I keep updating the packages and newer versions now require 0.1.16. If you'd like I could help out with updating the package.
Bug#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device
September 1 2015 5:27 PM, "Nikolaus Rath" wrote: > Why compare it with something that has been unmaintained for years and is > not even in Debian? (Leaving alone the fact that there are at least 3 > projects calling themselves s3fs, but AFAIK they're all in similar > states). > > Contrasting it with something like S3QL would probably be more helpful > :-). As you said there are three different projects with the name s3fs. But the one I was referring to, s3fs-fuse[1], is actively maintained while s3fs (python)[2] and s3fslite[3] are not. The name doesn't really matter though as the approach of all of them and S3QL is pretty much the same. Create an S3 based filesystem. s3backer on the other hand exposes just a single "block" device to the system and allows common filesystems to be used on top of it. I kinda like that approach so I went with it. Cheers, Lennart Weller [1] https://github.com/s3fs-fuse/s3fs-fuse [2] https://fedorahosted.org/s3fs/ [3] https://github.com/russross/s3fslite
Bug#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: s3backer Version : 1.4.1 Upstream Author : Archie L. Cobbs * URL : https://www.github.com/archiecobbs/s3backer * License : GPL, OpenSSL Programming Lang: C Description : Amazon AWS S3-backed virtual hard disk device s3backer is a filesystem that contains a single file backed by the Amazon Simple Storage Service (Amazon S3). The blocks of the file are stored as S3 objects. This way s3backer acts as a virtual hard disk device. s3backer also offers encryption as part of the VHD. s3backer offers some great benefits over s3fs as any filesystem can be used on top of the VHD removing all inconsistencies which might occur with a naive implementation of a filesystem. Currently there is a license conflict between the GPL code and OpenSSL. I have forwarded some of the common solutions to the upstream author.
Bug#760473: Further analysis and a patch
August 11 2015 7:54 PM, "David Kalnischkies" wrote: > apt does not link indirectly to libnettle nor to libcurl-gnutls. The > optinal apt-transport-https does. That is a big difference for > bootstrappers as it means they can ignore -https for the time being > until the base system is up and running and can then be used to build > "proper" packages. I was indeed wrong about that assumption. wget on the other hand, which is marked important and part of the base system, is linked against libnettle. So the library will most likely exist on all but the most minimal systems on which the base system is not defined by the debian policy. > So, big thanks for the patch, but I have to pull the marker as we can't > apply it as is. What could be done maybe is dlopen libnettle (and/or > others if available) and use them and otherwise fallback to our own > slower but always available code. We could then Recommends libnettle and > make everyone happy, I guess… just, libnettle seems to be a bit too > unstable in its ABI, which is another problem with this patch ATM as > every ABI break in nettle means we are required to make one in > libapt-pkg, too, entangling use in their transition… > Caused by e.g. SHA256Summation having a struct sha256_ctx member, which > could have a size change in a newer libnettle abi, so the size of > SHA256Summation would change, too (that could be avoided through via the > use of a d-pointer). I get your point but the wget authors did consider it to be stable enough to include it in their software. I might have a look at rewriting the patch as a dynamically linked version. In which case I could also add openssl, which is also part of the base system, as second fall-back. > >> In the process of finding the culprit I also replaced the http method >> with a new version using libcurl. Similiar to the https method. This >> change does not provide any measurable speed boost as of yet, as the >> whole process is still waiting for the hashing to complete. I attached >> the patch nonetheless as it removes a lot of redudant code. > > Same problem. http is in apt directly as 99% of all mirrors are > http-only, so it is how you usually operate apt, -https is used by… > very few people/mirrors. > I'll probably won't have a second look at this patch as it brings almost no benefit to the table at the current point in time. It just made the HTTP implementation a lot more stable. Regards, Lennart
Bug#794562: 0ad: Test 0ad with new version of nvidia-texture-tools
I went through all the added patches and removed all those which were already included in upstream. That left me with mostly debian related patches[0] which he doesn't want applied upstream. issue188 - still have that one clang-cpp11 - doesn't really apply to debian but I will probably include it anyhow to avoid any future bugs. or report it upstream to get it added to a release rpath - don't think that applies to dynamic libraries and therefore this package cmake-dev* - those patches basically just add some switches to look for certain libraries. i think we can work with upstream here as we only built with a dfsg setup on debian which means no cuda or cg anyway. I'll try to get upstream to release a new version of nvtt so I can get a clean release for the new package. [0]http://anonscm.debian.org/cgit/collab-maint/nvidia-texture-tools.git/tree/debian/patches On 2015-08-07 03:16, Vincent Cheng wrote: On Thu, Aug 6, 2015 at 6:06 PM, Vincent Cheng wrote: Here's some feedback from upstream (freenode #0ad-dev): s/freenode/quakenet/ of course -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#794562: 0ad: Test 0ad with new version of nvidia-texture-tools
Package: 0ad Severity: wishlist Dear Maintainer, Could you test 0ad with the new nvidia-texture-tools version I uploaded to collab-maint[0]? My experience with the package tells me that it might break something. The updated package also includes the ARM64 support added by Martin Michlmayr which is now in upstream. Lennart [0] http://anonscm.debian.org/cgit/collab-maint/nvidia-texture-tools.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#794570: ITP: python-prompt-toolkit -- Python library for building interactive command lines
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: python-prompt-toolkit Version : 0.45 Upstream Author : Jonathan Slenders * URL : https://github.com/jonathanslenders/python-prompt-toolkit * License : BSD-3-clause Programming Lang: Python Description : Python library for building interactive command lines prompt_toolkit is a GNU readline replacement written in pure Python supporting advanced features like syntax highlighting, multi line editing and code completion. The package is a dependency of pgcli and mycli (#794250, #794251) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#793249: innoextract: change of type in system_error might break with GCC-5
tags 793249 + confirmed This will most likely be an issue if I undertood the issue correctly. On 2015-07-22 15:33, Matthias Klose wrote: Package: src:innoextract Severity: important Tags: sid stretch User: debian-...@lists.debian.org Usertags: gcc-pr66145 GCC PR libstdc++/66145 is a regression in GCC 5 which won't be fixed upstream in time for the GCC defaults change. The work around is to rebuild the affected packages after GCC 5 is the default compiler. Please look at the code and decide, if the package is affected. If not, please just close the issue. If it's a real issue, I'll add the packages affected to libstdc++6's Breaks attributes, with the version of the package at the time of the defaults change. See https://wiki.debian.org/GCC5#libstdc.2B-.2B-_c.2B-.2B-11_incompatibilities_.284.9_and_5.29 for further information. To build with GCC 5,install the gcc, g++, gfortran, ... packages from experimental (apt-get -t experimental install g++). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#794452: python-sqlparse: Please update package to 0.1.14 or higher to satisfy pgcli/mycli dependency
Package: python-sqlparse Version: 0.1.13-2 Severity: wishlist Dear Maintainer, Please update the package to version 0.1.14 or the newest version 0.1.16 to satisfy the dependencies of the packages I am currently building for debian, pgcli (#794250) and mycli (#794251). Greetings, Lennart Weller -- System Information: Debian Release: 8.1 APT prefers stable APT policy: (1000, 'stable'), (800, 'testing'), (700, 'unstable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#794251: ITP: mycli -- CLI for MySQL/MariaDB with syntax highlighting and completion
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: mycli Version : 1.0.1 Upstream Author : Amjith Ramanujam * URL : http://mycli.net * License : BSD-3-clause Programming Lang: Python Description : CLI for MySQL/MariaDB with syntax highlighting and completion This is a MySQL/Mariadb client that does auto-completion and syntax highlighting. The CLI is also capable of pretty printing tabular data Reasons for ITP: Usefuly utility for people who like to do their SQL work on the Shell. I intend to maintain this with either sponsorship from PATP or my personal sponsor. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#794250: ITP: pgcli -- CLI for PostgreSQL with syntax highlighting and completion
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: pgcli Version : 0.18.0 Upstream Author : Amjith Ramanujam * URL : http://pgcli.com/ * License : BSD-3-clause Programming Lang: Python Description : CLI for PostgreSQL with syntax highlighting and completion This is a PostgreSQL client that does auto-completion and syntax highlighting. The CLI is also capable of pretty printing tabular data Reasons for ITP: Usefuly utility for people who like to do their SQL work on the Shell. I intend to maintain this with either sponsorship from PATP or my personal sponsor. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790317: Patch applied upstream
I upgraded my local version of the texture tools. The git Version has some serious bugs right now. The included test suite fails with lots of segfaults if it runs at all. Also the current version according to the version file is 2.1.0 but there is no such tag in the repo. This will probably require some additional patches to get it working on even the supported platforms. I'll get back to you On 23 July 2015 16:56:12 CEST, Lennart Weller wrote: >So far I only tested the building and compress/decompress functionality >in a QEMU VM with arm64. But now that it is upstream I might as well >just update the package to a newer git version. A lot of patches in the >current package were included in the upstream version by now and >homepage etc has changed too. > >On 21.07.2015 02:34, Martin Michlmayr wrote: >> tags 790317 + fixed-upstream >> thanks >> >> The patch got applied today: >> >https://github.com/castano/nvidia-texture-tools/commit/58617584d4d2541ff9fcfe23a9a492af86b11efb >> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790317: Patch applied upstream
So far I only tested the building and compress/decompress functionality in a QEMU VM with arm64. But now that it is upstream I might as well just update the package to a newer git version. A lot of patches in the current package were included in the upstream version by now and homepage etc has changed too. On 21.07.2015 02:34, Martin Michlmayr wrote: > tags 790317 + fixed-upstream > thanks > > The patch got applied today: > https://github.com/castano/nvidia-texture-tools/commit/58617584d4d2541ff9fcfe23a9a492af86b11efb > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#792275: debian-maintainers: Please add Lennart Weller as Debian Maintainer
Package: debian-maintainers Severity: normal Dear Maintainer, Please add me, Lennart Weller , to the Debian Maintainers keyring. You can find the jetring changeset in the attachment. Thank you for your attention, Lennart Weller Comment: Add Lennart Weller as a Debian Maintainer Date: Mon, 13 Jul 2015 00:48:11 +0200 Action: import Recommended-By: Sebastian Reichel Agreement: https://lists.debian.org/debian-newmaint/2015/07/msg00017.html Advocates: https://lists.debian.org/debian-newmaint/2015/07/msg00018.html Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBFSgTFYBEADl0Ft9mQpsQu3CaKts05E1uZvbkeINt2BVBeZ02DoGWTK30Az+ HeY34NB+QRf0Cydrv62C6b54xQw9kDkLu5+Y6WVKxZLip5fVzKWsWa79LwZXof8s 0SHcSHAhKujABbyKawINiWm/Scm/8GA6sJgaKv21Ad6SQxRsMs533hjoB590ja9V +pXIXbNeAdJ5swhztVEvyD7OKkuVuzPgD3GIXsa85Hsikv6aJcal8DhBp20/qsuW qSNfK4R0JN3JXiIf4lwnA0Vyx0ONHrtKC0Opaf7p81r8XUPfRtd7CDyhiJoTt09c /Zx0r9710a4COYaBW/HyithcfkyLAl6V4OEl2doJlNmbyamaniAD1Y/TJ04wR9F3 jIC3s/hL07TSgeiD6QoSUfwt/yIRqTFY7t5F5DWR3XAv+HVH8pdwRAxMGHc/4HDA O3PycU01Heiq7epu6auPR7uBUz1Wm/tl9QO433Yt2U52v4sHNXBXfj1cmPq5TSKx Zncm+Kly+rbGzofpWm25f5A91Ocni+Ra50ZZe7fU/VDy0qhh+GC3BsbgiBr1Q7vT oTxmAc7sbCvY8V3lzCA5aMnDq+1rm1EBs8DcjsCP1YWREgHYRT2TU+3o69+Qq9kj p9q2gKImdtE+1cd9vVB+hs02u4rtPPBcf6X/KeFcPF15JOy495TijoryBQARAQAB tDNMZW5uYXJ0IFdlbGxlciAoUGFja2FnZSBzaWduaW5nIGtleSkgPGxod0ByaW5n MC5kZT6JAj0EEwEKACcFAlSgTFYCGwMFCQlmAYAFCwkIBwMFFQoJCAsFFgMCAQAC HgECF4AACgkQ9IUzG6Y/ivIsuRAArYOdWGPRx5OJ3QPG71cEqzLoKM6zqVo/c68D HFh6KQTDf9dId/WaKxy2YtgUzoyJEkZ9lP0CwFXMYkLeQlexHbdZBwcz08NIs4DE v4h9wyOWKGB/Zv5yNiJ+J0v8G/b9gP+mmU5Q4BpMrr2ZZP9xztZ3G/Mqk7TYlbJ2 WC36MVaDF9TVJKaDILoUQgnWUOuC/zfapNZMQokBzzWRmV6IZsWvB5RBKBOZFcLv uLcn/kS38HQr9gCHlNsbWE8RFY6E0YcPRY7OyybA850y0y7yfho383fjsCzVmdbL sPrE+yp3+bRmr0Uy+qvXZ3k1gvRRnZsKPHYGMBB5c9bWcd6tC7bjsR+100t8DnX2 vpNaT0RgqiTVdxyzhSPtOv4Q4iIw4AeYIwBa6HMs5CvXp2oYmjVSwy0pax/up/cl 31losf1k/rmN2X8AnZlKN5Nb/eVku/lI8C5yagul4lLTQKkok49D8KAAUC6n6CVH lM4CCkZaxz3G8rSv2NMrsYVy0Qs3elJhyc5N0msdjKtp75DVunDjknEcB6An6+07 gYbgrNHFXrhUAlP7ZXBLNBOeMjWFB6+32IyEOZcm/qs37UlJo2WNULC2Lyma7sw0 SdPMUWZ5gwDL8T8JdU/tIhLmj3GXnZE3fiqaiew3ONAgUmrfVRFqFZZen9BYzjRE cktN6oS5Ag0EVKBMVgEQAMCMFbn17wFRNkMSKHRumCT+wzuu3RzbvSXKfgrfdXlA R16ujI48E2pouXEMQlsZ6Gqj4Zp9FhL90Zr3O2RA1bm5e/ZVkqyTlsBNdmZUP6zB FicdbxDCuLLibzfhplRVnvI899LTZffH+oCBhuPDpyOZpQtv8Ycp9QxYXc6I+6a/ 471thbyiIZ7+yU+QyKf1boalo7IGHcMLVRnSA82VdHbZuViGRQxB7TUbPwAFlHir 7e3jccwAtXfDkGdIL3DURKYGOePoBx83yUCVEUkEo96FBNcBPdiGalJ753L6Cc8A 5lDEsftcS7Nk3brgfoK49Rkmzzz8lAGIVJgXLSnU9YTCwCfBXguc0ZE+RWGy5ywq VM26bLDoSiOIZ8K6RHgblxM2/CrwHpTTXEllBsVaxJAE5DWCAC2pU6nsfTuOGgpq 6y2e0YXCdBky4zyp+yfqtHgAXORKmVxtdmnTi4l9lJqZm/vPIn6gAKQUX4XezbHg Y65bKBf1VWLCzEBUn9nuElQD6vA/9zyLd8IZHMVAh/OTFWoAFYoivRPWjWUNR3l2 vQzTDXpbPO2OL3BGBlt28tIGKSLEFuAlCUZxjx0IC8faeJAgFqZFGKCvFNUChFmk DvBhuCQNnTA2q6Ip55YgVI/n3KCsSdE7v3iXjXIEf2s5cKTYzFJ4IUcEbppHQ8+l ABEBAAGJAiUEGAEKAA8FAlSgTFYCGwwFCQlmAYAACgkQ9IUzG6Y/ivJC1RAAi97N 8gwKMWA0BI8MGjE/kc2k8Ls1sRK7aeMug0FCqz+yBt0iaGCj3y+nXpu3mDuGhPeT lvwEllIXWDq2ffXuGCVHL0aVM55plboRNpmweVe8QJJkQ4LVVJG1pavHZGngNT2u Dfc8jri7p4LCCRuoB1ZsXgdZfJzdb/GhK3gGqBtFPogyvH61PgHQmkC5bsVM+Ek3 Ej5ftK1FDf+GnECK9ICKhP8saKDfsVs2C84wADkJ+mIAGMiUqOcVw+Xc7336wh+h yHvVdA0/cb6fcyvo4ch7rf3kJz3SNIulCGNUjVoeAWJTKly90XLBKuJFg2FxHHlL M82L+BUyNmyxxenk1bhWWTVmTWw34X3Df+CdVMSNZ9FmBHNAtJqqtuFht1BVRG+4 p1B6pZlw8E+TM1mbERIETe6UXgrCDWjDvQmcjPpXR0LSIM7aPVlBzAjC1ZAlkO7J 4FL9YoommwqDxzurVbjiZwD6qUUrfWzCQXGknZHEKU7WIUqaETmdPqrqX/ihfweD K2I+kTcbJtvUdJvo4XXLL6QeT23sdxa7sfWUxXBSLJ0BPLPOP9TCc5/fYtj+4ph6 arORISxy398753ETNA5h0tEUOCKNXuMyIny9Cg1nInd/pzMANXx9xeHY0yu0FlEc Kop9Q8CFGjJVGDjeBYPg2gIo/HnieLnJQkaCa9k= =QPmD -END PGP PUBLIC KEY BLOCK-
Bug#792228: ITP: termdebug -- Tools for recording and replaying terminal I/O
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: termdebug Version : 2.2 Upstream Author : G.P Halkes * URL : http://os.ghalkes.nl/termdebug.html * License : GPL-3 Programming Lang: C Description : Tools for recording and replaying terminal I/O Termdebug is a set of utilities to record and replay the input and output of terminal programs. Its main goal is to aid in developing and debugging terminal programs. Similar to termrec/termplay and nethack-recorder/player, neither of which is packaged for debian, but also records terminal input. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#790317: Please add ARM64 support
I might do some testing on the debian test boxes for arm64 over the weekend and include it as patch. From my experience with nvtt it might take a while for a patch to be added to upstream. Lennart On 2015-06-28 02:02, Martin Michlmayr wrote: forwarded 790317 https://github.com/castano/nvidia-texture-tools/issues/224 thanks I forwarded it to https://github.com/castano/nvidia-texture-tools/issues/224 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763486: Acknowledgement (nvidia-texture-tools: Please change build dependency to libjpeg-dev (libjpeg-turbo transition))
Did you rebuild the nvidia-texture-tools on your PC? Because the library in the package is only linked against jpeg.so.62. Because of the way cmake includes the jpeg libraries right now it will probably include both if it finds them. I will fix the build process over the next days to avoid this. Lennart Am 05.10.2014 19:10, schrieb Yasushi SHOJI: On Sat, 04 Oct 2014 16:54:21 +0200 Lennart Weller wrote: I quickly tested the compression/decompression and use of the library in games with the libjpeg-turbo and couldn't find any faults. The new version is now available in unstable. Just rebuilt 0ad with new libnvtt2:amd64 installed and I see the following message when linking: /usr/bin/ld: warning: libjpeg.so.62, needed by /usr/lib/x86_64-linux-gnu/libnvtt.so, may conflict with libjpeg.so.8 ldd on libnvtt.so.2.0.8 shows me that the version 2.0.8-1+dfsg-5 of it is linked against both libjpeg62 and libjpeg.so.8. Is this norm? Thanks, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760473: apt method http uses 100% cpu with high transfer rate
Package: apt Version: 1.0.7 Severity: normal Dear Maintainer, The current implementation of the http method puts a much higher load on the CPU than a similar call done in wget or curl. As an example I downloaded a large file from the deb mirror (0ad-data) which is then cached by local squid. Which in turn then provides higher transfer rates in case I download it again and causing this bug to appear: cli: % apt-get download 0ad-data Get:1 http://ftp.de.debian.org/debian/ jessie/main 0ad-data all 0.0.16-1 [530 MB] 46% [1 0ad-data 247 MB/530 MB 46%] 24.6 MB/s 11s top: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 8516 weller20 05516 4200 3944 R 99.4 0.0 0:04.60 http For comparison the same download with wget: cli: % wget http://ftp.de.debian.org/debian/pool/main/0/0ad-data/0ad-data_0.0.16-1_all.deb (58.5 MB/s) - '0ad-data_0.0.16-1_all.deb' saved [530253138/530253138] top: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 12578 weller20 05992 4104 3712 R 18.2 0.0 0:00.57 wget As you can see from these lines the download is capped by the http method to almost 40% of the transfer rate due to the single core CPU usage. My guess is that this problem stems from the circular buffer design used in the http method which might've provided a speed boost back in the day but hinders it now. /proc/cpuinfo: processor : 31 model name : Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz cpu MHz : 2328.042 -- Package-specific info: -- (/etc/apt/preferences present, but not submitted) -- -- (/etc/apt/sources.list present, but not submitted) -- -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (550, 'testing'), (500, 'stable'), (210, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.15.3-64+ (SMP w/32 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages apt depends on: ii debian-archive-keyring 2012.4 ii gnupg 1.4.18-2 ii libapt-pkg4.12 1.0.7 ii libc6 2.19-9bfw1 ii libgcc1 1:4.9.1-4bfw1 ii libstdc++6 4.9.1-4bfw1 apt recommends no packages. Versions of packages apt suggests: pn apt-doc ii aptitude0.6.11-1bfw1 ii dpkg-dev1.17.13 ii python-apt 0.9.3.9 -- Configuration Files: /etc/logrotate.d/apt changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730524: innoextract: Please update to version 1.4
Hey, The 1.4 release was made in March _2013_ and I read the changelog which didn't have any interesting new features in my opinion. I updated the collab-maint git with the 1.4 nevertheless and will have it uploaded in the next days to unstable. Cheers, Lennart On 26.11.2013 06:59, Stephen Kitt wrote: > Package: innoextract > Version: 1.3-1+b1 > Severity: wishlist > > Dear Maintainer, > > innoextract 1.4 was released in March 2012. Would it be possible to > update the Debian package? > > Thanks, > > Stephen > > > -- System Information: > Debian Release: jessie/sid > APT prefers testing > APT policy: (500, 'testing'), (500, 'stable'), (200, 'unstable'), (1, > 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages innoextract depends on: > ii libboost-filesystem1.54.0 1.54.0-2 > ii libboost-iostreams1.54.01.54.0-2 > ii libboost-program-options1.54.0 1.54.0-2 > ii libboost-system1.54.0 1.54.0-2 > ii libc6 2.17-93 > ii libgcc1 1:4.8.2-1 > ii liblzma55.1.1alpha+20120614-2 > ii libstdc++6 4.8.2-1 > > innoextract recommends no packages. > > innoextract suggests no packages. > > -- no debconf information > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#716713: libtxc-dxtn-s2tc0: S2TC_REFINE_COLORS=ALWAYS (default) creates broken edges
Coming back to this issue as it appearantly won't be fixed upstream anytime soon, does the LOOP fix the issue? Or does it produce new issues? If it works out I could just temporarily set the default to LOOP for the debian package. Lennart Am 11.07.2013 18:36, schrieb Schrober: > Package: libtxc-dxtn-s2tc0 > Severity: normal > Version: 0~git20121227-1 > Forwarded: https://github.com/divVerent/s2tc/issues/2 > X-Debbugs-CC: divver...@xonotic.org > > The default setting which enables color refinement causes edges towards alpha > to get a weird "broken pixel" effect. > > To reproduce: > > convert input.png input.tga > export S2TC_REFINE_COLORS=ALWAYS > s2tc_compress -i input.tga -o output.dds -t DXT5 > convert output.dds output.png > s2tc_decompress -i output.dds -o output.tga > > Input and output image are attached (you may need to scale it to see the 1 > pixel line problem on the bottom and right side). This problem doesn't happen > with libtxc_dxtn.so from an actual S3TC implementation like > http://cgit.freedesktop.org/~mareko/libtxc_dxtn/ and doesn't happen when > disabling S2TC_REFINE_COLORS by setting it to export > S2TC_REFINE_COLORS=NEVER. > It is important to understand that S2TC_REFINE_COLORS=ALWAYS is always > enabled > by default and the user has to deactivate it manually. Maybe it is better to > change it to S2TC_REFINE_COLORS=LOOP by default? > > This problem was introduced in one of those commits: > d7caf4ce1bd5df6c98a1a59a122a4a63d9916bd7 > 35e0718f1325a482cdf2795d054f3f49779747a6 > 38acfdc032ae17ac97bb547dfae89ad6160ee798 > b3f0fb2b88f700d5e32b3f7e2ac004c3f51121df > > I think 38acfdc032ae17ac97bb547dfae89ad6160ee798 ("alpha 0 pixels are always > important (think color filtering, unexpected blend functions)") caused the > problem because compiling it with the lap fix from > b3f0fb2b88f700d5e32b3f7e2ac004c3f51121df ("another LAB") was the first commit > causing the problem. The previous commit > d7caf4ce1bd5df6c98a1a59a122a4a63d9916bd7 ("fix file opening bug in > s2tc_decompress") together with b3f0fb2b88f700d5e32b3f7e2ac004c3f51121df > ("another LAB") did not have this problem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721972: debdiff
Totally forgot about the nvtt issue. I uploaded your patch to the collab-maint repository and asked my uploader to do some testing and upload it to unstable. Sorry again, Lennart -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713966: nvidia-texture-tools: OptimalOptions.cmake assumes x86_64 implies athlon64
So the testsuite works fine when nvtt is not optimized for athlon64? On 24.06.2013 13:33, Vincent Cheng wrote: > Package: src:nvidia-texture-tools > Version: 2.0.8-1+dfsg-3 > Severity: important > Tags: patch > Control: block 712956 by -1 > > Dear Maintainer, > > As reported in #712956, one of the amd64 buildds (barber) fails to > execute 0ad's testsuite (causing a FTBFS) due to some sort of "Illegal > instruction". After asking upstream [1], it turns out that this may be > caused by nvidia-texture-tools being built with -march=athlon64 on any > amd64 host. Please consider applying the following quilt-formatted > patch to fix this. > > --- a/cmake/OptimalOptions.cmake > +++ b/cmake/OptimalOptions.cmake > @@ -15,7 +15,7 @@ > ENDIF(NV_SYSTEM_PROCESSOR STREQUAL "i686") > > IF(NV_SYSTEM_PROCESSOR STREQUAL "x86_64") > - SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=athlon64") > + #SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=athlon64") > #SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=athlon64 > -msse3") > ENDIF(NV_SYSTEM_PROCESSOR STREQUAL "x86_64") > > > Regards, > Vincent > > [1] http://trac.wildfiregames.com/ticket/1994 > > -- System Information: > Debian Release: jessie/sid > APT prefers testing > APT policy: (700, 'testing'), (500, 'unstable'), (200, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.9-1-vclaptop-amd64 (SMP w/8 CPU cores; PREEMPT) > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690469: Possible fix for segfault
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just noting here that I saw the bug report and will test this issue and the patch. I'm just currently a little bit swamped. Am 17.12.2012 01:03, schrieb Laurent Carlier: > The following patch fix segfault with atqw/quake4, please test. > > Regards > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDSBI0ACgkQiE7WFTROQuNQeQCgk7/NSk4eZnWSpXxrKVS017pn BxYAn0B0X7IU0KEfwXfX/z//sk9FQc6o =mUe7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#689642: nvidia-texture-tools: fails to build against libtiff5 due to clash of wills over int64/uint64
I already updated the package[1] a while back to fix this issue as br...@canonical.com alerted me to this issue with their build-servers. I haven't pressured my sponsor enough yet to get it uploaded. Will do that today. Sorry for that. [1] http://anonscm.debian.org/gitweb/?p=collab-maint/nvidia-texture-tools.git;a=commit;h=18176bf0d166edcc0fb22bcb6dc0219e28383f10 Am 04.10.2012 19:11, schrieb Colin Watson: > Package: nvidia-texture-tools > Version: 2.0.8-1+dfsg-2 > Severity: important > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu ubuntu-patch quantal > > When built against libtiff5 (as will be the default for libtiff-dev in > Ubuntu 12.10, and I believe in Debian jessie), nvidia-texture-tools > fails to build on amd64 as follows: > > [ 36%] Building CXX object src/nvimage/CMakeFiles/nvimage.dir/ImageIO.cpp.o > In file included from /usr/include/tiffio.h:33:0, >from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:31: > /usr/include/tiff.h:77:23: error: conflicting declaration 'typedef long int > int64' > In file included from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvcore/nvcore.h:163:0, >from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvcore/Ptr.h:6, >from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:3: > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvcore/DefsGnucLinux.h:62:29: > error: 'int64' has a previous declaration as 'typedef long long int int64' > In file included from /usr/include/tiffio.h:33:0, >from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:31: > /usr/include/tiff.h:78:23: error: conflicting declaration 'typedef long > unsigned int uint64' > In file included from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvcore/nvcore.h:163:0, >from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvcore/Ptr.h:6, >from > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:3: > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvcore/DefsGnucLinux.h:61:29: > error: 'uint64' has a previous declaration as 'typedef long long unsigned > int uint64' > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp: In > function 'nv::FloatImage* nv::ImageIO::loadFloat(const char*)': > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:138:10: > warning: converting 'false' to pointer type 'nv::FloatImage*' > [-Wconversion-null] > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp: In > function 'nv::Image* nv::ImageIO::loadTGA(nv::Stream&)': > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:236:12: > warning: converting 'false' to pointer type 'nv::Image*' [-Wconversion-null] > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:257:11: > warning: converting 'false' to pointer type 'nv::Image*' [-Wconversion-null] > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp: In > function 'nv::Image* nv::ImageIO::loadPNG(nv::Stream&)': > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:624:10: > warning: converting 'false' to pointer type 'nv::Image*' [-Wconversion-null] > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:632:10: > warning: converting 'false' to pointer type 'nv::Image*' [-Wconversion-null] > > /build/buildd/nvidia-texture-tools-2.0.8-1+dfsg/src/nvimage/ImageIO.cpp:639:10: > warning: converting 'false' to pointer type 'nv::Image*' [-Wconversion-null] > make[3]: *** [src/nvimage/CMakeFiles/nvimage.dir/ImageIO.cpp.o] Error 1 > > This is because tiff 4.x exposes its own idea of int64 and uint64 > typedefs in , and this means that the ones in > nvidia-texture-tools have to match. > > I trust my complaint in the following patch about typedeffing common > non-namespaced identifiers speaks for itself, although I realise it > should also go to the tiff maintainers! > > * Avoid int64/uint64 typedef clash with . > > diff -Nru > nvidia-texture-tools-2.0.8-1+dfsg/debian/patches/int64-typedef-madness.patch > nvidia-texture-tools-2.0.8-1+dfsg/debian/patches/int64-typedef-madness.patch > --- > nvidia-texture-tools-2.0.8-1+dfsg/debian/patches/int64-typedef-madness.patch > 1970-01-01 01:00:00.0 +0100 > +++ > nvidia-texture-tools-2.0.8-1+dfsg/debian/patches/int64-typedef-madness.patch > 2012-10-04 17:53:36.0 +0100 > @@ -0,0 +1,30 @@ > +Description: Avoid int64/uint64 typedef clash with > + Both nvidia-texture-toolkit and tiff attempt to define their own int64 and > + uint64 types. As of libtiff 4.x, these are exported in , and so we > + have to make some attempt to get them to match. > + . > + Need I point out how terrible an idea it is to t
Bug#668645: Acknowledgement (libgl1-mesa-dri: Add a recommendation for a libtxc-dxtn implementation)
Is this under consideration or did I just file it against the wrong package? There is actually some interest in other packages to have s2tc installed by default as games and other applications using s3tc implementations benefit greatly from this package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#668645: libgl1-mesa-dri: Add a recommendation for a libtxc-dxtn implementation
Package: libgl1-mesa-dri Severity: wishlist I suggest adding a recommends dependency to mesa-dri for the package libtxc-dxtn0 provided by libtxc-dxtn-s2tc0. The package is currenly available in unstable S2TC is a most likely patent-free S3TC compatible texture compression. The performance increase for GL and WebGL applications offering this option is quite noticable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667989: ITP: s2tc -- S2TC is a patent-free S3TC compatible texture compression
Package: wnpp Severity: wishlist Owner: Lennart * Package name: s2tc Version : 0~git20110809 Upstream Author : Rudolf Polzer * URL : https://github.com/divVerent/s2tc * License : MIT/X11 Programming Lang: C/C++ Description : S2TC is a patent-free S3TC compatible texture compression implementation S2TC is a patent-free S3TC compatible implementation and provides texture compression to Mesa. The package also includes tools to compress/decompress S2TC textures and convert S3TC textures to S2TC ones using the patent-free algorithm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594800: (no subject)
The nvidia-texture-tools are now in debian unstable[1]. If you need any help with creating the package for 0ad drop me a message and I will see how I can be of assistance to you. [1] http://packages.debian.org/source/sid/nvidia-texture-tools -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666254: nvidia-texture-tools: FTBFS on i386 and powerpc: .symbols file mismatches
I already removed the symbols file and use dh_shlibdeps in my new version. Generating symbol files for C++ is a real pain [1] but the shlibdeps seems to work pleasently well. [1] http://lists.debian.org/debian-devel/2012/01/msg00671.html Am 30.03.2012 03:31, schrieb Aaron M. Ucko: > Package: nvidia-texture-tools > Version: 2.0.8-1+dfsg-1 > Severity: normal > > Builds of nvidia-texture-tools on i386 and powerpc naturally get > further than on architectures upstream doesn't support at all (whose > failures I reported in #666252). All the same, they still run into > trouble because the libraries wind up defining different symbols than > on amd64. (No two architectures have the same list, in part because > powerpc is big-endian, calling for a bunch of POSH_ functions that > deal with byte swapping; see > https://buildd.debian.org/status/package.php?p=nvidia-texture-tools&version=2.0.8-1+dfsg-1 > for details.) > > Could you please accommodate these differences? > > Thanks! > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666252: nvidia-texture-tools: FTBFS on architectures not supported upstream
I already changed the the arch builds for my package in collab-maint. I just want to add a few patches which also allow building on kfreebsd-(amd64|i386) before I submit the package again for building Am 30.03.2012 03:21, schrieb Aaron M. Ucko: > Package: nvidia-texture-tools > Version: 2.0.8.1+dfsg-1 > Severity: serious > Justification: fails to build from source > > It looks like nvidia-texture-tools only supports building on x86 and > PowerPC; as such, could you please set its source Architecture list > (in the first stanza of debian/control) to amd64 i386 powerpc ppc64? > Alternatively, you're of course welcome to add support for further > architectures; just please make sure the Architecture setting matches > reality one way or the other. Also, please request a corresponding > update to https://buildd.debian.org/quinn-diff/Packages-arch-specific . > > Thanks! > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Am 29.03.2012 02:17, schrieb Paul Wise: > On Wed, 2012-03-28 at 22:40 +0200, Lennart Weller wrote: > >> Because I did not plan to have it submitted to debian when I >> created it for my ubuntu ppa. > > Hmm, OK. > >> In what way do you think it's broken? Also I did submit [1] the >> patch for the library versioning but it got ignored so far. Every >> software which would benefit from the library currently uses the >> two year old version 2.0.8 and there is more then one open >> request so why should the library be hidden from the system? > > Firstly, source code version and SONAME are completely different > things. There is no reason to start the SONAME at 2, it should > start at 0. Secondly, if upstream is not producing properly > versioned shared libraries, it is very inappropriate to trample > their SONAME name-space and much better to use a Debian-specific > SONAME. If upstream chooses 0 as the SONAME and then makes two new > releases with an incompatible ABI, they will be up to SONAME 2 > which will be ABI incompatible with the Debian SONAME 2. The SONAME starting with 2 was suggested by my supporter and I understand the reasoning for it. The upstream developer seems to only break ABI in major versions and if someone creates a package for version 1.* than there won't be any conflicts. Also the upstream package does not contain any SO versioning for the current stable release. But I will contact the upstream developer about these concerns. >>> 02-multiarch.patch looks like it *does* need forwarding. >> This way of implementing multi-arch support is debian specific so >> I don't think upstream would need this. Which is also written in >> the abstract of the patch. Building the library with this patch >> would definitely go against the the multi-arch solution of e.g. >> RHEL-based distributions. > > I don't know CMake that well but it appears that upstream is > incorrectly hard-coding the lib install directory. Anyone wanting > to customise the library dir will get the wrong result. RHEL/Fedora > distributions don't support proper multi-arch, they only have > bi-arch (aka multilib). When they start switching to proper > multi-arch, they are going to need that patch so it is best to get > it upstream now. In the upstream version you can currently choose the PREFIX of the installation but it will always be installed to PREFIX/lib. That was fixed by my patch. But as I said I will talk with the upstream author and try to have it added to his version. >> I used this naming scheme because it is frequently used by other >> libraries like libc-bin, ncurses-bin, libnotify-bin, >> libglib2.0-bin and so on. Of course I'm free to any suggestions >> on this part. > > Well, ultimately the library isn't the most important part of the > package, the important bit is the command-line tools and they > should be named appropriately. The libraries come from an embedded > code copy of nvidia-oss, not from nvidia-texture-tools itself. I > would say the name of the package with the binaries should reflect > the above. > > Embedded code copies are discouraged in Debian. There are also the > libsquish and poshlib embedded code copies. Please inform the > security team about these issues if the package reaches the > archive. > > http://wiki.debian.org/EmbeddedCodeCopies > http://code.google.com/p/nvidia-oss/ > http://code.google.com/p/libsquish/ http://hookatooka.com/poshlib/ > > In addition, libsquish can be built with SSE or Altivec on the > appropriate platforms, increasing its speed. By embedding > libsquish, nvidia-texture-tools is missing out on that speed-up. > Since As you can see in the nvidia-oss repository there was no changeset since 2009 where as nvidia-texture-tools received changes to former nvidia-oss directories upto the stable release in 2010 and is still being updated for the next release. Thats why I didn't use the nvidia-oss version. With the other libraries you have a fair point and I will package them seperatly for the next upstream release. >> I removed gnuwin32 binary files, auto-generated Visual Studio >> project files (because they had no license header and were not >> necessary) and a custom configure script which broke automatic >> cmake building and basically called just cmake in the first >> place. I will look into it to add this information to the >> package. > > You should have a get-orig-source debian/rules target to > automatically build/repack the tarball. Please see debian-policy > for info on that. Okay I will look into that and add the target. > I guess you missed removal of the non-free nvidia logo? Those icons were also inside the visual studio project directories. I didn't even notice that I erased them as the whole directory structure wasn't important to the package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Am 29.03.2012 14:10, schrieb Fabio: > If you are packaging 2.0.8 please have a look at the README.txt and patches > at: > http://trac.wildfiregames.com/browser/ps/trunk/libraries/nvtt/ > > The issue139.patch is particularly important: it fixed image corruption I > noticed on 0.A.D., see here: > http://www.wildfiregames.com/forum/index.php? > showtopic=13617&view=findpost&p=211880 > > Thanks, > Fabio > > I will look through the patches and add the ones which seem important until the next release update. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Am 28.03.2012 13:51, schrieb Paul Wise: On Wed, 2012-03-28 at 12:25 +0200, Lennart Weller wrote: I already got a sponsor for the package and I already completed the packaging a few month back but thanks for offering your help. How come you didn't file an ITP *before* packaging it? That is what ITPs are for. Because I did not plan to have it submitted to debian when I created it for my ubuntu ppa. The package is already in collab-maint [1]. And in the new queue for unstable. It was mainly meant to allow to build 0ad. Here [2] is the ITP for 0ad which requires nvidia-texture-tools to continue. I see. Here is a quick review of your packaging: Your library versioning is broken, you should use a Debian-specific SONAME until upstream sets that. Personally I don't think the libs should be public, better to put them in a private dir. In what way do you think it's broken? Also I did submit [1] the patch for the library versioning but it got ignored so far. Every software which would benefit from the library currently uses the two year old version 2.0.8 and there is more then one open request so why should the library be hidden from the system? 02-multiarch.patch looks like it *does* need forwarding. This way of implementing multi-arch support is debian specific so I don't think upstream would need this. Which is also written in the abstract of the patch. Building the library with this patch would definitely go against the the multi-arch solution of e.g. RHEL-based distributions. You might want to run wrap-and-sort -sa so that diffs of the debian/ dir are more readable. Didn't know that tool. Thanks for mentioning it. Otherwise I would have done this myself manually in the future. IMO libnvtt-bin should be called nvidia-texture-tools. I used this naming scheme because it is frequently used by other libraries like libc-bin, ncurses-bin, libnotify-bin, libglib2.0-bin and so on. Of course I'm free to any suggestions on this part. The package version has +dfsg in it but there is no indication of how the upstream tarball was repacked and what was non-free. I removed gnuwin32 binary files, auto-generated Visual Studio project files (because they had no license header and were not necessary) and a custom configure script which broke automatic cmake building and basically called just cmake in the first place. I will look into it to add this information to the package. [1] http://code.google.com/p/nvidia-texture-tools/issues/detail?id=170 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Am 28.03.2012 04:48, schrieb Paul Wise: > On Wed, Mar 28, 2012 at 3:15 AM, Lennart Weller wrote: > >> * Package name: nvidia-texture-tools >> Version : 2.0.8 >> Upstream Author : Ignacio Castano >> * URL : http://code.google.com/p/nvidia-texture-tools/ >> * License : MIT/Expat, BSD-2-clause >> Programming Lang: C++ >> Description : image processing and texture manipulation tools >> >> NVIDIA Texture Tools is a collection of image processing and texture >> manipulation tools, designed to be integrated in game tools and asset >> conditioning pipelines. The primary features of the library are mipmap and >> normal map generation, format conversion and DXT compression. > > I had intended to package this and have some early packaging already, > so if you need a sponsor I can do that. > > I've been talking to upstream about some deficiencies in the software > and its dependencies (that are not yet in Debian). I would suggest > that you wait until these discussions are concluded and the upstreams > have made new releases before working on the package. > I already got a sponsor for the package and I already completed the packaging a few month back but thanks for offering your help. The package is already in collab-maint [1]. And in the new queue for unstable. It was mainly meant to allow to build 0ad. Here [2] is the ITP for 0ad which requires nvidia-texture-tools to continue. [1] http://anonscm.debian.org/gitweb/?p=collab-maint/nvidia-texture-tools.git;a=summary [2] http://bugs.debian.org/594800 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Am 28.03.2012 01:01, schrieb Ben Hutchings: > On Tue, Mar 27, 2012 at 09:15:27PM +0200, Lennart Weller wrote: >> Package: wnpp >> Severity: wishlist >> Owner: Lennart Weller >> >> >> * Package name: nvidia-texture-tools >> Version : 2.0.8 >> Upstream Author : Ignacio Castano >> * URL : http://code.google.com/p/nvidia-texture-tools/ >> * License : MIT/Expat, BSD-2-clause >> Programming Lang: C++ >> Description : image processing and texture manipulation tools >> >> NVIDIA Texture Tools is a collection of image processing and texture >> manipulation tools, designed to be integrated in game tools and asset >> conditioning pipelines. The primary features of the library are mipmap and >> normal map generation, format conversion and DXT compression. >> >> The sourcecode contains algorithms protected by US patent 5,956,431 aka >> S3TC. >> Though from what I've read on debian-legal this should be okay as the >> patent >> is not actively enforced. > > Since you've accepted as fact that this software infringes those > patents, it looks like you're about to violate item 1 of the Debian > patent policy. > > Ben. > S3TC is not actively enforced by S3. And I took this thread [1] as a reference to create the ITP anyway. According to this thread from 2010 there are at least three other projects already using the S3TC algorithms. And there is more than one project which depends on this package. e.g. 0ad and wine [1] http://lists.debian.org/debian-legal/2010/12/msg00062.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools
Package: wnpp Severity: wishlist Owner: Lennart Weller * Package name: nvidia-texture-tools Version : 2.0.8 Upstream Author : Ignacio Castano * URL : http://code.google.com/p/nvidia-texture-tools/ * License : MIT/Expat, BSD-2-clause Programming Lang: C++ Description : image processing and texture manipulation tools NVIDIA Texture Tools is a collection of image processing and texture manipulation tools, designed to be integrated in game tools and asset conditioning pipelines. The primary features of the library are mipmap and normal map generation, format conversion and DXT compression. The sourcecode contains algorithms protected by US patent 5,956,431 aka S3TC. Though from what I've read on debian-legal this should be okay as the patent is not actively enforced. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611175: zsh: VCS_INFO wrongly detects svn repositories
On 27.01.2011 17:43, Frank Terbeck wrote: > I suggest, debian does the same (maybe you could update your patch for > debian's convenience). > > One nit: you reported this against version 4.3.6-6; however vcs_info was > shipped with zsh 4.3.7 for the first time. ...so unless debian's 4.3.6-6 > package ships it on its own, I doubt that's correct. :) I forgot to check for a version mismatch. I just send the report from an older debian box with mail setup for reportbug. The actual version was 4.3.10 but that doesn't really matter anyway. --- a/VCS_INFO_detect_svn 2011-01-27 17:50:51.0 +0100 +++ b/VCS_INFO_detect_svn 2011-01-27 17:51:09.0 +0100 @@ -7,5 +7,5 @@ [[ $1 == '--flavours' ]] && return 1 VCS_INFO_check_com ${vcs_comm[cmd]} || return 1 -[[ -d ".svn" ]] && return 0 +[[ -f ".svn/entries" || -f ".svn/format" ]] && return 0 return 1
Bug#611175: zsh: VCS_INFO wrongly detects svn repositories
On 27.01.2011 16:58, Frank Terbeck wrote: > That sounds reasonable. Do you know how stable the "entries" file is > within the .svn directories with respect to versions? Ie. Does it exist > in old versions as well as in recent ones? (My knowledge of subversion's > directory contents are rather limited.) > I don't use svn frequently either but I just happend to have a ~/.svn/authors file which caused the bug. I found this: http://stackoverflow.com/questions/1364618/how-do-i-determine-svn-working-copy-layout-version So checking: [[ -f ".svn/entries" || -f ".svn/format" ]] && return 0 should be sufficient for all versions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#611175: zsh: VCS_INFO wrongly detects svn repositories
Package: zsh Version: 4.3.6-6 Severity: normal Tags: patch Currently zshs VCS_INFO function wrongly detects svn repositories if an .svn directory exists in the current path. Which also applies to home directories containing for example a ~/.svn/authors file. Instead of checking only for the directory it would be smarter to check for an important svn repository file. Like .svn/entries. Which is done through my patch. I suggest to check the other revison control systems as well. -- System Information: Debian Release: 5.0.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages zsh depends on: ii libc6 2.7-18lenny7 GNU C Library: Shared libraries ii libcap2 2.11-2 support for getting/setting POSIX. ii libncursesw5 5.7+20081213-1 shared libraries for terminal hand Versions of packages zsh recommends: ii libpcre3 7.6-2.1Perl 5 Compatible Regular Expressi Versions of packages zsh suggests: pn zsh-doc(no description available) -- no debconf information --- a/VCS_INFO_detect_svn 2011-01-26 12:47:33.010081966 +0100 +++ b/VCS_INFO_detect_svn 2011-01-26 12:46:50.800830005 +0100 @@ -7,5 +7,5 @@ [[ $1 == '--flavours' ]] && return 1 VCS_INFO_check_com ${vcs_comm[cmd]} || return 1 -[[ -d ".svn" ]] && return 0 +[[ -f ".svn/entries" ]] && return 0 return 1
Bug#595174: [Pkg-fglrx-devel] Bug#595174: 10.8 blocks opengl wine applications. "_XReply: Assertion `!dpy->xcb->reply_data', failed")
That pretty much fixed it. Though the only other fglrx installation I had before was the 10.3-prealpha package from the ubuntu repositories when there was no debian package. This bugreport can be closed. On 27.09.2010 22:02, Michael Gilbert wrote: this specific error has come up before. the issue was narrowed down to files leftover from a manual driver installation. see [0]. perhaps that will help. best wishes, mike [0] http://bugs.debian.org/579813 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595174: 10.8 blocks opengl wine applications. "_XReply: Assertion `!dpy->xcb->reply_data', failed")
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tried to use the Steam client today. Which as it turned out also fails with fglrx > 10.7. See next to last line. It probably has something in common with the fact that this is a graphics card from the Evergreen series. I will probably give mesa 7.10 with r600g a chance next. l...@blackbox:~ % WINEPREFIX=$HOME/Steam wine "C:\Programme\Steam\Steam.exe" CellID: Fetching server list from CSDS. . . fixme:process:SetProcessShutdownParameters (0100, ): partial stub. fixme:urlmon:CoInternetSetFeatureEnabled 5, 0x0002, 1, stub fixme:urlmon:CoInternetSetFeatureEnabled 10, 0x0002, 1, stub fixme:mixer:ALSA_MixerInit No master control found on HD-Audio Generic, disabling mixer ALSA lib ../../../src/pcm/pcm.c:2171:(snd_pcm_open_conf) Cannot open shared library /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so ALSA lib ../../../src/pcm/pcm.c:2171:(snd_pcm_open_conf) Cannot open shared library /usr/lib32/alsa-lib/libasound_module_pcm_pulse.so CellID: CSDS returned 169 servers. CellID: Connecting to 87.248.192.58:27031. . . CellID: Connect to 87.248.192.58:27031 took 87 MS CellID: Nothing beat our old best time of 56 MS fixme:wbemprox:wbem_locator_ConnectServer 0x4b312f8, L"ROOT\\CIMV2", (null), (null), (null), 0x0080, (null), (nil), 0x422c000) err:ole:CoGetClassObject class {77f10cf0-3db5-4966-b520-b7c54fd35ed6} not registered err:ole:CoGetClassObject no class object {77f10cf0-3db5-4966-b520-b7c54fd35ed6} could be created for context 0x1 fixme:winhttp:WinHttpGetIEProxyConfigForCurrentUser returning no proxy used fixme:winhttp:WinHttpGetIEProxyConfigForCurrentUser returning no proxy used mme\Steam\Steam.exe: ../../src/xcb_io.c:452: _XReply: Zusicherung »!dpy->xcb->reply_data« nicht erfüllt. fixme:threadpool:RtlQueueWorkItem Flags 0x4 not supported -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyg3QUACgkQiE7WFTROQuOF6QCeL62vl328S4RALqRCTQhCuiRK Fb4AnjCRXEjqMKFecs/XAS6JynGTTwsS =ADMc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595174: fglrx-driver: fglrx, 10.8 blocks opengl wine applications. "_XReply: Assertion `!dpy->xcb->reply_data', failed"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I tested both still throwing the same error. But now the application crashes as well and therefore i have a stacktrace. Maybe this can help identifying the cause of the bug. mme\NCsoft\AionEU\bin32\aion.bin: ../../src/xcb_io.c:452: _XReply: Zusicherung »!dpy->xcb->reply_data« nicht erfüllt. wine: Assertion failed at address 0xf77fb430 (thread 0009), starting debugger... Unhandled exception: assertion failed in 32-bit code (0xf77fb430). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:f77fb430 ESP:00325624 EBP:0032563c EFLAGS:0296( - -- I S -A-P- ) EAX: EBX:08e4 ECX:08e4 EDX:0006 ESI:f763a357 EDI:f765bff4 Stack dump: 0x00325624: 0032563c 0006 08e4 f7543a21 0x00325634: f765bff4 0032575c 00325764 f7546e42 0x00325644: 0006 003256dc 0250 0x00325654: f765d430 0080 f765d3a0 f765bff4 0x00325664: f765d3a0 0079 00325684 f758988d 0x00325674: 003256a0 f765bff4 f765bff4 007a Backtrace: =>0 0xf77fb430 (0x0032563c) 1 0xf7546e42 abort+0x181() in libc.so.6 (0x00325764) 2 0xf753c928 __assert_fail+0xf7() in libc.so.6 (0x003257ac) 3 0x7e2bea12 _XReply+0x351() in libx11.so.6 (0x003257fc) 4 0xf503f3bf LnxXextEscape+0x10e() in libatiadlxx.so (0x0032586c) 5 0xf501c265 Send+0xc4() in libatiadlxx.so (0x003258ac) 6 0xf50313c1 __i686.get_pc_thunk.cx+0x95() in libatiadlxx.so (0x0032591c) 7 0xf5024f78 ADL_Workstation_AdapterNumOfGLSyncConnectors_Get+0x37() in libatiadlxx.so (0x0032595c) 0xf77fb430: popl%ebp Modules: Module Address Debug info Name (77 modules) PE40- 6af000 Deferredaion.bin ELF 7b80-7b976000 Deferredkernel32 \-PE 7b81-7b976000 \ kernel32 ELF 7bc0-7bcb9000 Deferredntdll \-PE 7bc1-7bcb9000 \ ntdll ELF 7bf0-7bf04000 Deferred ELF 7e1e-7e214000 Deferreduxtheme \-PE 7e1f-7e214000 \ uxtheme ELF 7e214000-7e21d000 Deferredlibxcursor.so.1 ELF 7e21d000-7e222000 Deferredlibxfixes.so.3 ELF 7e222000-7e225000 Deferredlibxcomposite.so.1 ELF 7e225000-7e22c000 Deferredlibxrandr.so.2 ELF 7e22c000-7e235000 Deferredlibxrender.so.1 ELF 7e235000-7e23a000 Deferredlibxxf86vm.so.1 ELF 7e23a000-7e25c000 Deferredimm32 \-PE 7e24-7e25c000 \ imm32 ELF 7e25c000-7e261000 Deferredlibxdmcp.so.6 ELF 7e261000-7e27a000 Deferredlibxcb.so.1 ELF 7e27a000-7e397000 Export libx11.so.6 ELF 7e397000-7e3a6000 Deferredlibxext.so.6 ELF 7e3a6000-7e3be000 Deferredlibice.so.6 ELF 7e3df000-7e487000 Deferredwinex11 \-PE 7e3f-7e487000 \ winex11 ELF 7e4a9000-7e4cf000 Deferredlibexpat.so.1 ELF 7e4cf000-7e4fe000 Deferredlibfontconfig.so.1 ELF 7e4ff000-7e502000 Deferredlibxinerama.so.1 ELF 7e502000-7e505000 Deferredlibxau.so.6 ELF 7e505000-7e509000 Deferredlibuuid.so.1 ELF 7e509000-7e511000 Deferredlibsm.so.6 ELF 7e51f000-7e596000 Deferredlibfreetype.so.6 ELF 7e596000-7e5c3000 Deferredws2_32 \-PE 7e5a-7e5c3000 \ ws2_32 ELF 7e5c3000-7e6af000 Deferredcomctl32 \-PE 7e5d-7e6af000 \ comctl32 ELF 7e6af000-7e899000 Deferredshell32 \-PE 7e6c-7e899000 \ shell32 ELF 7e899000-7e8fc000 Deferredshlwapi \-PE 7e8b-7e8fc000 \ shlwapi ELF 7e8fc000-7e92 Deferredmpr \-PE 7e90-7e92 \ mpr ELF 7e941000-7e99e000 Deferredwininet \-PE 7e95-7e99e000 \ wininet ELF 7e99e000-7ea88000 Deferredoleaut32 \-PE 7e9c-7ea88000 \ oleaut32 ELF 7ea88000-7eafd000 Deferredrpcrt4 \-PE 7eaa-7eafd000 \ rpcrt4 ELF 7eafd000-7ebfe000 Deferredole32 \-PE 7eb2-7ebfe000 \ ole32 ELF 7ebfe000-7ec59000 Deferredadvapi32 \-PE 7ec1-7ec59000 \ advapi32 ELF 7ec59000-7ece5000 Deferredgdi32 \-PE 7ec7-7ece5000 \ gdi32 ELF 7ece5000-7ee17000 Deferreduser32 \-PE 7ed0-7ee17000 \ user32 ELF 7ef8c000-7ef98000 Deferredlibnss_files.so.2 ELF 7ef98000-7efa2000 Deferredlibnss_nis.so.2 ELF 7efa2000-7efb9000 Deferredlibnsl.so.1 ELF 7efb9000-7efdf000 Deferredlibm.so.
Bug#595174: [Pkg-fglrx-devel] Bug#595174: fglrx-driver: fglrx 10.8 blocks opengl wine applications. "_XReply: Assertion `!dpy->xcb->reply_data' failed"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.09.2010 20:55, Patrick Matthäi wrote: > Am 07.09.2010 20:38, schrieb Lennart Weller: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 07.09.2010 20:24, Patrick Matthäi wrote: >>> Am 01.09.2010 21:59, schrieb Lennart Weller: >>>> On 01.09.2010 20:34, Patrick Matthäi wrote: >>>>> Am 01.09.2010 20:14, schrieb Lennart Weller: >>>>>> Package: fglrx-driver >>>>>> Version: 1:10-8-1 >>>>>> Severity: critical >>>>>> Tags: upstream >>>>>> >>>>>> The current upstream release of fglrx causes applications using >>>>>> opengl in a wine environment to crash instantly. >>>>>> A similar error was reported in April 2010 to the wine >>>>>> bugtracker:http://bugs.winehq.org/show_bug.cgi?id=22490 >>>>>> Though this time its solely related to fglrx. After downgrading to >>>>>> 10.7 all tested applications work again. >>>>>> >>>>> >>>>> What happens, if you disable the new 2D stack: >>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587824#21 >>>>> >>>>> (==) fglrx(0): ATI 2D Acceleration Architecture enabled<-- this has >>>>> to be disabled in your xorg.0.log >>>>> >>>> The problem persists even if XAA is used. I explicitly checked both >>>> suggestions in the other thread. First the reset of the config file and >>>> afterwards the ForceXAA parameter. >>> >>> Okay first I think this bug is not a release blocker - if it only fails >>> to launch opengl wine applications. >>> >>> But before I may downgrade it, could you provide some windows >>> application names (please no apps where I have to pay first) with that I >>> may reproduce your issue? >>> >> >> >> Due to the fact that somehow all GUI applications have a relation with a >> graphics driver it's not really fitting to categorize it as `critical` >> by the BTS. Though it introduces regressions which stop 'unrelated' >> applications from working correctly, which is the reason I put it up as >> critical anyway. >> >> Okay I tested Aion[1] and Lineage 2[2], both from NCSoft(both games run >> perfectly fine with wine1.2 or newer). And the client can be downloaded >> and started without paying for it. The applications fail to start with >> 10.8 so it should be enough to test. >> >> [1] >> http://www.fileplanet.com/204286/20/fileinfo/Aion-Online-Client-v1.9 >> [2]http://www.fileplanet.com/215661/21/fileinfo/Lineage-2---Freya-Game-Client >> > > Thanks, but do you have got any little application where this bug apply, > maybe? > I only tested those two games and the older bug reports from the wine bugtracker had 'World of Warcraft' as a reference which isn't much smaller and I can't guarantee that this bug appears for every OpenGL application but it might. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyGjqQACgkQiE7WFTROQuM6XwCggYwfBZp4eBKfdrMG8R323Vsa /FwAn3XMjj0e8lBq78tlIKJtxuZeFxUE =Xdib -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595174: [Pkg-fglrx-devel] Bug#595174: Bug#595174: fglrx-driver: fglrx 10.8 blocks opengl wine applications. "_XReply: Assertion `!dpy->xcb->reply_data' failed"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07.09.2010 20:24, Patrick Matthäi wrote: > Am 01.09.2010 21:59, schrieb Lennart Weller: >> On 01.09.2010 20:34, Patrick Matthäi wrote: >>> Am 01.09.2010 20:14, schrieb Lennart Weller: >>>> Package: fglrx-driver >>>> Version: 1:10-8-1 >>>> Severity: critical >>>> Tags: upstream >>>> >>>> The current upstream release of fglrx causes applications using >>>> opengl in a wine environment to crash instantly. >>>> A similar error was reported in April 2010 to the wine >>>> bugtracker:http://bugs.winehq.org/show_bug.cgi?id=22490 >>>> Though this time its solely related to fglrx. After downgrading to >>>> 10.7 all tested applications work again. >>>> >>> >>> What happens, if you disable the new 2D stack: >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587824#21 >>> >>> (==) fglrx(0): ATI 2D Acceleration Architecture enabled <-- this has >>> to be disabled in your xorg.0.log >>> >> The problem persists even if XAA is used. I explicitly checked both >> suggestions in the other thread. First the reset of the config file and >> afterwards the ForceXAA parameter. > > Okay first I think this bug is not a release blocker - if it only fails > to launch opengl wine applications. > > But before I may downgrade it, could you provide some windows > application names (please no apps where I have to pay first) with that I > may reproduce your issue? > Due to the fact that somehow all GUI applications have a relation with a graphics driver it's not really fitting to categorize it as `critical` by the BTS. Though it introduces regressions which stop 'unrelated' applications from working correctly, which is the reason I put it up as critical anyway. Okay I tested Aion[1] and Lineage 2[2], both from NCSoft(both games run perfectly fine with wine1.2 or newer). And the client can be downloaded and started without paying for it. The applications fail to start with 10.8 so it should be enough to test. [1] http://www.fileplanet.com/204286/20/fileinfo/Aion-Online-Client-v1.9 [2]http://www.fileplanet.com/215661/21/fileinfo/Lineage-2---Freya-Game-Client -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyGhsMACgkQiE7WFTROQuNuFACdH8VcEvkGd7oP2efdTD3ML1DO UDEAn1p36PsEHGZOfeh5xX9rYYOyKVTH =lqyB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#595174: [Pkg-fglrx-devel] Bug#595174: fglrx-driver: fglrx 10.8 blocks opengl wine applications. "_XReply: Assertion `!dpy->xcb->reply_data' failed"
On 01.09.2010 20:34, Patrick Matthäi wrote: Am 01.09.2010 20:14, schrieb Lennart Weller: Package: fglrx-driver Version: 1:10-8-1 Severity: critical Tags: upstream The current upstream release of fglrx causes applications using opengl in a wine environment to crash instantly. A similar error was reported in April 2010 to the wine bugtracker:http://bugs.winehq.org/show_bug.cgi?id=22490 Though this time its solely related to fglrx. After downgrading to 10.7 all tested applications work again. What happens, if you disable the new 2D stack: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587824#21 (==) fglrx(0): ATI 2D Acceleration Architecture enabled <-- this has to be disabled in your xorg.0.log The problem persists even if XAA is used. I explicitly checked both suggestions in the other thread. First the reset of the config file and afterwards the ForceXAA parameter. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org