Bug#1033714: at runtime, flanker tries to create files under /usr

[Daniel Kauffman]

This file is updated automatically if you're using a different 
version of the library than the one with which the file was created 
originally. 
This seems to confirm that for each version of the package, these 
files should be generated from debian/rules at build time. 
Only if you want to also regenerate them when a new python3-ply is 
uploaded, as far as I understand it.
The python3-flanker package **could** be tightly coupled with the 
python3-ply package, but that wouldn't be ideal.


Also I think 
https://github.com/mailgun/flanker/commit/96d774eb6d67b1c5fafe711394c3756df7bb14ad 
(not released yet) is probably about this issue.
That would be great! If the files are not generated at either build time 
or run time, then this particular issue would be solved without special 
handling for Debian packaging, which is always preferred.


Looks like this commit should be in the next release after v0.9.15 
(released March 3, 2023).


In the case of python3-flanker, the package does not work until the 
file is generated. 
It does for me. 
Have you used flanker.addresslib.address.parse('u...@example.com') ? 
Other commands might not generate the files.


Are you running as root? In this case, the files would be generated and 
saved without permission errors.


Have you already generated these files? Possibly by previously running 
as root or possibly by previously installing flanker in a user environment?

Bug#1033714: at runtime, flanker tries to create files under /usr

[Daniel Kauffman]

it is created/modified by PLY, the library that is used internally 
for language parsing.



flanker is likewise using PLY:


> grep -r 'ply'

> addresslib/_parser/parser.py: import ply.yacc as yacc

> addresslib/_parser/lexer.py: import ply.lex as lex

> addresslib/address.py: from ply.lex import LexError

> addresslib/address.py: from ply.yacc import YaccError


This file is updated automatically if you're using a different 
version of the library than the one with which the file was created 
originally.


This seems to confirm that for each version of the package, these files 
should be generated from debian/rules at build time.



Another possible approach (not ideal) would be to save the generated 
files under /var/lib/python3-flanker. However, that approach would 
require maintaining a patch to save/load the generated files from that 
location. Also, most sysadmins would not expect Python files (or 
executable files in general) to be under /var. On my system, the only 
Python or executable files under /var are for dpkg, docker, and snap. 
However, as long as a particular version of flanker generates a 
consistent set of files, there is no need to generate at run time, and 
much better to generate at build time and package.




However, even if it fails to update it, it should still be working.

In the case of python3-flanker, the package does not work until the file 
is generated. Generating the files (correctly) fails due to lack of 
permissions.

Bug#1033714: at runtime, flanker tries to create files under /usr

[Daniel Kauffman]

Package: python3-flanker
Version: 0.9.14-3
Severity: serious

At runtime, flanker tries to create files under /usr but /usr is 
read-only, see:

https://www.debian.org/doc/debian-policy/ch-opersys.html
https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#purpose18


In python 3.9.2, run:

import flanker.addresslib.address
flanker.addresslib.address.parse('u...@example.com')


Note the permission denied errors:

Symbol 'mailbox_or_url_list' is unreachable
Symbol 'delim' is unreachable
Symbol 'mailbox_or_url' is unreachable
Symbol 'url' is unreachable
Couldn't create 'flanker.addresslib._parser.mailbox_parsetab'. [Errno 
13] Permission denied: 
'/usr/lib/python3/dist-packages/flanker/addresslib/_parser/mailbox_parsetab.py'

Symbol 'mailbox_or_url_list' is unreachable
Symbol 'delim' is unreachable
Symbol 'mailbox_or_url' is unreachable
Symbol 'mailbox' is unreachable
Symbol 'url' is unreachable
Symbol 'angle_addr' is unreachable
Symbol 'name_addr' is unreachable
Symbol 'phrase' is unreachable
Couldn't create 'flanker.addresslib._parser.addr_spec_parsetab'. 
[Errno 13] Permission denied: 
'/usr/lib/python3/dist-packages/flanker/addresslib/_parser/addr_spec_parsetab.py'

Symbol 'mailbox_or_url_list' is unreachable
Symbol 'delim' is unreachable
Symbol 'mailbox_or_url' is unreachable
Symbol 'mailbox' is unreachable
Symbol 'addr_spec' is unreachable
Symbol 'angle_addr' is unreachable
Symbol 'name_addr' is unreachable
Symbol 'phrase' is unreachable
Symbol 'local_part' is unreachable
Symbol 'domain' is unreachable
Symbol 'quoted_string' is unreachable
Symbol 'domain_literal' is unreachable
Symbol 'quoted_string_text' is unreachable
Symbol 'domain_literal_text' is unreachable
Couldn't create 'flanker.addresslib._parser.url_parsetab'. [Errno 13] 
Permission denied: 
'/usr/lib/python3/dist-packages/flanker/addresslib/_parser/url_parsetab.py'

Symbol 'mailbox_or_url_list' is unreachable
Symbol 'delim' is unreachable
Couldn't create 'flanker.addresslib._parser.mailbox_or_url_parsetab'. 
[Errno 13] Permission denied: 
'/usr/lib/python3/dist-packages/flanker/addresslib/_parser/mailbox_or_url_parsetab.py'
Couldn't create 
'flanker.addresslib._parser.mailbox_or_url_list_parsetab'. [Errno 13] 
Permission denied: 
'/usr/lib/python3/dist-packages/flanker/addresslib/_parser/mailbox_or_url_list_parsetab.py'


These files should probably be generated from debian/rules and included 
in the binary package.


Thanks,
Daniel Kauffman
Business Experience Designer
Rock Solid Solutions LLC

Bug#1031878: --fail-on warnings fails overrides even though --fail-on overrides is not specified

[Daniel Kauffman]

Package: lintian

Version: 2.104.0

Running `lintian --fail-on warnings` on a package which overrides all 
warnings in debian/lintian-overrides unexpectedly returns exit code 2. 
Expected behavior is for this command to return exit code 0 unless 
`lintian --fail-on overrides` is also specified.


Reading `man lintian` implies that `lintian --fail-on warnings` and 
`lintian --fail-on overrides` should have distinct behaviors. However, 
`lintian --fail-on warnings` seems to behave as if `lintian --fail-on 
warnings,overrides` were specified instead.


If `lintian --fail-on warnings` should always fail on warnings, even 
when debian/lintian-overrides overrides these warnings, the 
documentation should probably be clarified. However, this behavior 
leaves no way to check that a package having one or more overrides has 
no additional issues.


I run lintian as part of my build process. I'd like to fail the build if 
lintian finds issues with either the source package or the binary 
package. Currently, if I use --fail-on, and the package has any 
overrides, lintian always returns exit code 2. And if I don't use 
--fail-on, lintian always returns exit code 0. I seem to be unable to 
have lintian return a non-zero exit code only when a package has an 
issue that has not yet been fixed or overridden. Using 
--ftp-master-rejects might return such an exit code, however, such an 
exit code is not documented and would prevent using a --profile.


Same discussion applies for `--fail-on errors` etc.

Thanks,
Daniel Kauffman
Business Experience Designer
Rock Solid Solutions LLC

Bug#875636: lintian

[Daniel Kauffman]

lintian recognizes the profile if I create a symbolic link from 
/etc/lintian/profiles to $HOME/.lintian/profiles and run the same series 
of commands, so the issue isn't with the profile itself.



To unsubscribe click: 

Bug#875636: lintian ignores profiles under $HOME

[Daniel Kauffman]

Package: lintian
Version: 2.5.50.4
Severity: important

lintian ignores profiles under $HOME.  Previous versions of lintian 
recognized profiles under $HOME.  I'm not sure exactly when the 
regression happened.  At least some version of lintian in Jessie worked.


The order in which lintian searches for profiles is documented at 
https://lintian.debian.org/manual/section-2.5.html in section 2.5.1.  
But in my case the search seems to be skipping $HOME.


Here is a transcript showing the issue:

$ env
MAIL=/var/mail/buildbot-worker
USER=buildbot-worker
HOME=/var/lib/buildbot-worker
LOGNAME=buildbot-worker
TERM=xterm
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
LANG=en_US.UTF-8
SHELL=/bin/sh
PWD=/var/lib/buildbot-worker

$ ls $HOME/.lintian/profiles/buildbot
main.profile

$ lintian --info --profile buildbot 
buildbot-master_0.9.11-1+4.sid.2c3cdb66640084a9aa9cca640b0c9c49853179d5.dsc
Cannot find profile buildbot (in /usr/share/lintian/profiles) at 
/usr/share/lintian/commands/lintian line 1561.




To unsubscribe click: 

Bug#751636: ssh sessions are not cleanly terminated on shutdown/restart with systemd

[Daniel Kauffman]

On 07/06/2015 08:09 AM, Christoph Anton Mitterer wrote:

On Sat, 2015-07-04 at 14:40 -0700, Daniel Kauffman wrote:

If sshd is configured with UsePAM yes, then after installing libpam
-systemd to a remote system and rebooting, ssh sessions are cleanly
terminated, but after purging libpam-systemd and rebooting, ssh
session are not cleanly terminated.

I'd guess that this is just some timing coincidence.

I still see the issue from time to time, even though I have PAM
enabled.

E.g. just a few minutes ago it happened again with:
# reboot
PolicyKit daemon disconnected from the bus.
We are no longer a registered authentication agent.
g_dbus_connection_real_closed: Remote peer vanished with error: Underlying 
GIOStream returned 0 bytes on an async read (g-io-error-quark, 0). Exiting.
here it hangs
In that case, we're looking at two separate issues.  I tested the 
add/reboot/reboot/purge/reboot/reboot cycle on multiple systems and 
found the behavior to be consistently reproducible, where installing 
libpam-systemd would consistently and completely resolve the issue I was 
seeing.  The remote systems I tested are all running fresh, minimal 
installs of Debian 8.


Before installing libpam-systemd, on reboot, the terminal would hang for 
some time, then display:


Write failed: Broken pipe

After which the terminal would return to the local prompt.

After installing libpam-systemd and rebooting, on the next reboot, the 
terminal immediately displays:


Connection to N.N.N.N closed by remote host.
Connection to N.N.N.N closed.

After which the terminal immediately returns to the local prompt.

--
Daniel Kauffman
Lead Developer
Rock Solid Solutions, LLC
877.239.9195 toll-free
208.699.9699 mobile


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

Bug#751636: ssh sessions are not cleanly terminated on shutdown/restart with systemd

[Daniel Kauffman]

If sshd is configured with UsePAM yes, then after installing 
libpam-systemd to a remote system and rebooting, ssh sessions are 
cleanly terminated, but after purging libpam-systemd and rebooting, ssh 
session are not cleanly terminated.


If sshd is configured with UsePAM no, then installing/purging 
libpam-systemd has no effect, and ssh session are not cleanly terminated.


*When sshd is configured with UsePAM yes, and libpam-systemd is 
installed, **/usr/share/pam-configs/systemd refers to registering user 
sessions in the systemd control group hierarchy**.**Could this explain 
how ssh sessions are being shutdown cleanly when using PAM?  Does the 
ssh service, apart from PAM, similarly register sessions in the systemd 
control group hierarchy?  If the ssh service does not register sessions 
with the systemd control group hierarchy, could that explain this issue?*


Steps to reproduce (noting that the install/purge AND the reboot must be 
completed before the ssh session behavior changes):


Use ssh to connect to a remote system where ssh sessions are not cleanly 
terminated on remote system reboot.

Configure sshd with UsePAM yes.
Install libpam-systemd.
Reboot.
Observe ssh session is not cleanly terminated.
Use ssh to connect to remote system.
Reboot.
Observe ssh session is cleanly terminated.
Use ssh to connect to remote system.
Remove libpam-systemd.
Reboot.
Observe ssh session is cleanly terminated.
Use ssh to connect to remote system.
Reboot.
Observe ssh session is not cleanly terminated.

--
Daniel Kauffman
Lead Developer
Rock Solid Solutions, LLC
877.239.9195 toll-free
208.699.9699 mobile

Bug#783875: (no subject)

[Daniel Kauffman]

PlayOnLinux seems to require that the system wine be 32-bit, even though 
PlayOnLinux is later able to install and manage various 32-bit and 
64-bit versions of wine in the PlayOnLinux sandbox.


Wine package naming changed in Jessie, so at least on amd64, PlayOnLinux 
should now explicitly depend on wine32:i386.  Depending on wine is not 
sufficient, because the wine package is simply a meta-package that 
allows either wine32 or wine64 to be installed, and PlayOnLinux breaks 
when using 64-bit system wine.


I do not know whether or not there are packaging policies regarding this 
sort of dependency, where PlayOnLinux works fine on the amd64 
architecture, but depends on a package from the i386 architecture. In 
any case, I would not want to see PlayOnLinux removed from the amd64 
architecture, as the issue can be worked around by manually adding the 
i386 architecture and installing wine32.


Thanks,

Daniel Kauffman
Lead Developer
Rock Solid Solutions, LLC
877.239.9195 toll-free
208.699.9699 mobile


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

Bug#749653: libapache2-mod-wsgi-py3: Python library version mismatch

[Daniel Kauffman]

Package: libapache2-mod-wsgi-py3
Version: 3.4-4+b1
Severity: normal

The Apache2 error log contains the following warning about a Python 
library version mismatch:


apache2[NNN]: [:warn] [pid NNN] mod_wsgi: Compiled for Python/3.3.4.
apache2[NNN]: [:warn] [pid NNN] mod_wsgi: Runtime using Python/3.3.5.

I am not seeing any issues with the package other than this warning.

Browsing through the packages available in the repositories, it seems 
that libpython3.3 has been updated to 3.3.5 while 
libapache2-mod-wsgi-py3 has remained at 3.3.4.  Also, there may be a 
related issue with the mis-match between the libpython3.3 and the 
python3 minor version numbers, but I am not seeing any warnings about 
those packages.


I would suggest one of the following:

 * If the warning denotes a legitimate issue, adjust the package
   dependencies.
 * If the warning is superfluous, silence the warning.
 * If the warning is generally harmless but may sometimes be
   legitimate, change the text of the warning to note that the warning
   is generally harmless.

-- System Information:
Debian Release: 7.5
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-0.bpo.1-amd64 (SMP w/4 CPU cores)

Versions of packages libapache2-mod-wsgi-py3 depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.9-1
ii  libc6   2.18-4
ii  libpython3.33.3.5-1
ii  libpython3.43.4.1~rc1-1
ii  python3 3.3.4-1

libapache2-mod-wsgi-py3 recommends no packages.

libapache2-mod-wsgi-py3 suggests no packages.

Bug#658160: RFS: libapache2-mod-socket-policy-server 0.0.8-1 [NEW] -- An Apache2 module for serving Adobe socket policies

[Daniel Kauffman]

Thomas Goirand reviewed the package circa September 2011, but both he 
and I wanted another set of eyes to look at the Apache configuration 
bits before uploading, so it was never uploaded.


--
Daniel Kauffman
Lead Developer
Rock Solid Solutions, LLC
877.239.9195 toll-free
208.699.9699 mobile


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

Bug#658160: RFS: libapache2-mod-socket-policy-server 0.0.7-1 [NEW] -- An Apache2 module for serving Adobe socket policies.

[Daniel Kauffman]

The relevant files are in the downloads directory:

  http://socketpolicyserver.com/downloads/

The direct link to the Debian source control file is:


http://socketpolicyserver.com/downloads/libapache2-mod-socket-policy-server_0.0.7-1.dsc

Thanks!

Daniel Kauffman
Lead Developer
Rock Solid Solutions, LLC
877.239.9195 toll-free
208.699.9699 mobile



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

Bug#658160: RFS: libapache2-mod-socket-policy-server 0.0.7-1 [NEW] -- An Apache2 module for serving Adobe socket policies.

[Daniel Kauffman]

Package: sponsorship-requests
Severity: wishlist

I am seeking a sponsor for my package:

 * Package name: libapache2-mod-socket-policy-server
   Version : 0.0.7-1
   Copyright   : Rock Solid Innovations, LLC
 * URL : http://socketpolicyserver.com
 * License : Apache License Version 2.0

The package is an Apache2 module for serving Adobe socket policy files.

Adobe Flash Player (since version 9.0.124.0) will not open a socket 
connection to a server unless the server first authorizes the connection 
via an Adobe socket policy. This module serves these policies. (Adobe 
uses a non-standard protocol for serving these policies, hence the 
existence of this module.)


The package can be downloaded from:

  http://socketpolicyserver.com

Thanks in advance!

Daniel Kauffman
Lead Developer
Rock Solid Solutions, LLC
877.239.9195 toll-free
208.699.9699 mobile






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

Bug#642786: debhelper: dh_auto_install is not able to specify alternate Makefile targets

[Daniel Kauffman]

Package: debhelper
Version: 8.0.0
Severity: normal


In debian/rules, when using override_dh_auto_install, the command:

dh_auto_install -- alternate-install-target

Generates the following:

make -j1 install DESTDIR=/tmp/snip alternate-install-target

Instead of:

make -j1 alternate-install-target DESTDIR=/tmp/snip

While the commands:

dh_auto_build
dh_auto_clean

Work as expected by allowing alternate Makefile targets to be specified.



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

Bug#642282: ITP: libapache2-mod-socket-policy-server -- libapache2-mod-socket-policy-server is an Apache2 module for serving Adobe socket policies.

[Daniel Kauffman]

Package: wnpp
Severity: wishlist
Owner: Debian Packaging Team debian-packaging-t...@socketpolicyserver.com


* Package name: libapache2-mod-socket-policy-server
  Version : 0.0.1
  Copyright   : Rock Solid Innovations, LLC
* URL : http://socketpolicyserver.com
* License : Apache License Version 2.0
  Programming Lang: C
  Description : An Apache2 module for serving Adobe socket policies.

libapache2-mod-socket-policy-server is an Apache2 module for
serving Adobe socket policies.



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

Bug#624127: python3.2-minimal: /usr/lib/python3.2/ssl.py refers to PROTOCOL_SSLv2

[Daniel Kauffman]

Package: python3.2-minimal
Version: 3.2-2
Severity: important


/usr/lib/python3.2/ssl.py refers to PROTOCOL_SSLv2, but support for SSLv2 was 
removed by #622004. Bug #613369 describes what appears to have been the same 
issue for python2.6.



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

Bug#607897: virt-manager fails to create virtual network

[Daniel Kauffman]

Package: virt-manager
Version: 0.8.4-8
Severity: important

Virt-manager fails to create virtual network. Guests start and run, but 
without networking.


Error displayed by virt-manager:

Error creating virtual network: internal error '/sbin/iptables --table 
filter --delete INPUT --in-interface virbr0 --protocol udp 
--destination-port 69 --jump ACCEPT' exited with non-zero status 1 and 
signal 0: iptables: Bad rule (does a matching rule exist in that chain?).


Details:

Traceback (most recent call last):
  File /usr/share/virt-manager/virtManager/createnet.py, line 349, in 
finish

self.conn.create_network(xml)
  File /usr/share/virt-manager/virtManager/connection.py, line 730, 
in create_network

net.create()
  File /usr/lib/python2.6/dist-packages/libvirt.py, line 866, in create
if ret == -1: raise libvirtError ('virNetworkCreate() failed', 
net=self)
libvirtError: internal error '/sbin/iptables --table filter --delete 
INPUT --in-interface virbr0 --protocol udp --destination-port 69 --jump 
ACCEPT' exited with non-zero status 1 and signal 0: iptables: Bad rule 
(does a matching rule exist in that chain?).


Additional information:

Iptables version is 1.4.8. Libvirt version is 0.8.3-5.

Local user running virt-manager is a member of the libvirt group.

Connection in virt-manager is qemu:///system

Let me know if additional information would be helpful.

--
Daniel Kauffman




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