Bug#950096: flatpak: Flatpak fails to open SSL connections with p11-kit 0.23.19

[Lennart Weller]

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

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

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])

[Lennart Weller]

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:

[Lennart Weller]

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)

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller <l...@ring0.de>

* Package name: looking-glass
  Version : 0+a10
  Upstream Author : Geoffrey McRae <ge...@hostfission.com>
* 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)

[Lennart Weller]

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'

[Lennart Weller]

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'

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller <l...@ring0.de>

* Package name: cli-helpers
  Version : 1.0.1
  Upstream Author : Amjith Ramanujam <amjit...@gmail.com>
* 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

[Lennart Weller]

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

[Lennart Weller]

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 ?

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

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)

[Lennart Weller]

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)

[Lennart Weller]

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)

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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#811612: FTBFS with GCC 6: cannot convert x to y

[Lennart Weller]

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#810968: [debian-mysql] Bug#810968: mariadb-server-10.0: Logrotate exists 1 if a non-debian mysqld is running (e.g. containerized mysqld)

[Lennart Weller]

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

[Lennart Weller]

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)

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

> 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

[Lennart Weller]

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 <malko...@gmail.com>
 * 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:

[Lennart Weller]

This sounds like a nice plugin. I would package it if nobody else is working on 
it.

Bug#806400: ImportError: No module named 'pkg_resources'

[Lennart Weller]

Sorry. Should have been python3-pkg-resources. Haven't had my coffee yet.

November 27 2015 9:41 AM, "Max Kellermann" <m...@duempel.org> wrote:
> On 2015/11/27 09:34, Lennart Weller <lenn...@lennartweller.de> 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'

[Lennart Weller]

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#806415: mycli: No way to execute the query

[Lennart Weller]

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#806311: RFS: s3backer/1.4.2-1 [ITP]

[Lennart Weller]

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 <arc...@dellroad.org>
* 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#806311: RFS: s3backer/1.4.2-1 [ITP]

[Lennart Weller]

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#794250: pgcli packaging progress

[Lennart Weller]

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

[Lennart Weller]

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#794251: need to update python-pymysql ?

[Lennart Weller]

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#799776: python-pymysql: Update package to 0.6.6 or newer to satisfy the mycli dependency

[Lennart Weller]

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#794452:

[Lennart Weller]

If I can help you out with that let me know.

September 4 2015 9:55 AM, "Andrii Senkovych" <jolly_ro...@itblog.org.ua> 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 <l...@ring0.de>:
> 
>> 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

[Lennart Weller]

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" <lenn...@lennartweller.de> 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 <lenn...@lennartweller.de> 
> 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:

[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#797654: ITP: s3backer -- Amazon AWS S3-backed virtual hard disk device

[Lennart Weller]

September 1 2015 5:27 PM, "Nikolaus Rath" <nikol...@rath.org> 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

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller <l...@ring0.de>

* Package name: s3backer
  Version : 1.4.1
  Upstream Author : Archie L. Cobbs <arc...@dellroad.org>
* 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

[Lennart Weller]

August 11 2015 7:54 PM, David Kalnischkies da...@kalnischkies.de 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

[Lennart Weller]

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 vch...@debian.org 
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#794570: ITP: python-prompt-toolkit -- Python library for building interactive command lines

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* 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#794562: 0ad: Test 0ad with new version of nvidia-texture-tools

[Lennart Weller]

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#794452: python-sqlparse: Please update package to 0.1.14 or higher to satisfy pgcli/mycli dependency

[Lennart Weller]

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#793249: innoextract: change of type in system_error might break with GCC-5

[Lennart Weller]

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#790317: Patch applied upstream

[Lennart Weller]

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 lenn...@lennartweller.de 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#794250: ITP: pgcli -- CLI for PostgreSQL with syntax highlighting and completion

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* Package name: pgcli
  Version : 0.18.0
  Upstream Author : Amjith Ramanujam amjit...@gmail.com
* 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#794251: ITP: mycli -- CLI for MySQL/MariaDB with syntax highlighting and completion

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* Package name: mycli
  Version : 1.0.1
  Upstream Author : Amjith Ramanujam amjit...@gmail.com
* 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#790317: Patch applied upstream

[Lennart Weller]

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

[Lennart Weller]

Package: debian-maintainers
Severity: normal

Dear Maintainer,

Please add me, Lennart Weller l...@ring0.de, 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 l...@ring0.de as a Debian Maintainer
Date: Mon, 13 Jul 2015 00:48:11 +0200
Action: import
Recommended-By: 
  Sebastian Reichel s...@debian.org
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

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de

* 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

[Lennart Weller]

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))

[Lennart Weller]

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 l...@ring0.de 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

[Lennart Weller]

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 none
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

[Lennart Weller]

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#721972: debdiff

[Lennart Weller]

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#716713: libtxc-dxtn-s2tc0: S2TC_REFINE_COLORS=ALWAYS (default) creates broken edges

[Lennart Weller]

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#713966: nvidia-texture-tools: OptimalOptions.cmake assumes x86_64 implies athlon64

[Lennart Weller]

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

[Lennart Weller]

-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

[Lennart Weller]

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 tiff.h, 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 tiff.h.
 
 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 tiff.h
 + Both nvidia-texture-toolkit and tiff attempt to define their own int64 and
 + uint64 types.  As of libtiff 4.x, these are exported in tiff.h, and so we
 + have to make some attempt to get them to match.
 + .
 + Need I point out how terrible an idea it is to typedef standard-looking
 + names, rather than using your own namespace?

Bug#668645: Acknowledgement (libgl1-mesa-dri: Add a recommendation for a libtxc-dxtn implementation)

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart l...@ring0.de


* Package name: s2tc
  Version : 0~git20110809 
  Upstream Author : Rudolf Polzer divver...@alientrap.org
* 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)

[Lennart Weller]

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#666252: nvidia-texture-tools: FTBFS on architectures not supported upstream

[Lennart Weller]

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#666254: nvidia-texture-tools: FTBFS on i386 and powerpc: .symbols file mismatches

[Lennart Weller]

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-toolsversion=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#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

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=13617view=findpostp=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

[Lennart Weller]

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

[Lennart Weller]

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 icast...@nvidia.com
 * 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

[Lennart Weller]

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

[Lennart Weller]

Package: wnpp
Severity: wishlist
Owner: Lennart Weller l...@ring0.de


* Package name: nvidia-texture-tools
  Version : 2.0.8
  Upstream Author : Ignacio Castano icast...@nvidia.com 
* 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#666010: ITP: nvidia-texture-tools -- image processing and texture manipulation tools

[Lennart Weller]

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 l...@ring0.de


 * Package name: nvidia-texture-tools
   Version : 2.0.8
   Upstream Author : Ignacio Castano icast...@nvidia.com 
 * 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#611175: zsh: VCS_INFO wrongly detects svn repositories

[Lennart Weller]

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

[Lennart Weller]

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

[Lennart Weller]

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   none (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)

[Lennart Weller]

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)

[Lennart Weller]

-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, LROOT\\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

[Lennart Weller]

-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   Deferredkernel32elf
  \-PE  7b81-7b976000   \   kernel32
ELF 7bc0-7bcb9000   Deferredntdllelf
  \-PE  7bc1-7bcb9000   \   ntdll
ELF 7bf0-7bf04000   Deferredwine-loader
ELF 7e1e-7e214000   Deferreduxthemeelf
  \-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   Deferredimm32elf
  \-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   Deferredwinex11elf
  \-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_32elf
  \-PE  7e5a-7e5c3000   \   ws2_32
ELF 7e5c3000-7e6af000   Deferredcomctl32elf
  \-PE  7e5d-7e6af000   \   comctl32
ELF 7e6af000-7e899000   Deferredshell32elf
  \-PE  7e6c-7e899000   \   shell32
ELF 7e899000-7e8fc000   Deferredshlwapielf
  \-PE  7e8b-7e8fc000   \   shlwapi
ELF 7e8fc000-7e92   Deferredmprelf
  \-PE  7e90-7e92   \   mpr
ELF 7e941000-7e99e000   Deferredwininetelf
  \-PE  7e95-7e99e000   \   wininet
ELF 7e99e000-7ea88000   Deferredoleaut32elf
  \-PE  7e9c-7ea88000   \   oleaut32
ELF 7ea88000-7eafd000   Deferredrpcrt4elf
  \-PE  7eaa-7eafd000   \   rpcrt4
ELF 7eafd000-7ebfe000   Deferredole32elf
  \-PE  7eb2-7ebfe000   \   ole32
ELF 7ebfe000-7ec59000   Deferredadvapi32elf
  \-PE  7ec1-7ec59000   \   advapi32
ELF 7ec59000-7ece5000   Deferredgdi32elf
  \-PE  7ec7-7ece5000   \   gdi32
ELF 7ece5000-7ee17000   Deferreduser32elf
  \-PE  7ed0-7ee17000   \   user32
ELF 7ef8c000-7ef98000   Deferredlibnss_files.so.2
ELF 7ef98000-7efa2000   Deferredlibnss_nis.so.2
ELF 7efa2000-7efb9000   Deferred

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

[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
-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

[Lennart Weller]

-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: fglrx-driver: fglrx 10.8 blocks opengl wine applications. _XReply: Assertion `!dpy-xcb-reply_data' failed

[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.




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org