Bug#1020518: libmariadb3 is a client library that include marriadb-common that will mess with /etc/mysql/my.cnf
Package: libmariadb3 Version: 1:10.3.36-0+deb10u1 Severity: normal Dear Maintainer, The libmariadb3 package requires mariadb-common, but this last one will modify the /etc/mysql/my.cnf. The library is not only use on a host having mariadb as a server, this is used on clients or on server with other flavor of mysql , in mytop for exemple. Installing this on a server using mysql.com packages or perconna packages will alter the server configuration of /etc/mysql/my.cnf * What led up to the situation? install of mytop that requires libdbd-mysql-perl => libmariadb3 => mariadb-common * What exactly did you do (or not do) that was effective (or ineffective)? As this machine is not a mariadb server but a mysql server installing this caused problems with the my.cnf file, i am locked by this requirement of libmariadb * What was the outcome of this action? each apt action return now an error as the package fail : update-alternatives: error: alternative path /etc/mysql/mariadb.cnf doesn't exist * What outcome did you expect instead? installing a client library should not require anything on the server side and should not modify server configuration of mariadb or other mysql flavors (imho ;p) -- System Information: Debian Release: 10.13 APT prefers oldstable APT policy: (500, 'oldstable'), (100, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.254-vs2.3.9.12aq (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libmariadb3 depends on: ii libc6 2.28-10+deb10u1 ii libgnutls30 3.6.7-4+deb10u9 ih mariadb-common 1:10.3.36-0+deb10u1 ii zlib1g 1:1.2.11.dfsg-1+deb10u2 libmariadb3 recommends no packages. libmariadb3 suggests no packages. -- no debconf information
Bug#950709: broken dependencies, needs update
Package: libwxgtk3.0-dev Version: 3.0.4+dfsg-14 Severity: important This package is a total dependency failure, it needs to be updated to 3.0.4+dfsg-15.
Bug#927684: dunstify is missing from package
Package: dunst Version: 1.3.2-1 Severity: wishlist dunstify is included in the dunst source repository. It would be great if it could be included with the dunst package, or maybe broken out into a new package.
Bug#844473: Update nginx module nchan to 1.0.6
The latest version of Nchan is now 1.0.8. I've updated the debian build, you can pull it from https://github.com/slact/nginx-deb Changes since 1.0.6: 1.0.8 (Nov. 28 2016) fix: possible crash under severely heavy load, introduced in 1.0.7 with stack-overflow fix 1.0.7 (Nov. 27 2016) fix: memory leak after websocket publisher uncleanly aborts connection fix: misbehaving websocket publisher with nchan_publisher_upstream_request fix: potential stack overflow with very large message buffers fix: invalid memory access with empty nchan_publisher_upstream_request for websocket publisher fix: incorrect handling of chunked response from nchan_publisher_upstream_request fix: publishing through websocket too fast may result in buffered messages that never arrive fix: DELETE to multiplexed channel should delete all listed channels fix: abort if publishing to multiple channels while using redis j...@slact.net: > Package: nginx > Version: 1.10.2-2 > > I'm the author of Nchan and I've released a new version with some > important bugfixes, security fixes, and new features. It would be nice > if the Nginx package could be updated to the latest version, 1.0.6 > > https://nchan.slact.net/changelog > > Changes since 1.0.2 (current version in the Debian package): > > 1.0.6 (Nov. 15 2016) > fix: large messages were sometimes incorrectly cleaned up, leaving > behind temp files > fix: file descriptor leak when listening on a unix socket and suddenly > aborting client connections > fix: invalid memory access after reloading twice with redis enabled > fix: crash after shutting down nginx when 'master_process' set to 'off' > change: nchan_max_channel_subscribers now always refers to subscribers > on this instance of Nchan, even when using Redis. > feature: subscribe/unsubscribe callbacks with nchan_subscribe_request > and nchan_unsubscribe_request > 1.0.4 (Oct. 28 2016) > security: fix crash when receiving large messages over websocket with > ws+nchan subprotocol > 1.0.3 (Sept. 3 2016) > feature: nchan_message_timeout and nchan_message_buffer_length can now > use nginx variables for dynamic values > fix: unsolicited websocket PONGs disconnected the subscriber in > violation of RFC6455 > fix: possible script error when getting channel from Redis > fix: possible incorrect message IDs when using Redis (thanks @supertong) > security: possible invalid memory access on publisher GET, POST, or > DELETE when using Redis and the publisher connection is terminated > before receiving a response > fix: correct publisher response code when nchan_authorize_request is > unavailable (502 instead of 500) > security: crash if publisher POSTs request with no Content-Length > header when using nchan_authorize_request > > https://nchan.slact.net/ > > Thanks, >Leo P. >
Bug#836134: Update nginx_http_push_module to nchan 1.0.2
Package: nginx Version: 1.10.1-1 The current nginx-extras package includes a very outdated nginx_http_push_module (by about 2 years). It has since been renamed to Nchan, and vastly updated. I am the developer (of both Nchan and the old nginx_http_push_module). You can read more about Nchan at https://nchan.slact.net I've already updated the packaging rules to build nchan as a dynamic module. You can find my nginx Debian package repo at https://github.com/slact/nginx-deb .
Bug#767941: watchdog: Ping option does not support IPv6
Package: watchdog Version: 5.12-1 Severity: normal Dear Maintainer, The ping = option in watchdog.conf does not support an IPv6 address. This means that IPv6-only systems cannot use the ping testing functionality of Watchdog. Setting ping= to an IPv6 literal address fails with: Starting watchdog daemon...watchdog: unknown host fe80::230:18ff:fec0:5339 failed! The same happens if the setting is configured as a hostname which has only an record. -- System Information: Debian Release: 7.0 Architecture: armhf (armv6l) Kernel: Linux 3.12.29+ (PREEMPT) 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 watchdog depends on: ii debconf [debconf-2.0] 1.5.49 ii libc6 2.13-38+rpi2 ii lsb-base 4.1+Debian8+rpi1 ii makedev2.3.1-92 ii udev 175-7.2 watchdog recommends no packages. watchdog suggests no packages. -- Configuration Files: /etc/watchdog.conf changed: max-load-1 = 24 max-load-5 = 18 max-load-15 = 12 watchdog-device = /dev/watchdog realtime= yes priority= 1 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733478: cron: jobs does'nt run multiples time per hour when a start minute is specified
Package: cron Version: 3.0pl1-124 Severity: normal Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? i needed to run a job at :01, 21 and 41 minutes every hour. * What exactly did you do (or not do) that was effective (or ineffective)? 1/20 * * * * /bin/echo this fails */20 * * * * /bin/echo this works * What was the outcome of this action? the job does'nt run, nothing shown in the logs. * What outcome did you expect instead? i hoped that '1/20 * * * * /bin/echo this fails' would have worked. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579171: vzctl: Support for ipv6 in debian-add_ip.sh not working properly
Package: vzctl Version: 3.0.23-12 Severity: normal debian-add_ip.sh produces idle configuration file interfaces for ipv6: iface venet0 inet6 static address ::1 netmask 128 up ifconfig venet0 add 2002:d5ef:d6ab::2/0 ipv6 starting to be passing out of VE only after commands like: # VE address: ip route add 2002:d5ef:d6ab::2/128 # HN address ip route add 2002:d5ef:d6ab::1/0 dev venet0 -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-4-openvz-amd64 (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/bash Versions of packages vzctl depends on: ii iproute 20080725-2 networking and traffic control too ii libc6 2.10.2-7 Embedded GNU C Library: Shared lib ii vzquota 3.0.12-3 server virtualization solution - q Versions of packages vzctl recommends: ii rsync 3.0.3-2fast remote file copy program (lik vzctl 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#525321: [Pkg-samba-maint] Bug#525321: samba: force create mode option no longer works
On Fri, 2009-04-24 at 12:04 +0200, Christian Perrier wrote:
Quoting Nick Nobody (m...@nikosapi.org):
What happens when you copy the file ?
I see the same behaviour than the one you see, with 3.3.3. However,
copying the file ends up with the right permissions.
I'm not entirely sure that what you see is a bug, actually. After all,
when moving a file, you expect permissions to remain as they are.
The same thing occurs even if I copy a file.
It doesn't on my side. Copying a file ends up with the expected
permissions.
Which is why I assume that experiencing the problem with mv only is
IMHO maybe not a bug.
If this is isn't a bug, then what's the point of the force create mode
option? Whether I'm copying or moving a file to the samba share, I'm
still *creating* a new file on the remote server. All newly created
files should at least have the same permissions as force create mode.
This seems to be pretty clearly laid-out in the smb.conf man page:
create mask (S)
When a file is created, the necessary permissions are calculated
according to the mapping from DOS modes to UNIX permissions, and
the resulting UNIX mode is then bit-wise ´AND´ed with this
parameter. This parameter may be thought of as a bit-wise MASK for
the UNIX modes of a file. Any bit not set here will be removed from
the modes set on a file when it is created.
The default value of this parameter removes the group and other
write and execute bits from the UNIX modes.
Following this Samba will bit-wise ´OR´ the UNIX mode created from
this parameter with the value of the force create mode parameter
which is set to 000 by default.
I'm pretty sure this is a bug, in the smb.conf manpage it says that the
mode given to the force create mode gets OR'd with the file's
permissions. This guarantees that you'll always have at *least* whatever
force create mode is set to. The way I understand this is: create
mask strips away permissions and force create mode adds them, no?
If I could reproduce the bug when copying a file, I would
agree. However I am not..:-)
Have you considered checking the umask settings which you're using?
Both the server and the client have a default umask of 0022 and I've
tried mounting the share with umask= and that doesn't help.
Another weird thing I've noticed (which is not in 3.0.24-6etch10):
nikos...@kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
nikos...@kubuntubox:~$ cp copytest /mnt/smb/archives/
nikos...@kubuntubox:~$ mv movetest /mnt/smb/archives/
teh-server:~# ls -l /mnt/md1/archives/{copy,move}test
-rwxr-xr-x 1 samba samba 0 2009-04-24 15:41 /mnt/md1/archives/copytest
-rwxrwxrwx 1 samba samba 0 2009-04-24 15:40 /mnt/md1/archives/movetest
Shouldn't the execute bits be wiped out by my create mask (0664)? And
why are the group and others' write bits being removed when copying?
Thanks for your patience,
nick
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
On Fri, 2009-04-24 at 22:30 +0200, Luk Claes wrote:
Nick Nobody wrote:
On Fri, 2009-04-24 at 12:04 +0200, Christian Perrier wrote:
Quoting Nick Nobody (m...@nikosapi.org):
What happens when you copy the file ?
I see the same behaviour than the one you see, with 3.3.3. However,
copying the file ends up with the right permissions.
I'm not entirely sure that what you see is a bug, actually. After all,
when moving a file, you expect permissions to remain as they are.
The same thing occurs even if I copy a file.
It doesn't on my side. Copying a file ends up with the expected
permissions.
Which is why I assume that experiencing the problem with mv only is
IMHO maybe not a bug.
If this is isn't a bug, then what's the point of the force create mode
option? Whether I'm copying or moving a file to the samba share, I'm
still *creating* a new file on the remote server. All newly created
files should at least have the same permissions as force create mode.
This seems to be pretty clearly laid-out in the smb.conf man page:
create mask (S)
When a file is created, the necessary permissions are calculated
according to the mapping from DOS modes to UNIX permissions, and
the resulting UNIX mode is then bit-wise ´AND´ed with this
parameter. This parameter may be thought of as a bit-wise MASK for
the UNIX modes of a file. Any bit not set here will be removed from
the modes set on a file when it is created.
The default value of this parameter removes the group and other
write and execute bits from the UNIX modes.
Following this Samba will bit-wise ´OR´ the UNIX mode created from
this parameter with the value of the force create mode parameter
which is set to 000 by default.
I'm pretty sure this is a bug, in the smb.conf manpage it says that the
mode given to the force create mode gets OR'd with the file's
permissions. This guarantees that you'll always have at *least* whatever
force create mode is set to. The way I understand this is: create
mask strips away permissions and force create mode adds them, no?
If I could reproduce the bug when copying a file, I would
agree. However I am not..:-)
Have you considered checking the umask settings which you're using?
Both the server and the client have a default umask of 0022 and I've
tried mounting the share with umask= and that doesn't help.
Another weird thing I've noticed (which is not in 3.0.24-6etch10):
nikos...@kubuntubox:~$ touch {copy,move}test; chmod 777 {copy,move}test
nikos...@kubuntubox:~$ cp copytest /mnt/smb/archives/
nikos...@kubuntubox:~$ mv movetest /mnt/smb/archives/
teh-server:~# ls -l /mnt/md1/archives/{copy,move}test
-rwxr-xr-x 1 samba samba 0 2009-04-24 15:41 /mnt/md1/archives/copytest
-rwxrwxrwx 1 samba samba 0 2009-04-24 15:40 /mnt/md1/archives/movetest
This is because a umask has no effect on a move operation, but it does
on a copy operation.
Shouldn't the execute bits be wiped out by my create mask (0664)? And
why are the group and others' write bits being removed when copying?
I guess copying nor moving is seen as creating a file. What's the
behaviour if you save a new file on the share?
Cheers
Luk
nikos...@kubuntubox:~$ touch /mnt/smb/archives/testfile
teh-server:~# ls -l /mnt/md1/archives/testfile
-rw-r--r-- 1 samba samba 0 2009-04-24 16:30 /mnt/md1/archives/testfile
When using the older version (3.0.24-6etch10) I get the expected result:
-rw-rw-r-- 1 samba samba 0 2009-04-24 16:29 /mnt/md1/archives/testfile
nick
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: Bug#525321: samba: force create mode option no longer works
On Fri, 2009-04-24 at 16:47 -0700, Steve Langasek wrote: So when you have Unix extensions enabled, the chmod operation is honored, overriding any defaults set on open by 'force create mode'. If you don't want Unix modes on the client to be honored, you should disable unix extensions. That makes sense, I recall reading that unix extensions (or something that has to do with that setting) for the etch version of samba was broken (it also explains some errors I'd get when doing certain file operations). I disabled unix extensions with version 2:3.2.5-4lenny2 and sure enough, it works. Thanks for your help and sorry for wasting your time, nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525321: [Pkg-samba-maint] Bug#525321: samba: force create mode option no longer works
On Thu, 2009-04-23 at 23:47 +0200, Christian Perrier wrote: Quoting m...@nikosapi.org (m...@nikosapi.org): Package: samba Version: 2:3.2.5-4lenny2 Severity: normal After upgrading to lenny (from etch) it seems that the force create mode option no longer works. However, if I downgrade samba to 3.0.24-6etch10 the option works as it should. Here's an example: nikos...@kubuntubox:~$ touch testfile; chmod 600 testfile nikos...@kubuntubox:~$ mv testfile /mnt/smb/archives/ teh-server:~# ls -l /mnt/md1/archives/testfile -rw--- 1 samba samba 0 2009-04-23 11:23 /mnt/md1/archives/testfile When using the older version of samba, the permissions of that file would have been -rw-rw-r-- which is consistent with what I have in my config file. What happens when you copy the file ? I see the same behaviour than the one you see, with 3.3.3. However, copying the file ends up with the right permissions. I'm not entirely sure that what you see is a bug, actually. After all, when moving a file, you expect permissions to remain as they are. The same thing occurs even if I copy a file. I'm pretty sure this is a bug, in the smb.conf manpage it says that the mode given to the force create mode gets OR'd with the file's permissions. This guarantees that you'll always have at *least* whatever force create mode is set to. The way I understand this is: create mask strips away permissions and force create mode adds them, no? An example should clear this up: 1. File's original mode:-rwx---rw- (0706) 2. create mask: -rw-rw-r-- (0664) 3. Resulting mode (AND of 1,2): -rwr-- (0604) 4. force create mode: -rw-rw (0660) 5. Final mode (OR of 3,4): -rw-rw-r-- (0664) Am I wrong in thinking that this is how it's supposed to work? nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#76084: Achieve the perfect size
Youre just 1 simple click away from adding inches to your manhood. http://www.Dressniners.com/ Achieve the perfect size -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#260984: Coming over
9 inches of massive manhood will always come in handy. http://www.Pleasuredromes.com/ Gorgeous breasts and lips -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#262865: Coming over
Watch Britney moan and cry in pleasure and ecstasy. http://www.alogigubm.com/ Hot sex on demand -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352167: Be warned, the changes are irreversible
6 inches is inadequate to pleasure your woman add inches now. http://www.Filadelphio.com/ Guaranteed Results in Weeks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#279001: You can be the Alpha Male
Proven to be effective in gaining inches for more than 90% of Men worldwide. http://www.Doplacaty.com/ You can be the Alpha Male -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
