Bug#922218: gnome-shell fills up logs with an stack trace
O Mér, 13-02-2019 ás 11:30 +, Simon McVittie escribiu: > Control: tags -1 + moreinfo > > On Wed, 13 Feb 2019 at 11:51:08 +0100, Sergio Villar wrote: > > gnome-shell is making my system unusable by completelly filling up > > the /var partition due to the errors it spits into several log > > files > > like syslog, user.log and messages. > > Are you using any GNOME Shell extensions? > > If you are, does this problem persist if you disable them? > > Does this problem persist if you upgrade gnome-shell, mutter and gjs > to the versions in unstable? (These versions should have migrated to > testing a while ago, but are being held up by uninstallability on > s390x; > the release team assure me that they intend to get these versions > into > buster before the release.) That made it. I upgraded gnome-shell to unstable version and the problem is gone. BR
Bug#922224: atop interferes with package acct's logging
Package: atop
Version: 2.2.6-4
Severity: important
On systems running stretch and systemd and with both the acct and the atop
packages installed, the process accounting logs in /var/log/account/ only
cover one out of every 24 hours. The pattern is:
accton |v3| 0.00| 0.00| 0.00| 0| 0| 4180.00|
0.00| 1857218569|Wed Feb 13 06:25:04 2019
[...]
atopacctd |v3| 0.00| 0.00|414389280.00| 0| 0| 0.00|
0.00| 7551|Thu Dec 27 08:20:13 2018
and then nothing. If I run "systemctl atopacct status" I see:
Feb 13 07:25:06 HOST atopacctd[755]: reactivate process accounting
This leads me to believe that the two packages are mutually incompatible
and should be declared as such (unless the incompatibility is removed,
of course). I'll now proceed to ban atop from my systems.
On a potentially related note, I see that /etc/init.d/atopacct checks
directories /var/account/pacct and /var/log/pacct but not /var/log/account,
and that the atop(1) man page refers to /var/account/pacct. There are also
(in /etc/logrotate.d/psacc{s,u}_atop) references to /etc/logrotate.d/psacct;
is any Debian package providing this file?
Bug#922218: gnome-shell fills up logs with an stack trace
Package: gnome-shell Version: 3.30.1-2 Severity: critical Justification: breaks the whole system Dear Maintainer, gnome-shell is making my system unusable by completelly filling up the /var partition due to the errors it spits into several log files like syslog, user.log and messages. All three of them are Gigabytes of size. The issue that is reported by gnome-shell (hundreds of times per second!) is the following: Feb 12 14:54:25 dori gnome-shell[5179]: Object St.Icon (0x556220576a40), has been already finalized. Impossible to set any property to it. Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: == Stack trace for context 0x55621f7d6340 == Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: #0 0x55621fc4b2b0 i resource:///org/gnome/shell/ui/osdWindow.js:223 (0x7f055c6c9b38 @ 231) Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: #1 0x7ffc616fdf90 I resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f057c0b5de0 @ 71) Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: #2 0x7ffc616fe710 b self-hosted:916 (0x7f057c0f1230 @ 367) Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: #3 0x7ffc616fe800 b resource:///org/gnome/gjs/modules/signals.js:128 (0x7f057c0d2230 @ 386) Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: #4 0x55621fc4b228 i resource:///org/gnome/shell/ui/layout.js:530 (0x7f055c603230 @ 127) Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: #5 0x55621fc4b180 i resource:///org/gnome/gjs/modules/_legacy.js:82 (0x7f057c0b5de0 @ 71) Feb 12 14:54:25 dori org.gnome.Shell.desktop[5179]: #6 0x55621fc4b0c0 i self-hosted:916 (0x7f057c0f1230 @ 367) I'm setting a critical severity because as you might imagine, once the var partition is full several unrelated software starts to break. Also for non technical users rebooting wouldn't be a solution as the logs will persist. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (800, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/40 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2 ii evolution-data-server3.30.4-1 ii gir1.2-accountsservice-1.0 0.6.45-1 ii gir1.2-atspi-2.0 2.30.0-5 ii gir1.2-freedesktop 1.58.3-2 ii gir1.2-gcr-3 3.28.0-4 ii gir1.2-gdesktopenums-3.0 3.28.1-1 ii gir1.2-gdm-1.0 3.30.1-1 ii gir1.2-geoclue-2.0 2.5.2-1 ii gir1.2-glib-2.0 1.58.3-2 ii gir1.2-gnomebluetooth-1.03.28.2-3 ii gir1.2-gnomedesktop-3.0 3.30.2-4 ii gir1.2-gtk-3.0 3.24.3-1 ii gir1.2-gweather-3.0 3.28.2-2 ii gir1.2-ibus-1.0 1.5.19-1 ii gir1.2-mutter-3 3.30.2-4 ii gir1.2-nm-1.01.14.4-4 ii gir1.2-nma-1.0 1.8.18-2 ii gir1.2-pango-1.0 1.42.4-6 ii gir1.2-polkit-1.00.105-25 ii gir1.2-rsvg-2.0 2.44.10-1 ii gir1.2-soup-2.4 2.64.2-2 ii gir1.2-upowerglib-1.00.99.9-2 ii gjs 1.52.4-1 ii gnome-backgrounds3.30.0-1 ii gnome-settings-daemon3.30.2-1 ii gnome-shell-common 3.30.1-2 ii gsettings-desktop-schemas3.28.1-1 ii libatk-bridge2.0-0 2.30.0-2 ii libatk1.0-0 2.30.0-2 ii libc62.28-5 ii libcairo21.16.0-2 ii libcanberra-gtk3-0 0.30-7 ii libcanberra0 0.30-7 ii libcroco30.6.12-3 ii libecal-1.2-19 3.30.4-1 ii libedataserver-1.2-233.30.4-1 ii libgcr-base-3-1 3.28.0-4 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgirepository-1.0-11.58.3-2 ii libgjs0g 1.52.4-1 ii libglib2.0-0 2.58.2-3 ii libglib2.0-bin 2.58.2-3 ii libgstreamer1.0-01.14.4-1 ii libgtk-3-0 3.24.3-1 ii libical3 3.0.4-3 ii libjson-glib-1.0-0
Bug#921656: firefox ignores theme setting in .config/gtk-3.0/settings.ini
Package: firefox Version: 65.0-1 Severity: normal firefox (same as thunderbird #921524) ignores gtk-application-prefer-dark-theme = true from .config/gtk-3.0/settings.ini but respects $GTK_THEME=Adwaita:dark All other gtk-3 apps works fine.
Bug#921524: thunderbird ignores theme setting in .config/gtk-3.0/settings.ini
Package: thunderbird Version: 1:60.5.0-3 Severity: normal thunderbird ignores gtk-application-prefer-dark-theme = true from .config/gtk-3.0/settings.ini but respects $GTK_THEME=Adwaita:dark All other apps works fine.
Bug#904976: GTK3 separate binary package
Could you make an additional binary package geeqie-gtk3, please. -- sergio.
Bug#921263: thunar: Thunar ignores dark theme
Package: thunar Version: 1.8.4-1 Severity: normal Thunar ignores GTK_THEME=Adwaita:dark and % cat .config/gtk-3.0/settings.ini [Settings] gtk-application-prefer-dark-theme = true while thunar-settings is dark with one of this setting.
Bug#920340: 1.9 shows the same problem
The from #919972 shows the same problem after upgrading to 1.9 Subject: [package on hold] unattended-upgrades result for : SUCCESS Unattended upgrade result: All upgrades installed Packages with upgradable origin but kept back: libcurl4 As I said in #919972 1.9 shows correct message "Packages with upgradable origin but kept back", but subject is wrong: "[package on hold]" -- sergio.
Bug#920340: unattended-upgrades: [package on hold] while now one package is on hold
Package: unattended-upgrades
Version: 0.93.1+nmu1
Severity: normal
I'm not able to test 1.9 as this is a production server.
mail from root:
Subject
[package on hold] unattended-upgrades result for 'host': True
Body
Unattended upgrade returned: True
Packages that were upgraded:
Packages with upgradable origin but kept back:
base-files
Unattended-upgrades log:
Initial blacklisted packages:
Initial whitelisted packages:
Starting unattended upgrades script
Allowed origins are: ['origin=Debian', 'origin=Debian Backports']
Package 'base-files' has conffile prompt and needs to be upgraded
manually
package 'base-files' not upgraded
Packages that will be upgraded:
% s apt-mark showhold
% apt policy base-files
base-files:
Installed: 9.9+deb9u6
Candidate: 9.9+deb9u7
Version table:
9.9+deb9u7 500
500 https://deb.debian.org/debian stretch/main amd64 Packages
*** 9.9+deb9u6 100
100 /var/lib/dpkg/status
% grep 2019-01-24 /var/log/unattended-upgrades/unattended-upgrades.log
2019-01-24 06:38:35,022 INFO Initial blacklisted packages:
2019-01-24 06:38:35,022 INFO Initial whitelisted packages:
2019-01-24 06:38:35,022 INFO Starting unattended upgrades script
2019-01-24 06:38:35,023 INFO Allowed origins are: ['origin=Debian',
'origin=Debian Backports']
2019-01-24 06:38:38,283 WARNING Package 'base-files' has conffile prompt and
needs to be upgraded manually
2019-01-24 06:38:39,003 INFO package 'base-files' not upgraded
2019-01-24 06:38:40,268 INFO Packages that will be upgraded:
-- System Information:
Debian Release: stretch
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (400,
'proposed-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages unattended-upgrades depends on:
ii apt1.4.9
ii apt-utils 1.4.9
ii debconf [debconf-2.0] 1.5.61
ii init-system-helpers1.48
ii lsb-base 9.20161125
ii lsb-release9.20161125
ii python33.5.3-1
ii python3-apt1.4.0~beta3
ii ucf3.0036
ii xz-utils 5.2.2-1.2+b1
Versions of packages unattended-upgrades recommends:
ii cron [cron-daemon] 3.0pl1-128+deb9u1
Versions of packages unattended-upgrades suggests:
pn bsd-mailx
ii exim4-daemon-heavy [mail-transport-agent] 4.89-2+deb9u3
ii needrestart3.3-1~bpo9+1
-- debconf information:
* unattended-upgrades/enable_auto_updates: true
* unattended-upgrades/origins_pattern:
"origin=Debian,codename=${distro_codename},label=Debian-Security";
Bug#920339: matrix-synapse: installation process hangs with unknown reason
Package: matrix-synapse
Version: 0.34.1.1-3~bpo9+1
Severity: serious
# apt -t stretch-backports install matrix-synapse
...
Setting up matrix-synapse (0.34.1.1-3~bpo9+1) ...
Synapse no longer includes a web client. To enable a web client, configure
web_client_location. To remove this warning, remove 'webclient' from the
'listeners'
configuration.
Config is missing missing macaroon_secret_key
Synapse no longer includes a web client. To enable a web client, configure
web_client_location. To remove this warning, remove 'webclient' from the
'listeners'
configuration.
Config is missing missing macaroon_secret_key
Progress: [ 99%]
[.]
% ps aux | grep matri
root 10624 0.0 0.1 56692 5376 pts/0S+ 13:09 0:00 sudo -E apt -t
stretch-backports install matrix-synapse
root 10625 0.0 1.2 92480 49980 pts/0S+ 13:09 0:02 apt -t
stretch-backports install matrix-synapse
root 11862 0.0 0.4 60952 18424 pts/1S+ 13:10 0:00 /usr/bin/perl
-w /usr/share/debconf/frontend /var/lib/dpkg/info/matrix-synapse.postinst
configure
root 11868 0.0 0.0 0 0 pts/1Z+ 13:10 0:00
[matrix-synapse.]
matrix-+ 11934 0.1 1.6 271972 67760 ?Ssl 13:11 0:04
/usr/bin/python3 -m synapse.app.homeserver --config-path
/etc/matrix-synapse/homeserver.yaml --config-path /etc/matrix-synapse/conf.d/
--daemonize
% apt policy
Package files:
100 /var/lib/dpkg/status
release a=now
100 https://deb.debian.org/debian stretch-backports/non-free amd64 Packages
release o=Debian
Backports,a=stretch-backports,n=stretch-backports,l=Debian
Backports,c=non-free,b=amd64
origin deb.debian.org
100 https://deb.debian.org/debian stretch-backports/contrib amd64 Packages
release o=Debian
Backports,a=stretch-backports,n=stretch-backports,l=Debian
Backports,c=contrib,b=amd64
origin deb.debian.org
100 https://deb.debian.org/debian stretch-backports/main amd64 Packages
release o=Debian
Backports,a=stretch-backports,n=stretch-backports,l=Debian
Backports,c=main,b=amd64
origin deb.debian.org
500 https://deb.debian.org/debian stretch-proposed-updates/contrib amd64
Packages
release
o=Debian,a=proposed-updates,n=stretch-proposed-updates,l=Debian,c=contrib,b=amd64
origin deb.debian.org
500 https://deb.debian.org/debian stretch-proposed-updates/main amd64 Packages
release
o=Debian,a=proposed-updates,n=stretch-proposed-updates,l=Debian,c=main,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian stretch-updates/main amd64 Packages
release o=Debian,a=stable-updates,n=stretch-updates,l=Debian,c=main,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian-security stretch/updates/non-free amd64
Packages
release
v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=non-free,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian-security stretch/updates/contrib amd64
Packages
release v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=contrib,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian-security stretch/updates/main amd64 Packages
release v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=main,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian stretch/non-free amd64 Packages
release v=9.7,o=Debian,a=stable,n=stretch,l=Debian,c=non-free,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian stretch/contrib amd64 Packages
release v=9.7,o=Debian,a=stable,n=stretch,l=Debian,c=contrib,b=amd64
origin deb.debian.org
990 https://deb.debian.org/debian stretch/main amd64 Packages
release v=9.7,o=Debian,a=stable,n=stretch,l=Debian,c=main,b=amd64
origin deb.debian.org
Pinned packages:
The only one file in apt/preferences.d is stretch:
% cat /etc/apt/preferences.d/stretch
Package: *
Pin: release o=Debian,n=stretch
Pin-Priority: 990
Package: *
Pin: release o=Debian,n=stretch-updates
Pin-Priority: 990
The only one file in apt/sources.list.d is stretch.list:
% cat /etc/apt/sources.list.d/stretch.list
deb https://deb.debian.org/debian stretch main contrib non-free
deb https://deb.debian.org/debian-security stretch/updates main contrib non-free
deb https://deb.debian.org/debian stretch-updates main contrib non-free
deb https://deb.debian.org/debian stretch-proposed-updates main contrib non-free
deb https://deb.debian.org/debian stretch-backports main contrib non-free
% cat /etc/apt/apt.conf.d/00autoremove
Apt::AutoRemove {
RecommendsImportant "false";
SuggestsImportant "false";
}
% cat /etc/apt/apt.conf.d/00no-recommends
APT::Install-Recommends "false";
% apt-mark showmanual
acpi-support-base
acpid
adduser
apt
apt-file
apt-listchanges
apt-transport-https
apt-utils
aptitude
base-files
base-passwd
bash
bash-completion
bind9-host
bootlogd
bsdmainutils
bsdutils
busybox
bzip2
console-setup
Bug#919972: unattended-upgrades: report says 'packages were upgraded' while they were not
On 22/01/2019 17:53, Bálint Réczey wrote: Could you please give a try to 1.9 or 1.10 when it is out? The version in sid can be run on stretch and it contains a huge number of fixes. You're right! The 1.9 says: Packages with upgradable origin but kept back: libcurl4 -- sergio.
Bug#895381: Severity
* micah anderson [2019-01-20 21:03:53 +0100]: > I'm not disputing this bug exists, I'm just trying to determine why it > is you set the severity to "Serious". As you are probably aware, this > severity indicates that this is a sever violation of Debian policy > (violates a "must" or "required" directive), or in the package > maintainer's opinion, makes the package unsuitable for release. Oh. In the package maintainer's opinion. I had missed that part; my apologies. No, I don't claim a policy violation on this one and of course I'll defer to the package maintainer's assessment. I do find the bug scary, though, due to the possibility of silent corruption, and have been running a privately patched version of the package for that reason.
Bug#919972: unattended-upgrades: report says 'packages were upgraded' while they were not
Package: unattended-upgrades Version: 0.93.1+nmu1 Severity: normal Looks like this is not a dup of #895892 or #895894. mail from unattended-upgrades: --- Unattended upgrade returned: True Packages that were upgraded: libcurl4 Unattended-upgrades log: Initial blacklisted packages: Initial whitelisted packages: Starting unattended upgrades script Allowed origins are: ['origin=Debian', 'origin=Debian Backports'] Packages that will be upgraded: libcurl4 Writing dpkg log to '/var/log/unattended-upgrades/unattended-upgrades-dpkg.log' All upgrades installed --- % grep libcurl4 /var/log/unattended-upgrades/unattended-upgrades-dpkg.log /nothing/ % apt policy libcurl4 libcurl4: Installed: 7.61.0-1 Candidate: 7.62.0-1 Version table: 7.63.0-1 200 200 https://deb.debian.org/debian sid/main amd64 Packages 7.62.0-1 400 400 https://deb.debian.org/debian buster/main amd64 Packages *** 7.61.0-1 100 100 /var/lib/dpkg/status # apt dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # apt install libcurl4=7.62.0-1 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libcurl4 : Depends: libssl1.1 (>= 1.1.1) but 1.1.0j-1~deb9u1 is to be installed E: Unable to correct problems, you have held broken packages. % apt policy Package files: 100 /var/lib/dpkg/status release a=now 500 https://deb.debian.org/debian stretch-backports/non-free amd64 Packages release o=Debian Backports,a=stretch-backports,n=stretch-backports,l=Debian Backports,c=non-free,b=amd64 origin deb.debian.org 500 https://deb.debian.org/debian stretch-backports/contrib amd64 Packages release o=Debian Backports,a=stretch-backports,n=stretch-backports,l=Debian Backports,c=contrib,b=amd64 origin deb.debian.org 500 https://deb.debian.org/debian stretch-backports/main amd64 Packages release o=Debian Backports,a=stretch-backports,n=stretch-backports,l=Debian Backports,c=main,b=amd64 origin deb.debian.org 500 https://deb.debian.org/debian stretch-proposed-updates/contrib amd64 Packages release o=Debian,a=proposed-updates,n=stretch-proposed-updates,l=Debian,c=contrib,b=amd64 origin deb.debian.org 500 https://deb.debian.org/debian stretch-proposed-updates/main amd64 Packages release o=Debian,a=proposed-updates,n=stretch-proposed-updates,l=Debian,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian stretch-updates/main amd64 Packages release o=Debian,a=stable-updates,n=stretch-updates,l=Debian,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian-security stretch/updates/non-free amd64 Packages release v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=non-free,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian-security stretch/updates/contrib amd64 Packages release v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=contrib,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian-security stretch/updates/main amd64 Packages release v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian stretch/non-free amd64 Packages release v=9.6,o=Debian,a=stable,n=stretch,l=Debian,c=non-free,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian stretch/contrib amd64 Packages release v=9.6,o=Debian,a=stable,n=stretch,l=Debian,c=contrib,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian stretch/main amd64 Packages release v=9.6,o=Debian,a=stable,n=stretch,l=Debian,c=main,b=amd64 origin deb.debian.org 200 https://deb.debian.org/debian experimental/non-free amd64 Packages release o=Debian,a=experimental,n=experimental,l=Debian,c=non-free,b=amd64 origin deb.debian.org 200 https://deb.debian.org/debian experimental/contrib amd64 Packages release o=Debian,a=experimental,n=experimental,l=Debian,c=contrib,b=amd64 origin deb.debian.org 200 https://deb.debian.org/debian experimental/main amd64 Packages release o=Debian,a=experimental,n=experimental,l=Debian,c=main,b=amd64 origin deb.debian.org 200 https://deb.debian.org/debian sid/non-free amd64 Packages release o=Debian,a=unstable,n=sid,l=Debian,c=non-free,b=amd64 origin deb.debian.org 200 https://deb.debian.org/debian sid/contrib amd64 Packages release o=Debian,a=unstable,n=sid,l=Debian,c=contrib,b=amd64 origin deb.debian.org 200
Bug#919707: matrix-synapse: Missing depends
On Fri, 18 Jan 2019 23:02:28 +0100 Kurt Roeckx wrote: You have python3-msgpack (>= 0.3.0), while it should be be >= 0.4.2. The python3-msgpack dependency is absent. % apt show matrix-synapse | grep msgpack % But it's required! # /etc/init.d/matrix-synapse start ERROR:root:Needed msgpack>=0.4.2 but it was not installed python3-pymacaroons dependency is OK: % aptitude why python3-pymacaroons i matrix-synapse Depends python3-pymacaroons % apt show matrix-synapse | grep jinja2 Suggests: python3-bleach (>= 1.4.2), python3-jinja2 (>= 2.8) but 2.9 is required: # /etc/init.d/matrix-synapse start ERROR:root:Needed Jinja2>=2.9 but it was not installed ERROR:root:Needed Jinja2>=2.9 but it was not installed Missing Requirements: python3-Jinja2>=2.9, python3-Jinja2>=2.9 To install run: sudo apt install python3-Jinja2>=2.9 python3-Jinja2>=2.9 -- sergio.
Bug#898863: debian/watch doesn't work properly
On Wednesday, January 16 2019, Joel Cross wrote: > On Thu, 20 Dec 2018, at 3:49 AM, Sergio Durigan Junior wrote: >> While checking my maintainer's dashboard (<https://udd.debian.org/dmd>), >> I noticed that we still haven't solved this problem. I realize life >> sometimes gets in the way and it's hard to commit time to packaging, but >> I decided to send this friendly ping anyway and see if you had the >> chance to solve the issues I pointed out below. > > Hi Sergio, Hey Joel, > Well, I've finally got there! Please take a look at the latest upload > (https://mentors.debian.net/package/python-cerberus) and let me know what you > think. Thanks, and sorry for the delay, I've been fighting a cold. The modifications look good, even though I prefer to have them pushed to the salsa git repo with proper comments and all. Can you please do that? One minor nit: the current Standards-Version is 4.3.0. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#919460: [Pkg-xen-devel] Bug#919460: xen: disk I/O problems on stretch PV guest restores after security update
* Hans van Kranenburg [2019-01-17 00:41:39 +0100]: > > After "reboot -f"ing some of the affected domUs (which made them > > functional again), I rebooted the dom0. This time all domUs were > > restored normally. (Of course those that still had their filesystems > > mounted read-only stayed that way.) > > > > Is anyone else seeing this? > > The usual questions here would be like "can you reproduce the issue" > etc... Because if you consistently can cause the problem to happen, > you're in a positition to start trying things. Since this only happened on the reboot immediately following the Xen upgrade, in order to reproduce it I would need to either try it on another system or downgrade Xen on my test system and upgrade it again. The latter doesn't look like a good use of my limited time. I will eventually want to upgrade my production dom0's. Any domU's that I care about on these systems will be shut down prior to the reboot (that was the main lesson for me from this test), but I can leave a canary behind and see what happens to it. So eventually I should have an idea whether this is reproducible across systems. This will take a few weeks, though: plenty of time for others to run into the same problem if it's reproducible. I've been wondering whether the observed behaviour might be explained in terms of the specific changes made by the latest security patches. I don't see any such obvious explanation myself, but maybe to an expert it would leap out; that's partly why I reported this. If this is the case, then maybe there is no fix other than documenting the issue in release notes. It's also conceivable that the bug is in that domU kernel rather than in Xen. I might set up canary domU's with 4.9.144 (stretch-proposed-updates) and/or 4.19.x.
Bug#919460: xen: disk I/O problems on stretch PV guest restores after security update
Source: xen Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11 Yesterday I upgraded a test dom0 to this version (from 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10; stretch amd64, Xeon E5430), then rebooted. Running domU's were saved and restored in the usual way. However, all PV domU's running stretch (both i386 and amd64, all kernel 4.9.130-2) lost write access to xvda on restore due to I/O errors. Sample kernel log attached. (/var/log/kern.log stopped recording entries, so I grabbed dmesg output to show what happened afterwards.) I also had PV domUs running jessie (kernel 3.16.59-1, again both i386 and amd64). These were restored successfully. In all cases, xvda is backed by an LVM logical volume local to the dom0. After "reboot -f"ing some of the affected domUs (which made them functional again), I rebooted the dom0. This time all domUs were restored normally. (Of course those that still had their filesystems mounted read-only stayed that way.) Is anyone else seeing this? Jan 15 07:40:46 bst1 kernel: [1096816.319075] Freezing user space processes ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.320237] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.321499] PM: freeze of devices complete after 0.113 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321501] suspending xenstore... Jan 15 07:40:46 bst1 kernel: [1096816.321540] PM: late freeze of devices complete after 0.034 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321582] PM: noirq freeze of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] xen:grant_table: Grant tables using version 1 layout Jan 15 07:40:46 bst1 kernel: [1096816.321609] Suspended for 122.096 seconds Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: noirq restore of devices complete after 0.098 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: early restore of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328857] PM: restore of devices complete after 6.076 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328909] Restarting tasks ... done. ...skipping... Jan 15 07:40:46 bst1 kernel: [1096816.319075] Freezing user space processes ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.320237] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Jan 15 07:40:46 bst1 kernel: [1096816.321499] PM: freeze of devices complete after 0.113 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321501] suspending xenstore... Jan 15 07:40:46 bst1 kernel: [1096816.321540] PM: late freeze of devices complete after 0.034 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321582] PM: noirq freeze of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] xen:grant_table: Grant tables using version 1 layout Jan 15 07:40:46 bst1 kernel: [1096816.321609] Suspended for 122.096 seconds Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: noirq restore of devices complete after 0.098 msecs Jan 15 07:40:46 bst1 kernel: [1096816.321609] PM: early restore of devices complete after 0.038 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328857] PM: restore of devices complete after 6.076 msecs Jan 15 07:40:46 bst1 kernel: [1096816.328909] Restarting tasks ... done. Jan 15 07:40:51 bst1 kernel: [1096821.985693] blk_update_request: I/O error, dev xvda, sector 0 [1096816.319075] Freezing user space processes ... (elapsed 0.001 seconds) done. [1096816.320237] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [1096816.321499] PM: freeze of devices complete after 0.113 msecs [1096816.321501] suspending xenstore... [1096816.321540] PM: late freeze of devices complete after 0.034 msecs [1096816.321582] PM: noirq freeze of devices complete after 0.038 msecs [1096816.321609] xen:grant_table: Grant tables using version 1 layout [1096816.321609] Suspended for 122.096 seconds [1096816.321609] PM: noirq restore of devices complete after 0.098 msecs [1096816.321609] PM: early restore of devices complete after 0.038 msecs [1096816.328857] PM: restore of devices complete after 6.076 msecs [1096816.328909] Restarting tasks ... done. [1096821.985693] blk_update_request: I/O error, dev xvda, sector 0 [1096821.988866] blk_update_request: I/O error, dev xvda, sector 0 [1096821.988892] blk_update_request: I/O error, dev xvda, sector 0 [1096821.988908] blk_update_request: I/O error, dev xvda, sector 12941838 [1096821.988950] Aborting journal on device dm-3-8. [1096821.991190] blk_update_request: I/O error, dev xvda, sector 12931074 [1096821.991213] Buffer I/O error on dev dm-3, logical block 139265, lost sync page write [1096821.991230] blk_update_request: I/O error, dev xvda, sector 3663168 [1096821.991247] blk_update_request: I/O error, dev xvda, sector 9413656 [1096821.991270] Aborting journal on device dm-1-8. [1096821.991334] Aborting journal on device dm-0-8. [1096821.991386] JBD2: Error -5 detected when updating journal
Bug#919326: msmtp: account default not found: no configuration file available
Dear Simon, Yes. I have now checked and I have .msmtprc as a symlink. If it is not a symlink then I have no problems and everything runs smooth. In any case this is the output you asked for: root@quetzalli:~# dmesg | grep apparmor | tail -n 20 [1064093.935900] audit: type=1400 audit(1547506649.916:130): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="torbrowser_tor" pid=14345 comm="apparmor_parser" [1064094.438967] audit: type=1400 audit(1547506650.420:131): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/lib/cups/backend/cups-pdf" pid=14346 comm="apparmor_parser" [1064094.440476] audit: type=1400 audit(1547506650.420:132): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=14346 comm="apparmor_parser" [1064094.461620] audit: type=1400 audit(1547506650.444:133): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd//third_party" pid=14346 comm="apparmor_parser" [1064094.520228] audit: type=1400 audit(1547506650.500:134): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="torbrowser_firefox" pid=14343 comm="apparmor_parser" [1064094.736714] audit: type=1400 audit(1547506650.716:135): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="system_tor" pid=14348 comm="apparmor_parser" [1064094.854220] audit: type=1400 audit(1547506650.836:136): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="libreoffice-oopslash" pid=14350 comm="apparmor_parser" [1064094.936866] audit: type=1400 audit(1547506650.916:137): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="torbrowser_plugin_container" pid=14347 comm="apparmor_parser" [1064095.090757] audit: type=1400 audit(1547506651.072:138): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/man" pid=14351 comm="apparmor_parser" [1064095.091543] audit: type=1400 audit(1547506651.072:139): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="man_filter" pid=14351 comm="apparmor_parser" [1064102.892009] audit: type=1400 audit(1547506658.872:150): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/evince" pid=14349 comm="apparmor_parser" [1064102.910914] audit: type=1400 audit(1547506658.892:151): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/evince//sanitized_helper" pid=14349 comm="apparmor_parser" [1064102.914186] audit: type=1400 audit(1547506658.896:152): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/evince-previewer" pid=14349 comm="apparmor_parser" [1064102.930416] audit: type=1400 audit(1547506658.912:153): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/evince-previewer//sanitized_helper" pid=14349 comm="apparmor_parser" [1064102.932260] audit: type=1400 audit(1547506658.912:154): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/bin/evince-thumbnailer" pid=14349 comm="apparmor_parser" [1064111.250930] audit: type=1400 audit(1547506667.232:155): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="libreoffice-soffice" pid=14344 comm="apparmor_parser" [1064111.253633] audit: type=1400 audit(1547506667.236:156): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="libreoffice-soffice//gpg" pid=14344 comm="apparmor_parser" [1064151.025521] audit: type=1400 audit(1547506707.004:157): apparmor="DENIED" operation="open" profile="/usr/bin/msmtp" name="/home/sergio/Private/.msmtprc" pid=14560 comm="msmtp" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [1064177.994021] audit: type=1400 audit(1547506733.971:158): apparmor="DENIED" operation="open" profile="/usr/bin/msmtp" name="/home/sergio/mail/msmtp/log.txt"
Bug#919326: msmtp: account default not found: no configuration file available
Package: msmtp Version: 1.8.1-2 Severity: grave Justification: renders package unusable Dear Maintainer, A few days ago, msmtp fails to work. It all seems to be related to the inability to read ~/.msmtprc file. In other words it seems that ~/.msmtprc needs to have mode 644. This is not at all desired since sensible (private) information can be included in that file. The package msmtp should run with no trouble when the user configuration file ~/.msmtprc has mode 600. I am sending you some useful output so that you can check the relevance of the situation (please note that I tried playing with stable, testing and sid versions of msmtp and I get the same output -this lead me to think whether the problem is with msmtp or with some other related package): >>>>>>>>> sergio@quetzalli:~$ echo "Hello World" | msmtp -d ser...@mendozza.org ignoring system configuration file /etc/msmtprc: No such file or directory ignoring user configuration file /home/sergio/.msmtprc: Permission denied falling back to default account msmtp: account default not found: no configuration file available >>>>>>>>>>>> As such, the bug leaves the package fully unusable. Cheers, Sergio. -- System Information: Debian Release: buster/sid Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages msmtp depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.28-5 ii libgnutls303.6.5-2 ii libgsasl7 1.8.0-8+b2 ii ucf3.0038+nmu1 Versions of packages msmtp recommends: ii ca-certificates 20180409 Versions of packages msmtp suggests: pn msmtp-mta -- debconf information: msmtp/sysconfig: false msmtp/port: 25 msmtp/maildomain: msmtp/tls: false msmtp/auto_from: true msmtp/host:
Bug#838490: ganglia: ship systemd service units
Package: ganglia Version: 3.6.0-7+b1 Severity: wishlist Tags: patch Dear Maintainer, Ganglia currently has no SystemD unit in debian. This is the first unit i do, but i think have the necessary to work, probably need more functions. I hope this is helpful! Thanks, Sergio. --- [Unit] Description=monitoring system for high-performance After=network.target [Service] ExecStart=/usr/sbin/gmond --foreground --pid-file /var/run/gmond.pid Type=simple KillMode=process Restart=always StandardError=syslog [Install] WantedBy=multi-user.target --System Information: Debian 9 Architecture: amd64 Kernel: Linux 4.9.0-7-amd64 Init: systemd (via /run/systemd/system)
Bug#898863: debian/watch doesn't work properly
On Friday, July 27 2018, I wrote: > On Friday, July 27 2018, Joel Cross wrote: > >> Hi Sergio, >> >> I have fixed this by switching the watch file to use the GitHub URL instead. >> Would you mind reviewing the latest package and uploading? > > Hi Joel, Hey Joel, While checking my maintainer's dashboard (<https://udd.debian.org/dmd>), I noticed that we still haven't solved this problem. I realize life sometimes gets in the way and it's hard to commit time to packaging, but I decided to send this friendly ping anyway and see if you had the chance to solve the issues I pointed out below. Thanks, > I remember we had a problem with using github vs. pypi on some other > package, so maybe switching from one to the other can cause problems? > I'm not sure. Either way, there's actually a simple fix for the > original watch file: you just have to use a capital C when naming the > project (i.e., Cerberus instead of cerberus). Another useful tip is to > go to the pypi.debian.net web page: > > https://pypi.debian.net/cerberus > > and look at the "watch" link: > > https://pypi.debian.net/Cerberus/watch > > it will show you a suggested version of the watch file to be used. The > version is outdate (3 instead of 4), but it's useful anyway. > > While at it, since we're going to upload this package, it's a nice idea > to (a) bump Standards-Version (latest is 4.1.5), and (b) mark the > python-cerberus-doc package as "Multi-Arch: foreign", as suggested by > the Multiarch hinter. > > After you've done that, I'll gladly upload it. > > BTW, before I forget: I fixed the git tag "debian/1.2-1" on the > repository. It was pointing to the wrong commit. I had to delete the > tag and recreate it on salsa, just FYI. > > Thanks, > > -- > Sergio > GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 > Please send encrypted e-mail if possible > http://sergiodj.net/ > -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#905342: it seems new kernel solved the problem
Hi, just updated the kernel (4.19.9-1) and it seems services start much faster now. thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#905342: [pkg-apparmor] Bug#905342: Bug#905342: apache fpm not working anymore
On 12/17/18 10:06 AM, intrigeri wrote: Ivan Sergio Borgonovo: Yes, I'm actually running tor, postgres, samba, postfix, dovecot, spamassassin/spamd... My question was: are you running them *in LXC containers*? Yes. One host doing nearly nothing other than apt-cacher-ng, one LXC guest running most of my LAN services. The problem is still there eg. Dec 16 15:01:57 caronte systemd[1]: Starting The PHP 7.0 FastCGI Process Manager Dec 16 15:04:36 caronte systemd[1]: Started The PHP 7.0 FastCGI Process Manager. I don't understand what's the problem here. Many services still need way too much time to start. Really I'm not really sure it's an apparmor problem. It just happened I noticed the slow down of many services when I upgraded apparmor. When I tried to diagnose it things seems to improve downgrading, but after checking better, there seems to be no correlation between apparmor version and this problem. Probably the problem was already there till it got worse enough to get caught. Thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#905342: [pkg-apparmor] Bug#905342: apache fpm not working anymore
On 12/16/18 9:23 PM, intrigeri wrote: Hi, intrigeri: Ivan Sergio Borgonovo: As you said probably apparmor seems not to be the culprit. Nov 04 20:21:13 kerberos audit[1280]: AVC apparmor="DENIED" operation="mount" info="failed type match" error=-13 profile="lxc-container-default-cgns" name="/sys/fs/cgroup/unified/" pid=1280 comm="systemd" fstype="cgroup2" srcname="cgroup2" flags="rw, nosuid, nodev, noexec" This one looks like a bug in the LXC AppArmor profiles, please report it against the lxc package. [...] … and many more processes confined under the lxc-container-default-cgns profile. Are you actually running dovecot, tor, postgres, sshd, smdb, Postfix, dhclient etc. in LXC containers? Or is the lxc-container-default-cgns profile somehow erroneously applied to these processes? Gentle ping on this? Sorry. Yes, I'm actually running tor, postgres, samba, postfix, dovecot, spamassassin/spamd... The problem is still there eg. Dec 16 15:01:57 caronte systemd[1]: Starting The PHP 7.0 FastCGI Process Manager Dec 16 15:04:36 caronte systemd[1]: Started The PHP 7.0 FastCGI Process Manager. -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#916470: rasdaemon: wrong homepage
Package: rasdaemon Version: 0.6.0-1.2 Severity: normal Homepage: https://apps.fedorahosted.org/packages/rasdaemon is outdated. The new one is https://pagure.io/rasdaemon
Bug#189920: Any update after 16 years?
On 30/11/2018 16:33, Colin Watson wrote: If you don't have anything constructive to add to the report, please don't add noise. May be you can explain how should I disable $MAIL on ssh login? -- sergio.
Bug#914865: unattended-updates: doesn't work with apt cache on tmpfs
Package: unattended-updates Version: 0.93.1+nmu1 Severity: normal I have /var/cache/apt mounted on tmpfs and all apt utils works fine. Except unattended-updates, which produces the following (and really wrong) error: % sudo unattended-upgrade An error occurred: 'Could not open file /var/cache/apt/archives/partial/ghostscript_9.26~dfsg-0+deb9u1_amd64.deb - open (2: No such file or directory)' The URI 'https://deb.debian.org/debian-security/pool/updates/main/g/ghostscript/ghostscript_9.26~dfsg-0+deb9u1_amd64.deb' failed to download, aborting % ls -l /var/cache/apt total 56M -rw-r--r-- 1 root root 28M 2018-11-28 07:26 pkgcache.bin -rw-r--r-- 1 root root 28M 2018-11-28 07:26 srcpkgcache.bin dist-upgrade works fine: % s apt dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: ghostscript libgs9 libgs9-common 3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 7446 kB of archives. After this operation, 36.9 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 https://cdn-aws.deb.debian.org/debian-security stretch/updates/main amd64 ghostscript amd64 9.26~dfsg-0+deb9u1 [98.6 kB] ...
Bug#914744: gdb ftbfs with Python 3.7
On Monday, November 26 2018, Matthias Klose wrote: > gdb ftbfs with Python 3.7. upstream version 8.2 build fine. > > x86_64-linux-gnu-g++ -x c++ -g -O2 -fdebug-prefix-map=/<>=. > -fstack-protector-strong -Wformat -Werror=format-security -I. > -I/<>/gdb -I/<>/gdb/common > -I/<>/gdb/config -DLOCALEDIR="\"/usr/share/locale\"" > -DHAVE_CONFIG_H -I/<>/gdb/../include/opcode > -I/<>/gdb/../opcodes/.. -I../bfd -I/<>/gdb/../bfd > -I/<>/gdb/../include -I../libdecnumber > -I/<>/gdb/../libdecnumber -I/<>/gdb/gnulib/import > -Ibuild-gnulib/import -DTUI=1 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > -I/usr/include/python3.7m -I/usr/include/python3.7m -Wall -Wpointer-arith > -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts > -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable > -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized > -Wformat-nonliteral -c -o elfread.o -MT elfread.o -MMD -MP -MF > ./.deps/elfread.Tpo /<>/gdb/elfread.c > /<>/gdb/python/python.c: In function 'bool > do_start_initialization()': > /<>/gdb/python/python.c:1710:45: error: too few arguments to > function 'int _PyImport_FixupBuiltin(PyObject*, const char*, PyObject*)' >_PyImport_FixupBuiltin (gdb_module, "_gdb"); > ^ > In file included from /usr/include/python3.7m/Python.h:126, > from /<>/gdb/python/python-internal.h:100, > from /<>/gdb/python/python.c:94: > /usr/include/python3.7m/import.h:112:17: note: declared here > PyAPI_FUNC(int) _PyImport_FixupBuiltin( > ^~ > make[3]: *** [Makefile:1621: python/python.o] Error 1 > make[3]: *** Waiting for unfinished jobs > make[3]: Leaving directory '/<>/build/objdir/gdb' > make[2]: *** [Makefile:8491: all-gdb] Error 2 > make[2]: Leaving directory '/<>/build/objdir' > make[1]: *** [Makefile:850: all] Error 2 Thanks for the report. FWIW, this has been fixed upstream by: commit aeab512851bf6ed623d1c6c4305b6ce05e51a10c Author: Paul Koning Date: Fri Jun 8 13:26:36 2018 -0400 Fix build issue with Python 3.7 Not sure why this hasn't been picked by the rebase. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#914318: sleepyhead: new upstream release (v1.1)
On Thursday, November 22 2018, I wrote: > On Wednesday, November 21 2018, Diederik de Haas wrote: > >> Although there isn't a tag for it at >> https://gitlab.com/sleepyhead/sleepyhead-code/ >> if you look at master's version.h, it shows version 1.1. > > Thanks for the report, I'll take care of this later today. Just an update on this: I'm trying to get in touch with the upstream maintainer and ask him to properly tag the repository with the release versions. I prefer to proceed once this is addressed upstream. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#914621: adduser: please allow a leading underscore in user names again
My apologies for not having notice the closely related #521883 before submitting this. They can't immediately be merged because of the severity mismatch, and the discussion in #521883 seems to have drifted somewhat. I do like the idea of having a separate NAME_REGEX for system users, although that's definitely wishlist material while I still see this bug as a regression.
Bug#914621: adduser: please allow a leading underscore in user names again
Package: adduser
Version: 3.115
Severity: minor
The current default value for NAME_REGEX is ^[a-z][-a-z0-9_]*\$ (since version
3.111 reenabled underscores in all but the leading position). Historically,
adduser has allowed leading underscores from at least version 3.11.2 until
version 3.77, except for a brief hiatus in versions 3.61 and 3.62.
I understand why one may want to discourage leading digits in usernames, but
this restriction on leading underscores seems to have arosen by accident. I'm
therefore setting the severity to "minor" rather than "wishlist". ("minor"
because one can override this in /etc/adduser.conf, of course.)
Bug#914318: sleepyhead: new upstream release (v1.1)
On Wednesday, November 21 2018, Diederik de Haas wrote: > Although there isn't a tag for it at > https://gitlab.com/sleepyhead/sleepyhead-code/ > if you look at master's version.h, it shows version 1.1. Thanks for the report, I'll take care of this later today. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/
Bug#914223: solr-jetty: doesn't remove records from statoverride after purge
Package: solr-jetty Version: 3.6.2+dfsg-10+deb9u2 Severity: serious Justification: Policy 10.9 solr-jetty was installed and purged from host. I'm not able to dist-upgrade more: dpkg: unrecoverable fatal error, aborting: unknown user 'jetty' in statoverride file % dpkg -l | grep solr % dpkg -l | grep jett %
Bug#912375: please consider specifying the full path name to wish in /usr/bin/ds9
Package: saods9 Version: 7.5+repack1-2 Severity: wishlist Some of our users have experienced breakage in Debian's /usr/bin/ds9 due to certain variable settings in their environment. Although this might be considered user error, it may be possible to alleviate this class of problem by hardening the ds9 script; please consider doing so. Both the problems I am aware of involved a private installation of Tcl/Tk taking precedence over the system one. In one case, the user had an installation of NASA's LHEASoft, with its own libtcl8.6 and libtk8.6 on the LD_LIBRARY_PATH search path; this issue is mentioned at https://heasarc.gsfc.nasa.gov/lheasoft/issues.html and could be worked around by unsetting LD_LIBRARY_PATH in the ds9 script. In the other case, LD_LIBRARY_PATH was unset but the user had a wish executable (from an AstroConda installation) ahead of /usr/bin/wish in the search path; this could be worked around by making the script exec /usr/bin/wish explicitly. (In both cases a contributing factor was that the LHEASoft/AstroConda installation lacked a working Tcl "xml" package, which ds9 depends on.) I've wondered whether there might be policy reasons against the above workarounds but couldn't find any. Section 10.4 of the Debian Policy Manual is silent about fully qualifying path names (outside of the #! bang path).
Bug#911240: festvox-ca-ona-hts: Weird 'copyright' sound at the beginning of synthesised speech
Dear Francis, Festival does not support UTF-8. You should send the text to festival with ISO-8859-15 encoding. The accented character ò is represented by two bytes in UTF-8. Festival interprets those two bytes as two ISO-8859-15 characters, one of them being the copyright symbol. That's why you are hearing "copyright". You can probably use iconv to do the character encoding conversion. Best Sergio El dc., 17 d’oct. 2018, 16:51, Francis Tyers va escriure: > Package: festvox-ca-ona-hts > Version: 1.3-2 > Severity: important > > Dear Maintainer, > >* What led up to the situation? > > I installed festvox-ca-ona-hts > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > I ran: > > $ echo "això és una prova" | festival --tts --language catalan > > >* What was the outcome of this action? > > It said "A ix copyright és una prova" > >* What outcome did you expect instead? > > It should say "això és una prova" > > -- 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=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8), > LANGUAGE=ca_AD.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages festvox-ca-ona-hts depends on: > ii festival 1:2.5.0-2 > ii festival-ca 3.0.6-1 > > festvox-ca-ona-hts recommends no packages. > > festvox-ca-ona-hts suggests no packages. > > -- no debconf information >
Bug#909770: i915: Does not show gdm greeter on eDP: Link Training failed at link rate = 270000, lane count = 2
I think this patch[1] might potentially fix it. I'd love to give it a try since I suffer this issue in many different situations (normal startup, attaching external monitors, random flickers...). BR [1] https://bugs.freedesktop.org/show_bug.cgi?id=105267 O Mér, 10-10-2018 ás 13:01 +0100, Simon McVittie escribiu: > Control: retitle 909770 i915: Does not show gdm greeter on eDP: Link > Training failed at link rate = 27, lane count = 2 > Control: severity 909770 important > Control: reassign 909770 src:linux > Control: affects 909770 gdm3 > > On Wed, 10 Oct 2018 at 13:22:37 +0200, Sergio Villar Senin wrote: > > Note that I've reproduced today this very same issue with lightdm > > as > > well, so I guess this is the confirmation that the bug is somewhere > > else. Graphics drivers maybe? > > Yes, this sounds like a graphics driver problem. Summarizing for > kernel/graphics maintainers: > > Original bug report: > > > Boot the computer, then wait for the login screen (gdm) to appear. > > > > The background of the plyumouth theme is shown but the list of > > users is not there as expected. > > > > Sometimes I press the power button and the system suspends to > > RAM. When resuming then the gdm login screen is there, *but* if I > > try to > > enter any session (GNOME) it does not work. The authentication > > seems > > to succeed but then the screen becomes blank and there is no > > possibility to even switch to the terminals via Ctr-Alt-Fx. > > Logs: https://pastebin.com/PiwQdiR2 and > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909770#17 > > Most relevant-looking log message: > > > laptop kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* > > [CONNECTOR:71:eDP-1] Link Training failed at link rate = 27, > > lane > > count = 2 > > Workaround (presumably suspend/resume retries link training): > > > BTW I noticed that it is possible to enter the session by following > > the > > next steps: > > 1- Boot > > 2- Nothing is shown. Press power button to suspend > > 3- Resume laptop. gdm is shown > > 4- Enter credentials. Succeeds. > > 5- Nothing is shown. Press power button to suspend > > 6- Resume laptop. GNOME session is opened and working normally > > Disabling Wayland in gdm does not work around this. Switching to > lightdm > works around this (presumably it chooses video modes in a way that > does > not exactly match GNOME?), but not entirely reliably. > > smcv >
Bug#910993: hidapi-cffi: new upstream bugfix release is available
Source: hidapi-cffi Version: 0.2.1-1.1 Severity: wishlist Version 0.2.2 of this software was released (still to GitHub) on 2017-11-22. The changes are: 1. Fix length parameter in send_feature_report 2. Make serial number optional in Device.open. I've just started experimenting with this package and almost immediately ran into the second issue above, which is a deviation from the documentation. Besides packaging the new version, I'd also suggest adding a debian/watch file based on the usual template for projects hosted on GitHub.
Bug#910927: bacula-sd.service should specify SupplementaryGroups=bacula
Package: bacula-sd Version: 7.4.4+dfsg-6 There is a difference in behaviour between the SystemV init script, /etc/init.d/bacula-sd, and its systemd counterpart. The former starts /usr/sbin/bacula-sd as root with command-line arguments to specify the uid and gid to run as, while in the latter systemd starts the daemon with User=bacula and Group=tape. This difference has an impact on the running daemon's supplementary group list: in the SystemV case this includes group bacula, but not in the systemd case. This can lead to problems when switching from SystemV to systemd (e.g., on upgrade from jessie to stretch) if the administrator has chosen to rely on membership in group bacula for access control. One scenario where this will occur is if bacula-sd is configured to use TLS credentials and the secret key is owned by root:bacula and not readable by others. (One may want the daemon to only have read access to the key, and group tape may have other members who should not have access.) Adding /etc/systemd/system/bacula-sd.service.d/groups.conf with [Service] SupplementaryGroups=bacula has been verified to cure the symptoms. I suggest including this setting in /lib/systemd/system/bacula-sd.service .
Bug#909770: gdm3: Does not show the list of users and fails to start any session
Note that I've reproduced today this very same issue with lightdm as well, so I guess this is the confirmation that the bug is somewhere else. Graphics drivers maybe?
Bug#910708: mpv: please compile with v4l support
On 10/10/2018 11:28, James Cowgill wrote: This is intentional. The tv support in mpv has been unmaintained for some time now and upstream recommends you use the v4l support from libavdevice instead. Eg: mpv av://v4l2:/dev/video0 OK. But in this case it should be specified in the man page. -- sergio.
Bug#910708: mpv: please compile with v4l support
Package: mpv Version: 0.29.1-1 Severity: normal Dear Maintainer, please add v4l support. % mpv --tv=driver=help Error parsing option tv (option not found)
Bug#910625: netperf: log files are not rotated
Package: netperf Version: 2.6.0-2.1 Severity: serious Justification: Policy 10.8 Netperf creates unlimited number of /var/log/netserver.debug_PID files (really about 65K limited). Policy 10.8 says: "Log files must be rotated occasionally so that they don’t grow" Moreover Policy 10.8 says: "log files should be named /var/log/netperf.log" Moreover it's not possible to change log file name. Looks like it's hard-coded. Related bug #904394.
Bug#641390: a2ps recommends nonexistent package cupsys-client
control: severity -1 serious Section 7.2 of the Debian Policy Manual reads in part: "The Recommends field should list packages that would be found together with this one in all but unusual installations." cupsys-client does not exist in Debian any more, not even as a virtual package (it was renamed to cups-client many years ago), so I submit that ap2s' continued mention of it in Recommends: is a policy violation.
Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)
Hi Ilias,
Today I performed a dist-upgrade and things are back to normal. goobook
runs fine as it should. Hope it doesn't go wrong again.
Cheers,
Sergio.
--
Sergio Mendoza
Instituto de Astronomia, UNAM
http://www.mendozza.org/sergio
On Mon, Sep 24, 2018 at 09:19:49AM -0500, Sergio Mendoza wrote:
> Hi Ilias,
>
> Nope. It's not python-httplib2. Can't find what can it be:
>
>
> root@izta:~# pip uninstall python-httplib2
> Cannot uninstall requirement python-httplib2, not installed
> root@izta:~# dpkg -l python-httplib2
> Desired=Unknown/Install/Remove/Purge/Hold
> | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ Name Version Architecture Description
> +++-==---==
> ii python-httplib 0.11.3-1 all comprehensive HTTP client library
> root@izta:~# ls -l /usr/lib/python2.7/dist-packages/httplib2/
> total 180
> -rw-r--r-- 1 root root 73431 Sep 5 01:45 __init__.py
> -rw-r--r-- 1 root root 59427 Sep 9 13:05 __init__.pyc
> -rw-r--r-- 1 root root 3828 Mar 29 20:28 iri2uri.py
> -rw-r--r-- 1 root root 3786 Sep 9 13:05 iri2uri.pyc
> -rw-r--r-- 1 root root 18999 Mar 29 20:28 socks.py
> -rw-r--r-- 1 root root 17500 Sep 9 13:05 socks.pyc
>
>
> Cheers,
>
> Sergio.
>
> --
> Sergio Mendoza
> Instituto de Astronomia, UNAM
> http://www.mendozza.org/sergio
>
>
>
>
> On Sat, Sep 22, 2018 at 02:36:45PM +0300, Ilias Tsitsimpis wrote:
> > Hi again,
> >
> > On Fri, Sep 21, 2018 at 01:46PM, Sergio Mendoza wrote:
> > > Unfortunately, no matter how hard I look for to spot the problem, I have
> > > not find the culprit package. I tried and tried, but couldn't. This is
> > > the reason I reported the bug to goobook. Sorry for not being more
> > > helpful.
> > >
> > > > > sergio@izta:~$ goobook query sergio
> > > > > Traceback (most recent call last):
> > > > > File "/usr/bin/goobook", line 11, in
> > > > > load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
> > > > > File "/usr/share/goobook/goobook/application.py", line 94, in main
> > > > > args.func(config, args)
> > > > > File "/usr/share/goobook/goobook/application.py", line 125, in
> > > > > do_query
> > > > > goobk = GooBook(config)
> > > > > File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> > > > > self.cache.load()
> > > > > File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> > > > > self.update()
> > > > > File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> > > > > self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
> > > > > File "/usr/share/goobook/goobook/goobook.py", line 395, in
> > > > > fetch_contacts
> > > > > res = self._get(query)
> > > > > File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
> > > > > connection_type=httplib2.HTTPSConnectionWithTimeout)
> > > > > File
> > > > > "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line
> > > > > 562, in new_request
> > > > > redirections, connection_type)
> > > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > > line 1608, in request
> > > > > (response, content) = self._request(conn, authority, uri,
> > > > > request_uri, method, body, headers, redirections, cachekey)
> > > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > > line 1350, in _request
> > > > > (response, content) = self._conn_request(conn, request_uri,
> > > > > method, body, headers)
> > > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > > line 1272, in _conn_request
> > > > > conn.connect()
> > > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > > line 1059, in connect
> > > > > raise SSLHandshakeError(e)
> > > > > httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED]
> > > > > certificate verify failed (_ssl.c:726)
> > > >
> > > > The above traceback mentions
> > > > "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py".
> > > > This is not the canonical location where Debian Python packages get
> > > > installed. I believe you have installed a different version of the
> > > > httplib2 module using pip. Could you please test using the Python module
> > > > provided by the python-httplib2 package?
> >
> > Please take a look at the comment above. It looks like you are not using
> > the official Debian package for python-httplib2, which is installed
> > under /usr/lib/python2.7/dist-packages/httplib2/ [1]. My guess is that
> > you have `pip install`-ed that package, so I would start by uninstalling
> > it and revert back to the Debian one.
> >
> > [1] https://packages.debian.org/sid/all/python-httplib2/filelist
> >
> > Cheers,
> >
> > --
> > Ilias
Bug#909770: gdm3: Does not show the list of users and fails to start any session
> I basically started without plyumouth enabled and the screen becomes black with the cursor in the top left corner of the screen. I obviously meant _disabled_ BR
Bug#909770: gdm3: Does not show the list of users and fails to start any session
O Ven, 28-09-2018 ás 12:47 +0100, Simon McVittie escribiu: > On Fri, 28 Sep 2018 at 11:01:09 +0200, Sergio Villar Senin wrote: > > O Xov, 27-09-2018 ás 22:39 +0100, Simon McVittie escribiu: > > > On Thu, 27 Sep 2018 at 23:16:05 +0200, Sergio Villar Senin wrote: > > > >The background of the plyumouth theme is shown but the list > > > > of > > > >users is not there as expected. > > How many screens are you using, and how are they connected? From > your > log it looks as though the answer might be one laptop internal panel, > connected via eDP, and no external screens. Is that correct? That's correct > If you are using a plymouth theme that resembles the background you > would > expect for the gdm greeter (user list), please retry with a different > plymouth theme such as softwave or lines and tell me what you see? > (What > I'm trying to determine here is whether the most recent pixels on > your > screen came from plymouth or gdm.) I basically started without plyumouth enabled and the screen becomes black with the cursor in the top left corner of the screen. At that point I tried to attach an external screen, and guess what? then I could see the VTs in F2,F3... and in F1 there was the gray background (nothing else just that) from gdm. > > I don't see anything specially wrong there except these lines: > > > > laptop kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* > > [CONNECTOR:71:eDP-1] Link Training failed at link rate = 27, > > lane > > count = 2 > > I agree. This looks more like a kernel bug than anything else - I'm > not > sure that this is anything that gdm3 can fix - but I'll try to get a > bit more information about what does and doesn't work before > reassigning. > > If you follow the workaround that you described (involving > suspend/resume), > do you get a similar warning about link training after resuming? After resuming everything seems to work fine and I haven't seen any error in the journal. > You said that lightdm works OK. Do you get similar warnings about > link > training when using lightdm? Not a single one. The last warning appears just after the "/usr/lib/gdm3/gdm-x-session[3172]: (II) modeset(0)" lines. > If you edit /etc/gdm3/daemon.conf and edit it to have > > [daemon] > WaylandEnable=false > > then go back to gdm, does that make it work? No luck, same result. BR
Bug#909770: gdm3: Does not show the list of users and fails to start any session
O Xov, 27-09-2018 ás 22:39 +0100, Simon McVittie escribiu: > Control: tags -1 + moreinfo > > On Thu, 27 Sep 2018 at 23:16:05 +0200, Sergio Villar Senin wrote: > >The background of the plyumouth theme is shown but the list of > >users is not there as expected. > > When this happens, what messages appear in the system log (systemd > journal or syslog)? > > > Sometimes I press the power button and the system suspends to > > RAM. When resuming then the gdm login screen is there, *but* if I > > try to > > enter any session (GNOME) it does not work. The authentication > > seems > > to succeed but then the screen becomes blank and there is no > > possibility to even switch to the terminals via Ctr-Alt-Fx. > > When this happens, what messages appear in the system log (systemd > journal or syslog)? This is the boot log https://pastebin.com/PiwQdiR2 I don't see anything specially wrong there except these lines: laptop kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* [CONNECTOR:71:eDP-1] Link Training failed at link rate = 27, lane count = 2 BTW I noticed that it is possible to enter the session by following the next steps: 1- Boot 2- Nothing is shown. Press power button to suspend 3- Resume laptop. gdm is shown 4- Enter credentials. Succeeds. 5- Nothing is shown. Press power button to suspend 6- Resume laptop. GNOME session is opened and working normally That's why I think it's probably the same bug although I am no longer sure it's a gdm3 issue, perhaps something related to the intel drivers. BR
Bug#909770: gdm3: Does not show the list of users and fails to start any session
Package: gdm3 Version: 3.30.1-1 Severity: critical Justification: breaks the whole system Dear Maintainer, * What led up to the situation? The problem appeared on 3.30 and is still a problem in 3.30.1 * What exactly did you do (or not do) that was effective (or ineffective)? Boot the computer, then wait for the login screen (gdm) to appear. * What was the outcome of this action? The background of the plyumouth theme is shown but the list of users is not there as expected. * What outcome did you expect instead? The normal list of users from gdm. Sometimes I press the power button and the system suspends to RAM. When resuming then the gdm login screen is there, *but* if I try to enter any session (GNOME) it does not work. The authentication seems to succeed but then the screen becomes blank and there is no possibility to even switch to the terminals via Ctr-Alt-Fx. I'm now using lightdm which works fine. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdm3 depends on: ii accountsservice 0.6.45-1 ii adduser 3.118 ii dconf-cli 0.30.0-1 ii dconf-gsettings-backend 0.30.0-1 ii debconf [debconf-2.0] 1.5.69 ii gir1.2-gdm-1.03.30.1-1 ii gnome-session [x-session-manager] 3.30.0-2 ii gnome-session-bin 3.30.0-2 ii gnome-settings-daemon 3.30.0-1 ii gnome-shell 3.30.0-2 ii gnome-terminal [x-terminal-emulator] 3.30.0-1 ii gsettings-desktop-schemas 3.28.1-1 ii libaccountsservice0 0.6.45-1 ii libaudit1 1:2.8.4-2 ii libc6 2.27-6 ii libcanberra-gtk3-00.30-6 ii libcanberra0 0.30-6 ii libgdk-pixbuf2.0-02.38.0+dfsg-6 ii libgdm1 3.30.1-1 ii libglib2.0-0 2.58.1-2 ii libglib2.0-bin2.58.1-2 ii libgtk-3-03.24.0-3 ii libkeyutils1 1.5.9-9.3 ii libpam-modules1.1.8-3.8 ii libpam-runtime1.1.8-3.8 ii libpam-systemd239-9 ii libpam0g 1.1.8-3.8 ii librsvg2-common 2.40.20-3 ii libselinux1 2.8-1+b1 ii libsystemd0 239-9 ii libwrap0 7.6.q-27 ii libx11-6 2:1.6.6-1 ii libxau6 1:1.0.8-1+b2 ii libxcb1 1.13-3 ii libxdmcp6 1:1.1.2-3 ii lsb-base 9.20170808 ii lxsession [x-session-manager] 0.5.3-2 ii lxterminal [x-terminal-emulator] 0.3.2-1 ii mutter [x-window-manager] 3.30.0-1 ii openbox [x-window-manager]3.6.1-7 ii policykit-1 0.105-21 ii procps2:3.3.15-2 ii ucf 3.0038 ii x11-common1:7.7+19 ii x11-xserver-utils 7.7+8 ii xterm [x-terminal-emulator] 337-1 Versions of packages gdm3 recommends: ii at-spi2-core2.30.0-2 ii desktop-base9.0.7 ii x11-xkb-utils 7.7+4 ii xserver-xephyr 2:1.20.1-3 ii xserver-xorg1:7.7+19 ii zenity 3.28.1-1 Versions of packages gdm3 suggests: ii gnome-orca3.28.1-3 pn libpam-fprintd ii libpam-gnome-keyring 3.28.2-1 -- debconf information excluded
Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)
Hi Ilias,
Nope. It's not python-httplib2. Can't find what can it be:
root@izta:~# pip uninstall python-httplib2
Cannot uninstall requirement python-httplib2, not installed
root@izta:~# dpkg -l python-httplib2
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==---==
ii python-httplib 0.11.3-1 all comprehensive HTTP client library
root@izta:~# ls -l /usr/lib/python2.7/dist-packages/httplib2/
total 180
-rw-r--r-- 1 root root 73431 Sep 5 01:45 __init__.py
-rw-r--r-- 1 root root 59427 Sep 9 13:05 __init__.pyc
-rw-r--r-- 1 root root 3828 Mar 29 20:28 iri2uri.py
-rw-r--r-- 1 root root 3786 Sep 9 13:05 iri2uri.pyc
-rw-r--r-- 1 root root 18999 Mar 29 20:28 socks.py
-rw-r--r-- 1 root root 17500 Sep 9 13:05 socks.pyc
Cheers,
Sergio.
--
Sergio Mendoza
Instituto de Astronomia, UNAM
http://www.mendozza.org/sergio
On Sat, Sep 22, 2018 at 02:36:45PM +0300, Ilias Tsitsimpis wrote:
> Hi again,
>
> On Fri, Sep 21, 2018 at 01:46PM, Sergio Mendoza wrote:
> > Unfortunately, no matter how hard I look for to spot the problem, I have
> > not find the culprit package. I tried and tried, but couldn't. This is
> > the reason I reported the bug to goobook. Sorry for not being more
> > helpful.
> >
> > > > sergio@izta:~$ goobook query sergio
> > > > Traceback (most recent call last):
> > > > File "/usr/bin/goobook", line 11, in
> > > > load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
> > > > File "/usr/share/goobook/goobook/application.py", line 94, in main
> > > > args.func(config, args)
> > > > File "/usr/share/goobook/goobook/application.py", line 125, in
> > > > do_query
> > > > goobk = GooBook(config)
> > > > File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> > > > self.cache.load()
> > > > File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> > > > self.update()
> > > > File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> > > > self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
> > > > File "/usr/share/goobook/goobook/goobook.py", line 395, in
> > > > fetch_contacts
> > > > res = self._get(query)
> > > > File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
> > > > connection_type=httplib2.HTTPSConnectionWithTimeout)
> > > > File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py",
> > > > line 562, in new_request
> > > > redirections, connection_type)
> > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > line 1608, in request
> > > > (response, content) = self._request(conn, authority, uri,
> > > > request_uri, method, body, headers, redirections, cachekey)
> > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > line 1350, in _request
> > > > (response, content) = self._conn_request(conn, request_uri, method,
> > > > body, headers)
> > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > line 1272, in _conn_request
> > > > conn.connect()
> > > > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py",
> > > > line 1059, in connect
> > > > raise SSLHandshakeError(e)
> > > > httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED]
> > > > certificate verify failed (_ssl.c:726)
> > >
> > > The above traceback mentions
> > > "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py".
> > > This is not the canonical location where Debian Python packages get
> > > installed. I believe you have installed a different version of the
> > > httplib2 module using pip. Could you please test using the Python module
> > > provided by the python-httplib2 package?
>
> Please take a look at the comment above. It looks like you are not using
> the official Debian package for python-httplib2, which is installed
> under /usr/lib/python2.7/dist-packages/httplib2/ [1]. My guess is that
> you have `pip install`-ed that package, so I would start by uninstalling
> it and revert back to the Debian one.
>
> [1] https://packages.debian.org/sid/all/python-httplib2/filelist
>
> Cheers,
>
> --
> Ilias
Bug#840660: lightdm: Error using VT_WAITACTIVE 7 on /dev/tty0: Interrupted system call
It looks to me like upstream commit robert.anc...@canonical.com-20170213034648-wvwh9evai55o7sm5, first released in lightdm 1.21.4, should adequately address this (by retrying the system call on EINTR). Am cherry-picking this into 1.18.3, will test then tag this bug accordingly. (Note to other would-be cherry-pickers: the commit depends on an earlier one, michael.te...@canonical.com-20161020085337-efsjna95ma6yio89.)
Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)
Hi Ilias,
Unfortunately, no matter how hard I look for to spot the problem, I have
not find the culprit package. I tried and tried, but couldn't. This is
the reason I reported the bug to goobook. Sorry for not being more
helpful.
Regards,
Sergio.
--
Sergio Mendoza
Instituto de Astronomia, UNAM
http://www.mendozza.org/sergio
On Fri, Sep 21, 2018 at 07:39:29PM +0300, Ilias Tsitsimpis wrote:
> Hi Sergio,
>
> On Sat, Sep 15, 2018 at 11:28AM, Sergio Mendoza wrote:
> > Hi again,
> >
> > Today after an upgrade once again the problem appears:
>
> Do you know which package you updated that broke goobook?
>
> > sergio@izta:~$ goobook query sergio
> > Traceback (most recent call last):
> > File "/usr/bin/goobook", line 11, in
> > load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
> > File "/usr/share/goobook/goobook/application.py", line 94, in main
> > args.func(config, args)
> > File "/usr/share/goobook/goobook/application.py", line 125, in do_query
> > goobk = GooBook(config)
> > File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> > self.cache.load()
> > File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> > self.update()
> > File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> > self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
> > File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contacts
> > res = self._get(query)
> > File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
> > connection_type=httplib2.HTTPSConnectionWithTimeout)
> > File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py",
> > line 562, in new_request
> > redirections, connection_type)
> > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
> > 1608, in request
> > (response, content) = self._request(conn, authority, uri, request_uri,
> > method, body, headers, redirections, cachekey)
> > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
> > 1350, in _request
> > (response, content) = self._conn_request(conn, request_uri, method,
> > body, headers)
> > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
> > 1272, in _conn_request
> > conn.connect()
> > File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
> > 1059, in connect
> > raise SSLHandshakeError(e)
> > httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> > verify failed (_ssl.c:726)
>
> The above traceback mentions
> "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py".
> This is not the canonical location where Debian Python packages get
> installed. I believe you have installed a different version of the
> httplib2 module using pip. Could you please test using the Python module
> provided by the python-httplib2 package?
>
> Cheers,
>
> --
> Ilias
Bug#908116: firewalld: blocks multicast dns resolution for home zone
O Xov, 20-09-2018 ás 17:22 +0200, Michael Biebl escribiu: > On Thu, 06 Sep 2018 11:20:41 +0200 Sergio Villar Senin > wrote: > > Package: firewalld > > Version: 0.6.1-2 > > Severity: normal > > > > Dear Maintainer, > > > >* What led up to the situation? > > > >Upgrading to sid's 0.6.1-2 > > > >* What exactly did you do (or not do) that was effective (or > > ineffective)? > > > >Multicast DNS (avahi) does not work at all with the new > > firewalld > >release. I haven't changed the configuration and it was working > >fine before the update. Actually downgrading to 0.4.4.5-2 makes > > it > >work again. > > > > Please test again with firewalld 0.6.2-1 and Linux kernel 4.18. Yes, it does work now!
Bug#908977: nbd-client: systemd doesn's start nbd exports
On 18/09/2018 10:48, Wouter Verhelst wrote: Otherwise, this would have to be done into packages such as PostgreSQL and OpenVPN too, which also use template units, and that way lies madness. Would you like to say OpenVPN will not automatically start each /etc/openvpn/*.conf on systemd host? Moreover, /usr/share/doc/openvpn/README.Debian.gz: In order to start/stop a particular VPN you may use: # service openvpn@VPN_NAME start or # systemctl start openvpn@VPN_NAME Would you like to say PostgreSQL will not automatically and need some systemctl enable magick? -- sergio.
Bug#909014: [pkg-gnupg-maint] Bug#909014: Bug#909014: pinentry-efl binary package build request
On 18/09/2018 00:26, Daniel Kahn Gillmor wrote: libsecret talks to the "secret service", which afaik is provided only by GNOME Keyring these days. In this case I though pinentry-efl (as qt and fltk versions) should not talk to libsecret. -- sergio.
Bug#909014: [pkg-gnupg-maint] Bug#909014: pinentry-efl binary package build request
On 17/09/2018 22:54, Daniel Kahn Gillmor wrote: i hadn't heard from any debian users that this was desirable Hope pkg-e-de...@lists.alioth.debian.org will say this is desirable. Is it possible to subscribe it to this bug? do you think that pinentry-efl should talk to libsecret (the way that pinentry-gnome3 and pinentry-gtk2 do), or do you think it should be independent of libsecret? I even don't understand why pinentry-gnome3/gtk2 depends on libsecret and pinentry-qt/fltk does not. Are them statically compiled to do not make debian package dependencies? Anyway I thought pkg-e-devel should provide a more complete answer. -- sergio.
Bug#909014: pinentry-efl binary package build request
Source: pinentry Version: 1.1.0-1 Severity: normal Dear Maintainer! Please make a new binary packages with --enable-pinentry-efl for enlightenment. https://github.com/gpg/pinentry/commit/948105b7a34ec9a9e5479d376b7c86bafee50a01
Bug#902056: unable to user user shell with user's env
But at leas I'm not able to run user shell with user's home. 'sudo -su user' doesn't work and 'sudo -Esu user' saves my $HOME (and all my other env). -- sergio.
Bug#902056: may be not a bug
Really I'm already not sure if this is a bug as sudo is alias to sudo -E, and $ /usr/bin/sudo -E ls works. -- sergio.
Bug#902056: should be "No ssh-agent could be contacted"
$ sudo ls ... /var/log/auth.log: sudo: pam_ssh_agent_auth: Beginning pam_ssh_agent_auth for user sergio sudo: pam_ssh_agent_auth: Attempting authentication: `sergio' as `sergio' using /etc/ssh/sudo_authorized_keys sudo: pam_ssh_agent_auth: Contacted ssh-agent of user sergio (1000) $ /usr/bin/sudo ls ... /var/log/auth.log: sudo: pam_ssh_agent_auth: Beginning pam_ssh_agent_auth for user sergio sudo: pam_ssh_agent_auth: Attempting authentication: `sergio' as `sergio' using /etc/ssh/sudo_authorized_keys sudo: pam_ssh_agent_auth: No ssh-agent could be contacted -- sergio.
Bug#908977: nbd-client: systemd doesn's start nbd exports
Package: nbd-client Version: 1:3.18-1 Severity: normal Without systemd /etc/init.d/nbd-client will start all shares from /etc/nbdtab at bootup. With systemd user need to manually add each share with "systemctl enable nbd@nbdX.service". Behaviour must be the same! Please make systemd to start all shares from nbdtab. While it's not fixed, please add brief explanation about "systemctl enable nbd@nbdX.service" workaround.
Bug#907491: closed by Paul Gevers (Re: goobook fails to authenticate)
Hi again,
Today after an upgrade once again the problem appears:
sergio@izta:~$ goobook query sergio
Traceback (most recent call last):
File "/usr/bin/goobook", line 11, in
load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
File "/usr/share/goobook/goobook/application.py", line 94, in main
args.func(config, args)
File "/usr/share/goobook/goobook/application.py", line 125, in do_query
goobk = GooBook(config)
File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
self.cache.load()
File "/usr/share/goobook/goobook/goobook.py", line 257, in load
self.update()
File "/usr/share/goobook/goobook/goobook.py", line 264, in update
self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contacts
res = self._get(query)
File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
connection_type=httplib2.HTTPSConnectionWithTimeout)
File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line
562, in new_request
redirections, connection_type)
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1608, in request
(response, content) = self._request(conn, authority, uri, request_uri,
method, body, headers, redirections, cachekey)
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1350, in _request
(response, content) = self._conn_request(conn, request_uri, method, body,
headers)
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1272, in _conn_request
conn.connect()
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1059, in connect
raise SSLHandshakeError(e)
httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
failed (_ssl.c:726)
Cheers,
Sergio.
On Thu, Sep 13, 2018 at 07:15:03AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the goobook package:
>
> #907491: goobook fails to authenticate
>
> It has been closed by Paul Gevers .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Paul Gevers
> by
> replying to this email.
>
>
> --
> 907491: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907491
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> Date: Thu, 13 Sep 2018 09:12:55 +0200
> From: Paul Gevers
> To: 907491-d...@bugs.debian.org
> Subject: Re: goobook fails to authenticate
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
> Thunderbird/52.9.1
>
> On Tue, 11 Sep 2018 12:54:45 -0500 Sergio Mendoza
> wrote:
> > Yes, goobook works fine and smooth.
>
> > On Tue, Sep 11, 2018 at 06:51:00PM +0200, Kurt Roeckx wrote:
> > > Now that bug #907278 is fixed, I think this is fixed too.
>
> So, let's mark this bug so. openssl has the appropriate versioned Breaks
> relation with the python-httplib2 package, so users of testing/buster
> are protected even during partial upgrade.
>
> Paul
>
> Date: Tue, 28 Aug 2018 13:10:06 -0500
> From: Sergio Mendoza
> To: Debian Bug Tracking System
> Subject: goobook fails to authenticate
> Reply-To: ser...@mendozza.org
> X-Mailer: reportbug 7.5.0
>
> Package: goobook
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> I'm running debian unstable. I have not been able to work properly with
> goobook and can't find a solution for it. It requires immediate assitance.
> This is happening in all computers I have with Debian (quite a few):
>
> sergio@izta:~$ goobook dquery sergio
> Traceback (most recent call last):
> File "/usr/bin/goobook", line 11, in
> load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
> File "/usr/share/goobook/goobook/application.py", line 94, in main
> args.func(config, args)
> File "/usr/share/goobook/goobook/application.py", line 130, in
> do_query_details
> goobk = GooBook(config)
> File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
> self.cache.load()
> File "/usr/share/goobook/goobook/goobook.py", line 257, in load
> self.update()
> File "/usr/share/goobook/goobook/goobook.py", line 264, in update
> self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
> File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contac
Bug#891392: Successfully compiled ad
Moreover, I was able to run two E (via X and wayland) simultaneously. -- sergio.
Bug#908720: seahorse: does not list passwords for the login keyring
O Mér, 12-09-2018 ás 21:49 -0400, Jeremy Bicha escribiu: > Control: tags -1 -moreinfo > > On Wed, Sep 12, 2018 at 8:06 PM Sergio Villar Senin < > svil...@igalia.com> wrote: > > What extra info would you need? > > In the View menu, try clicking Show Any. Oh I feel super stupid right now, that was it. Perhaps it is just that the default option changed in between, but not sure. You can close this now. BR
Bug#908721: [Pkg-utopia-maintainers] Bug#908721: firewalld: blocks mdns traffic on home zone (with mdns enabled)
O Xov, 13-09-2018 ás 02:59 +0200, Michael Biebl escribiu: > You already filed the same issue as #908116 > No need to file a duplicate. Oh I'm really sorry for that, my MTA was not working fine so I thought I haven't sent it yet. Feel free to close as dup. BR
Bug#908720: seahorse: does not list passwords for the login keyring
O Mér, 12-09-2018 ás 19:58 -0400, Jeremy Bicha escribiu: > Control: tags -1 moreinfo > > I can't reproduce this bug with the information you have provided. > > Note that seahorse continues to run in the background as a system > service. I recommend logging out and logging back after upgrading > seahorse. I did it and even rebooted the machine. The passwords are not shown. The only thing I can see is the ssh and gpg keys. I've tried in 2 different computers, one in sid and the other in testing and the bug is reproducible in both of them (both with 3.30 version). What extra info would you need? BR
Bug#908721: Acknowledgement (firewalld: blocks mdns traffic on home zone (with mdns enabled))
Actually I think the problem is worst than I thought as I cannot access any of the enabled services in the machine with updated firewalld. I've tried several, ssh, rdp, mdns... All of them are enabled in the active zone and none of them is opened in the firewall. I'd advice increasing the severity of the issue.
Bug#908721: firewalld: blocks mdns traffic on home zone (with mdns enabled)
Package: firewalld Version: 0.4.4.6-2 Severity: important Dear Maintainer, * What led up to the situation? Upgrade to 0.6.1 * What exactly did you do (or not do) that was effective (or ineffective)? Using avahi-discover to list discoverable services in my LAN * What was the outcome of this action? Nothing was shown * What outcome did you expect instead? Available discoverable services are shown I've activated mdns for home zone. The home zone is active but the mdns traffic is blocked. I confirm that downgrading to 0.4.4.6 fixes the issue with zero configuration changes. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=gl_ES.utf8, LC_CTYPE=gl_ES.utf8 (charmap=UTF-8), LANGUAGE=gl_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firewalld depends on: ii dbus 1.12.10-1 ii gir1.2-glib-2.01.58.0-1 ii iptables 1.6.2-1.1 ii policykit-10.105-21 ii python33.6.6-1 ii python3-dbus 1.2.8-2+b1 ii python3-gi 3.28.3-1 ii python3-slip-dbus 0.6.5-2 Versions of packages firewalld recommends: ii ebtables 2.0.10.4-5 ii ipset 6.34-1 firewalld suggests no packages. -- Configuration Files: /etc/firewalld/firewalld.conf [Errno 13] Permiso denegado: '/etc/firewalld/firewalld.conf' /etc/firewalld/lockdown-whitelist.xml [Errno 13] Permiso denegado: '/etc/firewalld/lockdown-whitelist.xml' -- no debconf information
Bug#908720: seahorse: does not list passwords for the login keyring
Package: seahorse Version: 3.30-1 Severity: normal Dear Maintainer, * What led up to the situation? Upgrading to 3.30 * What exactly did you do (or not do) that was effective (or ineffective)? Open seahorse. Click on the login keyring. * What was the outcome of this action? No password is shown * What outcome did you expect instead? Passwords are shown However I didn't report this as data loss because the passwords are there as services like email, browser etc... are working fine and I can retrieve passwords with utilities like gkeyring for example. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=gl_ES.utf8, LC_CTYPE=gl_ES.utf8 (charmap=UTF-8), LANGUAGE=gl_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages seahorse depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.0-1 ii gcr 3.28.0-1 ii gnome-keyring3.28.2-1 ii gnupg2.2.10-1 ii libatk1.0-0 2.28.1-1 ii libavahi-client3 0.7-4 ii libavahi-common3 0.7-4 ii libavahi-glib1 0.7-4 ii libc62.27-6 ii libgck-1-0 3.28.0-1 ii libgcr-base-3-1 3.28.0-1 ii libgcr-ui-3-13.28.0-1 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-0 2.58.0-2 ii libgpgme11 1.11.1-1 ii libgtk-3-0 3.24.0-1 ii libldap-2.4-22.4.46+dfsg-5 ii libsecret-1-00.18.6-2 ii libsoup2.4-1 2.64.0-2 Versions of packages seahorse recommends: ii openssh-client 1:7.8p1-1 seahorse suggests no packages. -- no debconf information -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=gl_ES.utf8, LC_CTYPE=gl_ES.utf8 (charmap=UTF-8), LANGUAGE=gl_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages seahorse depends on: ii dconf-gsettings-backend [gsettings-backend] 0.30.0-1 ii gcr 3.28.0-1 ii gnome-keyring3.28.2-1 ii gnupg2.2.10-1 ii libatk1.0-0 2.28.1-1 ii libavahi-client3 0.7-4 ii libavahi-common3 0.7-4 ii libavahi-glib1 0.7-4 ii libc62.27-6 ii libgck-1-0 3.28.0-1 ii libgcr-base-3-1 3.28.0-1 ii libgcr-ui-3-13.28.0-1 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-0 2.58.0-2 ii libgpgme11 1.11.1-1 ii libgtk-3-0 3.24.0-1 ii libldap-2.4-22.4.46+dfsg-5 ii libsecret-1-00.18.6-2 ii libsoup2.4-1 2.64.0-2 Versions of packages seahorse recommends: ii openssh-client 1:7.8p1-1 seahorse suggests no packages. -- no debconf information
Bug#908719: gtk: cursor indicator lost in gnome-terminal when switching applications
Package: libgtk-3-0 Version: 3.24.0-1 Severity: important File: gtk Dear Maintainer, When you open a gnome-terminal and then switch to another window then the blinking cursor is lost. You can recover it by switching tabs in gnome-terminal. Apparently only Wayland sessions are affected. Reported upstream here: https://gitlab.gnome.org/GNOME/gtk/issues/1316 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=gl_ES.utf8, LC_CTYPE=gl_ES.utf8 (charmap=UTF-8), LANGUAGE=gl_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgtk-3-0:amd64 depends on: ii adwaita-icon-theme 3.28.0-1 ii hicolor-icon-theme 0.17-2 ii libatk-bridge2.0-0 2.26.2-1 ii libatk1.0-0 2.28.1-1 ii libc62.27-6 ii libcairo-gobject21.15.12-1 ii libcairo21.15.12-1 ii libcolord2 1.3.3-2 ii libcups2 2.2.8-5 ii libepoxy01.4.3-1 ii libfontconfig1 2.13.0-5 ii libfreetype6 2.8.1-2 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-0 2.58.0-2 ii libgtk-3-common 3.24.0-1 ii libharfbuzz0b1.8.8-2 ii libjson-glib-1.0-0 1.4.2-4 ii libpango-1.0-0 1.42.4-2 ii libpangocairo-1.0-0 1.42.4-2 ii libpangoft2-1.0-01.42.4-2 ii librest-0.7-00.8.0-2 ii libsoup2.4-1 2.64.0-2 ii libwayland-client0 1.16.0-1 ii libwayland-cursor0 1.16.0-1 ii libwayland-egl1 1.16.0-1 ii libx11-6 2:1.6.6-1 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-1 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxinerama1 2:1.1.4-1 ii libxkbcommon00.8.2-1 ii libxml2 2.9.4+dfsg1-7+b1 ii libxrandr2 2:1.5.1-1 ii shared-mime-info 1.9-2 Versions of packages libgtk-3-0:amd64 recommends: ii libgtk-3-bin 3.24.0-1 Versions of packages libgtk-3-0:amd64 suggests: ii gvfs 1.38.0-2 ii librsvg2-common 2.40.20-3 -- no debconf information
Bug#891392: Successfully compiled ad
I've just successfully compiled (and started) 0.22.3-2 with the patch above. It works, but not suitable for daily usage (no screen rotation, multiple glitches and artefacts, slow response for some apps) it broke X11 support for my own setup. But it doesn't break X11 support for me -- sergio.
Bug#907491: goobook fails to authenticate
Yes, goobook works fine and smooth. Thanks, Sergio. -- Sergio Mendoza Instituto de Astronomia, UNAM http://www.mendozza.org/sergio On Tue, Sep 11, 2018 at 06:51:00PM +0200, Kurt Roeckx wrote: > Now that bug #907278 is fixed, I think this is fixed too. >
Bug#908546: nbd-client: systemd nbd@.service device init
Package: nbd-client Version: 1:3.18-1 Severity: normal I have nbd1 IP NAME in /etc/nbdtab I have /dev/nbd1 /mountpoint ext4 _netdev,errors=remount-ro 0 0 in /etc/fstab So I can do nbd-client nbd1, and get mounted /mountpoint. But it is not started automatically after reboot. OK, I've created /etc/systemd/system/dev-nbd1.device.requires and symlinked nbd@.service here: ln -s /lib/systemd/system/nbd@.service /etc/systemd/system/dev-nbd1.device.requires/ But it is still not started automatically after reboot, as %i in nbd@.service is dev-nbd1 and not nbd1 and nbd-client cat't init dev-nbd1. So I've created nbd1.service in the /etc/systemd/system, replaced %i with nbd1 and symlinked it into /etc/systemd/system/dev-nbd1.device.requires And only now I got /mountpoint mounted after reboot.
Bug#908116: Missing files
These are the two missing files from the original report ---> firewalld.conf # firewalld config file # default zone # The default zone used if an empty zone string is used. # Default: public DefaultZone=public # Minimal mark # Marks up to this minimum are free for use for example in the direct # interface. If more free marks are needed, increase the minimum # Default: 100 MinimalMark=100 # Clean up on exit # If set to no or false the firewall configuration will not get cleaned up # on exit or stop of firewalld # Default: yes CleanupOnExit=yes # Lockdown # If set to enabled, firewall changes with the D-Bus interface will be limited # to applications that are listed in the lockdown whitelist. # The lockdown whitelist file is lockdown-whitelist.xml # Default: no Lockdown=no # IPv6_rpfilter # Performs a reverse path filter test on a packet for IPv6. If a reply to the # packet would be sent via the same interface that the packet arrived on, the # packet will match and be accepted, otherwise dropped. # The rp_filter for IPv4 is controlled using sysctl. # Default: yes IPv6_rpfilter=yes # IndividualCalls # Do not use combined -restore calls, but individual calls. This increases the # time that is needed to apply changes and to start the daemon, but is good for # debugging. # Default: no IndividualCalls=no # LogDenied # Add logging rules right before reject and drop rules in the INPUT, FORWARD # and OUTPUT chains for the default rules and also final reject and drop rules # in zones. Possible values are: all, unicast, broadcast, multicast and off. # Default: off LogDenied=off # AutomaticHelpers # For the secure use of iptables and connection tracking helpers it is # recommended to turn AutomaticHelpers off. But this might have side effects on # other services using the netfilter helpers as the sysctl setting in # /proc/sys/net/netfilter/nf_conntrack_helper will be changed. # With the system setting, the default value set in the kernel or with sysctl # will be used. Possible values are: yes, no and system. # Default: system AutomaticHelpers=system ---> lockdown-whitelist.xml
Bug#908116: firewalld: blocks multicast dns resolution for home zone
Package: firewalld Version: 0.6.1-2 Severity: normal Dear Maintainer, * What led up to the situation? Upgrading to sid's 0.6.1-2 * What exactly did you do (or not do) that was effective (or ineffective)? Multicast DNS (avahi) does not work at all with the new firewalld release. I haven't changed the configuration and it was working fine before the update. Actually downgrading to 0.4.4.5-2 makes it work again. The mdns service is enabled for the home zone BTW. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=gl_ES.utf8, LC_CTYPE=gl_ES.utf8 (charmap=UTF-8), LANGUAGE=gl_ES.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firewalld depends on: ii dbus 1.12.10-1 ii gir1.2-glib-2.01.58.0-1 ii iptables 1.6.2-1.1 ii policykit-10.105-21 ii python33.6.6-1 ii python3-dbus 1.2.8-2+b1 ii python3-gi 3.28.2-1+b1 ii python3-slip-dbus 0.6.5-2 Versions of packages firewalld recommends: ii ebtables 2.0.10.4-5 ii ipset 6.34-1 firewalld suggests no packages. -- Configuration Files: /etc/firewalld/firewalld.conf [Errno 13] Permiso denegado: '/etc/firewalld/firewalld.conf' /etc/firewalld/lockdown-whitelist.xml [Errno 13] Permiso denegado: '/etc/firewalld/lockdown-whitelist.xml' -- no debconf information
Bug#907491: goobook fails to authenticate
Package: goobook
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I'm running debian unstable. I have not been able to work properly with
goobook and can't find a solution for it. It requires immediate assitance.
This is happening in all computers I have with Debian (quite a few):
sergio@izta:~$ goobook dquery sergio
Traceback (most recent call last):
File "/usr/bin/goobook", line 11, in
load_entry_point('goobook==1.9', 'console_scripts', 'goobook')()
File "/usr/share/goobook/goobook/application.py", line 94, in main
args.func(config, args)
File "/usr/share/goobook/goobook/application.py", line 130, in
do_query_details
goobk = GooBook(config)
File "/usr/share/goobook/goobook/goobook.py", line 59, in __init__
self.cache.load()
File "/usr/share/goobook/goobook/goobook.py", line 257, in load
self.update()
File "/usr/share/goobook/goobook/goobook.py", line 264, in update
self.contacts = list(self._parse_contacts(gc.fetch_contacts()))
File "/usr/share/goobook/goobook/goobook.py", line 395, in fetch_contacts
res = self._get(query)
File "/usr/share/goobook/goobook/goobook.py", line 371, in _get
connection_type=httplib2.HTTPSConnectionWithTimeout)
File "/usr/local/lib/python2.7/dist-packages/oauth2client/client.py", line
562, in new_request
redirections, connection_type)
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1608, in request
(response, content) = self._request(conn, authority, uri, request_uri,
method, body, headers, redirections, cachekey)
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1350, in _request
(response, content) = self._conn_request(conn, request_uri, method, body,
headers)
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1272, in _conn_request
conn.connect()
File "/usr/local/lib/python2.7/dist-packages/httplib2/__init__.py", line
1059, in connect
raise SSLHandshakeError(e)
httplib2.SSLHandshakeError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify
failed (_ssl.c:726)
>>>>>
Cheers,
Sergio
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages goobook depends on:
ii python2.7.15-3
ii python-gdata 2.0.18+dfsg1-2
ii python-httplib2 0.9.2+dfsg-1
ii python-oauth2client 4.1.2-3
ii python-pkg-resources 39.2.0-1
ii python-setuptools 39.2.0-1
ii python-simplejson 3.15.0-1+b1
goobook recommends no packages.
Versions of packages goobook suggests:
ii python-keyring 13.1.0-1
Bug#906907: ITP: pw -- A simple command-line password manager
On Wednesday, August 22 2018, Dashamir Hoxha wrote: > Package: wnpp > Severity: wishlist > > Description: > A simple command-line password manager that keeps passwords inside a > gpg encrypted tgz archive. The content of the archive is a directory tree > with a file for each password entry. The first line of the file is the > password, and the rest can optionally be additional or related info. > It provides commands for manipulating the passwords, allowing the user > to add, remove, edit, generate passwords etc. > > Repository: https://gitlab.com/dashohoxha/pw > Documentation: https://dashohoxha.gitlab.io/pw/man/ What changed between this attempt and your last one? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903880 -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#905342: [pkg-apparmor] Bug#905342: apache fpm not working anymore
Previously it was unset (default value, it should be 15s), now it is set to 120s (service generally start after 110s). Surprisingly starting the service manually succeed immediately. Doing some test (booting and rebooting to see what was going on) I noticed php-fpm may not start even with the previous version of apparmor (still with default setting but much less frequently than with the newer apparmor). So probably apparmor isn't even the main culprit and just made it enough worse to make it noticeable. I'm trying to review any package that was upgraded in the past month to see if anything other than apparmor could be related but the only candidate seems to be systemd that has been upgraded several time in the past 30 days. If you've any suggestion on how to investigate the problem further so i can at least relate it to the correct package they will be welcome. On 08/15/2018 03:14 AM, Seth Arnold wrote: On Tue, Aug 14, 2018 at 01:01:59AM +0200, Ivan Sergio Borgonovo wrote: It seems that the new apparmor makes php-fpm start time sensibly higher and systemd timeout. There is a correlation between php-fpm slowing down and the new version of apparmor but at the moment I just increased systemd timeout (TimeoutStartSec). What was the old value, what is the new value? Thanks -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#905342: apache fpm not working anymore
Hi, finally I've something interesting that may help to fix the problem. It seems that the new apparmor makes php-fpm start time sensibly higher and systemd timeout. There is a correlation between php-fpm slowing down and the new version of apparmor but at the moment I just increased systemd timeout (TimeoutStartSec). If you've any suggest to collect any information that could be useful let me know. On 08/04/2018 04:02 AM, intrigeri wrote: Control: tag -1 + moreinfo Hi Ivan, Ivan Sergio Borgonovo: I've a lxc guest running apache php fpm for horde. lxc guest and host both were running apparmor. Host was updated from 2.12-5 to 2.13-6. Guest was updated from 2.13-4 to 2.13-6. Can you confirm this happens on Debian testing? What exact kernel are you running? After upgrading apparmor horde stopped working. I downgraded apparmor on the host and still horde on the guest was not working. After downgrading apparmor on the guest horde started to work again. Problems seems related to apparmor recipes rather than in binaries since by mistake I forgot to downgrade the apparmor package in the guest and things were working. I'm curious how AppArmor is involved, because AFAIK Debian testing does not enable any AppArmor confinement for Apache/PHP: - do you have libapache2-mod-apparmor installed? did you do anything to enable and use it? - I see that recent php-fpm have support for switching AppArmor "hats"; did you enable this? related log entries may be Aug 1 19:46:50 caronte kernel: [265475.231940] audit: type=1400 audit(1533145610.777:245): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="klogd" pid=19732 comm="apparmor_parser" Sadly, this one is irrelevant. Please provide some more info: - the output of "journalctl -b | grep apparmor" - the output of "aa-status" Also, https://wiki.debian.org/AppArmor/Debug might help. Cheers, -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#906063: Building package with SOURCE_ONLY_CHANGES=yes generates invalid *_source.changes file
Package: pbuilder Version: 0.229.3 Severity: normal Hi there, While building the cvc4 package for upload, I tried setting SOURCE_ONLY_CHANGES=yes in order to generate a *_source.changes file. Everything was apparently fine, but when I tried to upload to changes file, I got the following error: $ dput ftp-master cvc4_1.6-2_source.changes Uploading cvc4 using ftp to ftp-master (host: ftp.upload.debian.org; directory: /pub/UploadQueue/) running allowed-distribution: check whether a local profile permits uploads to the target distribution running protected-distribution: warn before uploading to distributions where a special policy applies running checksum: verify checksums before uploading Bad checksums on cvc4_1.6-2_source.changes: Checksum mismatch for file cvc4_1.6-2.dsc: b65d2b868fd05a6aeb7606e5f03a05f3 != f83d68e6a9f76c3a887d3ff6e7b498f9 Comparing the cvc4_1.6-2_source.changes file against the cvc4_1.6-2_amd64.changes file, one can see that the checksum for the cvc4_1.6-2.dsc file is indeed different between them. In the end, I had to do a normal upload. I'm using gbp buildpackage with pbuilder behind the curtains, and my config files are: $ cat .pbuilderrc # Automatically sign builds. AUTO_DEBSIGN=yes PDEBUILD_PBUILDER=cowbuilder BUILDRESULT=$PWD/../ SOURCE_ONLY_CHANGES=yes $ cat .gbp.conf Config file for git-buildpackage [DEFAULT] pristine-tar = True # Tell git-buildpackage how to clean the source tree. This is needed # for pbuilder. cleaner = fakeroot debian/rules clean # This is how we invoke pbuilder, arguments passed to git-buildpackage # will be passed to dpkg-buildpackage in the chroot. builder = /usr/bin/git-pbuilder [import-orig] # Always merge the upstream/ branch onto the master/ branch. merge = True [buildpackage] # Always sign tags sign-tags = True # My key ID keyid = BLABLA # Always use git-pbuilder git-pbuilder = True # ... and always make sure that our builder is pbuilder. git-builder = pbuilder [dch] full = True release = True spawn-editor = always [clone] verbose = True Any advices on what's going on? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#889780: O: stomper -- Python client implementation of the STOMP protocol
On Tuesday, February 06 2018, Tobias Frost wrote: > The current maintainer of stomper, Simon Chopin , > is apparently not active anymore. Therefore, I orphan this package now. Hi Tobias, The stomper package is maintained by the Debian Python Modules Team (DPMT); Simon is (was?) listed as an Uploader, not the maintainer. I don't think it's accurate to list the package as orphaned. Cheers, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#905342: apache fpm not working anymore
Package: apparmor Version: 2.13-6 I've a lxc guest running apache php fpm for horde. lxc guest and host both were running apparmor. Host was updated from 2.12-5 to 2.13-6. Guest was updated from 2.13-4 to 2.13-6. Package upgraded included: apparmor apparmor-easyprof apparmor-notify apparmor-profiles apparmor-utils libapparmor1 python3-apparmor python3-libapparmor After upgrading apparmor horde stopped working. I downgraded apparmor on the host and still horde on the guest was not working. After downgrading apparmor on the guest horde started to work again. Problems seems related to apparmor recipes rather than in binaries since by mistake I forgot to downgrade the apparmor package in the guest and things were working. related log entries may be Aug 1 19:46:50 caronte kernel: [265475.231940] audit: type=1400 audit(1533145610.777:245): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="klogd" pid=19732 comm="apparmor_parser" -- Ivan Sergio Borgonovo https://www.webthatworks.it https://www.borgonovo.net
Bug#904877: ITP: trololio -- Trollius and asyncio compatibility library
Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior * Package name: trololio Version : 1.0 Upstream Author : ThinkChaos * URL : https://github.com/ThinkChaos/Trololio * License : Expat Programming Lang: Python Description : trololio -- Trollius and asyncio compatibility library Trololio provides a compatibility layer for Trollius and asyncio (aka Tulip). It addresses the differences listed in Trollius and Tulip: . * Allows the use of Trollius' syntax with asyncio. * Provides missing objects and aliases for the others. * Synchronizes debug environnement variables. I will maintain this package with the DPMT. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#904846: libjs-jstimezonedetect.js doesn't provide a *.min.js
Package: libjs-jstimezonedetect Version: 1.0.6-1 A project I'm packaging depends on libjs-jstimezonedetect, and makes use of the jstz.min.js file. However, I can't find this file on the package: $ apt-file list node-jstimezonedetect node-jstimezonedetect: /usr/lib/nodejs/jstimezonedetect/jstz.js node-jstimezonedetect: /usr/share/doc/node-jstimezonedetect/changelog.Debian.gz node-jstimezonedetect: /usr/share/doc/node-jstimezonedetect/copyright It would be great if you could ship it. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#898863: debian/watch doesn't work properly
On Friday, July 27 2018, Joel Cross wrote: > Hi Sergio, > > I have fixed this by switching the watch file to use the GitHub URL instead. > Would you mind reviewing the latest package and uploading? Hi Joel, I remember we had a problem with using github vs. pypi on some other package, so maybe switching from one to the other can cause problems? I'm not sure. Either way, there's actually a simple fix for the original watch file: you just have to use a capital C when naming the project (i.e., Cerberus instead of cerberus). Another useful tip is to go to the pypi.debian.net web page: https://pypi.debian.net/cerberus and look at the "watch" link: https://pypi.debian.net/Cerberus/watch it will show you a suggested version of the watch file to be used. The version is outdate (3 instead of 4), but it's useful anyway. While at it, since we're going to upload this package, it's a nice idea to (a) bump Standards-Version (latest is 4.1.5), and (b) mark the python-cerberus-doc package as "Multi-Arch: foreign", as suggested by the Multiarch hinter. After you've done that, I'll gladly upload it. BTW, before I forget: I fixed the git tag "debian/1.2-1" on the repository. It was pointing to the wrong commit. I had to delete the tag and recreate it on salsa, just FYI. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
Control: tags -1 + fixed-upstream - moreinfo On Friday, July 27 2018, I wrote: > I'll send the upstream patch to clarify the manpage (and Cc you); I > hope this is enough to address the issue. The patch has been submitted to the mailing list: https://sourceware.org/ml/gdb-patches/2018-07/msg00729.html And pushed: commit 129eb0f1f16dc7a49799a024a7bcb109d954a1e7 (HEAD -> master, origin/master, origin/HEAD) Author: Sergio Durigan Junior Date: Fri Jul 27 00:52:23 2018 -0400 Improve gcore manpage and clarify "-o" option Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
On Thursday, July 26 2018, GSR wrote:
> sergi...@debian.org (2018-07-26 at 0008.50 -0400):
>> Sorry, I'm not sure I understand the problem. The '-o' option works as
>> expected here:
>>
>> $ bash /usr/bin/gcore 21153
>> 0x7f11fc3d0404 in __GI___nanosleep (requested_time=0x7ffc3cb70240,
>> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
>> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
>> Saved corefile core.21153
>>
>> $ bash /usr/bin/gcore -o blabla 21258
>> 0x7f3531233404 in __GI___nanosleep (requested_time=0x7fff80925a40,
>> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
>> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
>> Saved corefile blabla.21258
>>
>> $ bash /usr/bin/gcore -o blabla 21549 21550
>> 0x7fc267908404 in __GI___nanosleep (requested_time=0x7ffc76bc1c80,
>> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
>> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
>> Saved corefile blabla.21549
>> 0x7fab24ce5404 in __GI___nanosleep (requested_time=0x7ffc2d80a380,
>> remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
>> 28 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
>> Saved corefile blabla.21550
>
> The man page says you can ask for filename blabla, then uses
> blabla.21258. That is the problem, it's not a filename, more like a
> template, and between getting blabla.21258 or core.21258, no big win,
> IMO. If it needs extra handling to end in the file you really wanted,
> probably you can rename any of them, or wrap with pushd/popd to change
> directory.
>
> Compare also to many other programs, when they talk about a file or
> filename, they normally use what is provided, unchanged. wget -i -o -a
> and -O, sed -f, etc. wget doesn't force url files to end in .url, or
> logging ones in .log, or ... You want to use .txt or no extension? All
> work. You can even feed device names or connect to processes if the
> shell supports "making files". They are flexible.
>
> Thing talks about filename, I expect filename result, not that it
> magically means template. Just as mayority of programs do.
Ah, OK, now I understand. Indeed, I think the manpage could be extended
to explain that "filename" is actually a prefix.
>> > Suggestions:
>> >
>> > - change man page and -h output to say "pid[s]".
>>
>> This change would be welcome, IMO.
>
> See patches... manpage one is probably moot, if generated from other
> source, but could be used as reference.
I have a patch here to clarify the manpage. I think it's the best
approach.
> Other option is simplifying the script, and users do multiple calls,
> one per PID. Which I guess it was how it worked before as that is the
> man page "tone" (process, not processes, pid, not pids, etc).
Doing a bit of archaeology, it's possible to verify that the script was
introduced by:
commit 627bf7c1c73e713199b020c66973629ddcb8cc59
Author: Elena Zannoni
Date: Thu Apr 17 20:33:09 2003 +
and it's also possible to confirm that the loop was always present.
Ever since I started working on GDB I noticed that the gcore script is a
bit "forgotten".
>> > - support single PID with exact filename (no .pid extension). If you
>> > can get a list of PIDs, you can also probably do the loop, so the
>> > feature isn't so helpful but more importantly it disallows things
>> > like '-o >( gzip - > "path/${PID}.gz" )' (on the fly compression) or
>> > '-o "$T"' (a safe T created by tempfile(1)).
>> >
>> > - fix man page for -o "write core file to filename if one PID, or
>> > filename.pid if multiple PIDs, instead of default core.pid".
>>
>> I don't really understand the two proposals above.
>
> IOW: If you ask for a file to be used, it should be that one when
> possible (single PID case), not something else. "Do what I say,
> cooperate". And document that.
Honestly, I don't think this bug is important enough to justify
complicating the script. I'll send the upstream patch to clarify the
manpage (and Cc you); I hope this is enough to address the issue.
Thanks,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
signature.asc
Description: PGP signature
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
On Thursday, July 26 2018, GSR wrote: > Patch for possible update of man page. The patch is reversed. > And a note: the suggested compression trick doesn't work (seek > errors). Maybe there is other way, maybe not possible. The other > example, about using securely created destination, works. I personally would like to see the gdb.texinfo file updated using the upstream version. No need to carry an extra patch for this scenario. > --- gcore.1 2018-07-26 04:50:01.066541238 +0200 > +++ gcore.1-old 2018-07-11 17:49:59.0 +0200 > @@ -1,26 +1,20 @@ > -.TH gcore "1" "Jul 2018" "gdb 8.1" "GNU Tools" > +.TH gcore "1" "May 2007" "gdb 6.8" "GNU Tools" > .SH NAME > -gcore \- Generate core files for running processes > +gcore \- Generate a core file for a running process > .SH SYNOPSIS > .B gcore > -[-a] [-o \fIfilename\fR] \fIpid[s]\fR > +[-o \fIfilename\fR] \fIpid\fR > .SH DESCRIPTION > .\" Add any additional description here > .PP > -gcore generates a core file for the process(es) specified by process IDs, > -\fIpid[s]\fR. By default, each core file is written to core.\fIpid\fR, in the > +gcore generates a core file for the process specified by its process ID, > +\fIpid\fR. By default, the core file is written to core.\fIpid\fR, in the > current directory. > .TP > -\fB\-a\fR > -(Linux only) ignore /proc/PID/coredump_filter and also dump memory mappings > -marked with the 'VM_DONTDUMP' flag. See info node Core File Generation for > -longer explanation. > -.TP > \fB\-o\fR \fIfilename\fR > -write core file to \fIfilename\fR if one PID, or \fIfilename.pid\fR if > -multiple PIDs, instead of default core.\fIpid\fR > +write core file to \fIfilename\fR instead of core.\fIpid\fR > .SH COPYING > -Copyright \(co 2003, 2005, 2007, 2008, 2018 Free Software Foundation, Inc. > +Copyright \(co 2003, 2005, 2007, 2008 Free Software Foundation, Inc. > .PP > Permission is granted to make and distribute verbatim copies of this manual > provided the copyright notice and this permission notice are preserved on > -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#903996: network-manager-config-connectivity-debian fills up logs
O Mar, 24-07-2018 ás 18:41 +0200, Michael Biebl escribiu: > On Tue, 17 Jul 2018 23:32:56 +0100 Mark van Rossum > wrote: > > > Since the update to network-manager-config-connectivity- > > debian:amd64 > > 1.12.0-4, and when I am connected via Wifi > > Networkmanager is rapidly filling syslog and user.log with error > > messages of the following structure: > > > > > NetworkManager[1126]: [1531337424.2758] connectivity: > > > > connectivity check failed: 4 > > I've talked to upstream about this, and they provided a patch which > fix > the busy loop. > As I can't reproduce the problem myself, it would be great if you > could > do the testing for me. > I've provided packages with the patch applied at: > https://people.debian.org/~biebl/network-manager/ > > Please install those packages, re-enable connectivity checking and > report back with your results. I've been trying the new packages and I haven't had any problem in a day and a half. I guess it's fixed now as in the past, as I mentioned, I ended up with an unusable system in less than 5 minutes. BR
Bug#904628: gdb: gcore -o uses .pid extension anyway, man page outdated
Control: tags -1 + moreinfo
On Wednesday, July 25 2018, GSR wrote:
> Hello:
>
> Current man page says "write core file to filename instead of
> core.pid" but the real outcome is that dump is written to
> filename.pid. Probably because it's not just a single PID, but a list
> of PIDs, which neither man page nor -h talk about.
Sorry, I'm not sure I understand the problem. The '-o' option works as
expected here:
$ bash /usr/bin/gcore 21153
0x7f11fc3d0404 in __GI___nanosleep (requested_time=0x7ffc3cb70240,
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
Saved corefile core.21153
$ bash /usr/bin/gcore -o blabla 21258
0x7f3531233404 in __GI___nanosleep (requested_time=0x7fff80925a40,
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
Saved corefile blabla.21258
$ bash /usr/bin/gcore -o blabla 21549 21550
0x7fc267908404 in __GI___nanosleep (requested_time=0x7ffc76bc1c80,
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
Saved corefile blabla.21549
0x7fab24ce5404 in __GI___nanosleep (requested_time=0x7ffc2d80a380,
remaining=0x0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
Saved corefile blabla.21550
> While checking what was going on, I found -a is not documented in man
> page, and script has not comment at all about what it really does
> (options are found in 10.19 of info docs, it toggles two defaults,
> Linux only).
For some reason (probably because of the non-free aspect of it), the
version of gdb.texinfo present in the salsa GDB repo is not the one
shipped on upstream GDB 8.1. The gcore manpage is generated from this
file, so this is why you're seeing an old version of it.
The -a option was introduced last year in order to replicate the
coredump-filter feature implemented a while ago on GDB. However, it's
not true that the script doesn't contain a comment explaining it. This
is what I see here:
# When the -a option is present, this may hold additional commands
# to ensure gdb dumps all mappings (OS dependent).
When the manpage is updated, you'll also be able to see the description
there.
> Suggestions:
>
> - change man page and -h output to say "pid[s]".
This change would be welcome, IMO.
> - support single PID with exact filename (no .pid extension). If you
> can get a list of PIDs, you can also probably do the loop, so the
> feature isn't so helpful but more importantly it disallows things
> like '-o >( gzip - > "path/${PID}.gz" )' (on the fly compression) or
> '-o "$T"' (a safe T created by tempfile(1)).
>
> - fix man page for -o "write core file to filename if one PID, or
> filename.pid if multiple PIDs, instead of default core.pid".
I don't really understand the two proposals above.
> - fix man page for -a (point to info? small text explaining?).
This is not necessary, as I explained above.
Cheers,
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
signature.asc
Description: PGP signature
Bug#904160: gdb: bashism(s) in gcore (or wrong shebang)
On Friday, July 20 2018, GSR wrote:
> Hello:
>
> The shebang line of gcore script points to sh (dash here), and when
> trying to use it stops immediately with:
>
> ---8<---
> /usr/bin/gcore: 28: /usr/bin/gcore: Syntax error: "(" unexpected
> --->8---
>
> Changing sh to bash in the first line of the script makes it work
> again. That or fix line 28 (and any other) to be compatible with basic
> sh syntax.
FWIW, this has been fixed upstream by:
commit e1e6f073a9f5d7c3183cb8096fb24a42c28ba36b
Author: Georg Sauthoff
Date: Thu Mar 1 17:23:31 2018 -0500
Improve gcore shell quoting and portability
--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
signature.asc
Description: PGP signature
Bug#903996: network-manager-config-connectivity-debian fills up logs
I'd raise the severity of this issue. In my particular case I got an unusable system from fresh start after 5 minutes. I checked the syslog and this is what I get $ sudo grep "connectivity check failed" /var/log/syslog | grep "Jul 19" | wc -l 10522249 10M records in just 5 minutes looks clearly wrong. We are not talking about "just" 8k per minute, but 2M in my case. BR
Bug#903996: network-manager-config-connectivity-debian fills up logs
I'd raise the severity of this issue. In my particular case I got an unusable system from fresh start after 5 minutes. I checked the syslog and this is what I get $ sudo grep "connectivity check failed" /var/log/syslog | grep "Jul 19" | wc -l 10522249 10M records in just 5 minutes looks clearly wrong. We are not talking about "just" 8k per minute, but 2M in my case. BR
Bug#904066: ITP: python-openidc-client -- A Python OpenID Connect client with token caching and management
Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior * Package name: python-openidc-client Version : 0.6.0 Upstream Author : Patrick Uiterwijk * URL : https://github.com/puiterwijk/python-openidc-client * License : Expat Programming Lang: Python Description : A Python OpenID Connect client with token caching and management This package is a simple Python OpenID Connect client library with token caching and management. I will maintain this package with the DPMT. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#904054: ITP: cccolutils -- Python Kerberos Credential Cache Collection Utilities
Package: wnpp Severity: wishlist Owner: Sergio Durigan Junior * Package name: cccolutils Version : 1.4 Upstream Author : https://pagure.io/cccolutils * URL : Patrick Uiterwijk * License : GPL-2+ Programming Lang: Python Description : Python Kerberos Credential Cache Collection Utilities This module provides Kerberos 5 credential cache collection utilities for Python 2.6+ and 3. . When a user authenticates to a Kerberos realm (eg. with kinit), the user has a short-lived credential in a cache (view it with klist). . You can use this cccolutils module to easily determine if the user has any valid Kerberos credentials, or what the username is for a particular Kerberos realm. I will maintain this package with the DPMT. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#881205: NMU for backintime 1.1.24
On Monday, July 16 2018, I wrote: > On Sunday, July 01 2018, Fabian Wolff wrote: > >> Hi Jonathan, >> >> On Fri, 29 Jun 2018 22:21:54 +0100, Jonathan Wiltshire wrote: >>> Would you like to co-maintain? If so, please add yourself to uploaders and >>> prepare a maintainer upload (rather than NMU). I added you to the >>> repository members in anticipation. >> >> Thanks. In principle, I'd be interested in co-maintaining the package, >> but unfortunately, I don't think that I have the time for it right >> now. I might reconsider co-maintaining this package in the future, >> though. >> >> For the time being, I'd like to leave it at a NMU. Can I proceed with >> the NMU? If so, would you like to sponsor it, or should I look for a >> sponsor elsewhere? > > Hello Jonathan, > > FYI, Fabian contacted me and I accepted to sponsor his NMU. I have been > working with him for some time and his uploads are always very good; > I've also reviewed the modifications he made and they are sensible. > I'll be uploading the package to the DELAYED queue as a courtesy. Uploaded to the 5-day DELAYED queue. Cheers, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#881205: NMU for backintime 1.1.24
On Sunday, July 01 2018, Fabian Wolff wrote: > Hi Jonathan, > > On Fri, 29 Jun 2018 22:21:54 +0100, Jonathan Wiltshire wrote: >> Would you like to co-maintain? If so, please add yourself to uploaders and >> prepare a maintainer upload (rather than NMU). I added you to the >> repository members in anticipation. > > Thanks. In principle, I'd be interested in co-maintaining the package, > but unfortunately, I don't think that I have the time for it right > now. I might reconsider co-maintaining this package in the future, > though. > > For the time being, I'd like to leave it at a NMU. Can I proceed with > the NMU? If so, would you like to sponsor it, or should I look for a > sponsor elsewhere? Hello Jonathan, FYI, Fabian contacted me and I accepted to sponsor his NMU. I have been working with him for some time and his uploads are always very good; I've also reviewed the modifications he made and they are sensible. I'll be uploading the package to the DELAYED queue as a courtesy. As a side note, he forked your repository on salsa and did his work on his repo: https://salsa.debian.org/wolff-guest/pkg-backintime I think it makes sense to set up a new "debian/backintime" repository and use his repo as the starting point; I can do that if you want. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#903880: RFS: pw/1.2-1 [ITP] -- simple command-line password manager
On Monday, July 16 2018, Dashamir Hoxha wrote: > On Mon, Jul 16, 2018 at 6:53 AM Sergio Durigan Junior > wrote: > >> Hello, >> >> Thank you for your interest in Debian. >> >> From the website (which unfortunately uses github): >> >> pw was written by Dashamir Hoxha (dashoho...@gmail.com). The code is >> on GitHub at https://github.com/dashohoxha/pw. pw started as a fork of >> pass (http://www.passwordstore.org/), written by Jason A. Donenfeld >> (ja...@zx2c4.com). >> >> pass is already packaged, works perfectly (I use it myself), has an >> active upstream, and doesn't use github (which IMO is a feature >> nowadays). What is the advantage of having "pw" in the archive? > > > A couple of years ago I made some suggestions for improvement to 'pass'. > I proposed to use an encrypted archive for the whole directory of passwords, > instead of encrypting only the passwords, because this way the structure of > the passwords is hidden and protected as well, besides the passwords > themselves. > > This looks like a reasonable thing, however it conflicts with some other > feature of 'pass', namely the ability to share different branches of > passwords > with different people. Since 'pass' is widely used, there is no way to > remove > an existing feature from it, since some of the users may already depend on > it. Why would you need to remove a feature from it? Why not add a new "mode" or option? > So, my proposal could not be technically accepted and the only way was > to start a fork, which I did. Later I continued to add more features which > make it different from 'pass'. For example having a GPG key is a must > for using 'pass', however in 'pw' it is only an option, one can also use > a simple password for encrypting the archive. In my opinion this makes > 'pw' easier to get started, compared to 'pass', since we all know that > managing GPG keys is not an easy task, especially for beginners. I'm not a security expert, but using a "simple password" for encrypting the archive instead of a 4096 RSA key seems like a bad thing to do, even if done in the name of "ease of use". But as I said, I'm not an expert in this area (and I confess I haven't spent too much time thinking about the implications). > Another difference is that in 'pass' you can share your passwords with > other people only through a central git repository. In 'pw' you need to > synchronize the encrypted archives with other people, and this can be > done with 'scp' or 'rsync' or any other means. First of all, git is not centralized; it's companies like github that made it seem like a centralized thing. If you can use scp, then you can also clone a git repository via SSH. And as for rsync, one can easily mirror the local repository by rsync'ing the ~/.password-store/ directory. > So, the main target users of 'pass' are big enterprises, or organizations, > or corporations. On the other hand 'pw' is more suitable for individuals > or small groups. What?! I completely disagree with this statement. I don't know how you reached the conclusion that 'pass' has "big enterprises, or organizations, or corporations". I use pass myself as an individual, and I know several other *individuals* who also use it. The fact that it requires GPG is *not* an anti-feature for individuals, as you seem to imply. > I do not claim that 'pw' is better than 'pass', but at least they are > different, > because they have different features. So, it makes sense to have both > of them in the repository, and let the users decide which one is more > suitable > for their needs. They're indeed different, but I feel reticent in accepting 'pw' because IMO it promotes less security, not more. > References: > - https://lists.zx2c4.com/pipermail/password-store/2016-January/001887.html > - https://lists.zx2c4.com/pipermail/password-store/2016-January/001902.html > - https://lists.zx2c4.com/pipermail/password-store/2016-January/001928.html > > I don't think that the place of hosting adds or removes anything to the > merits > of an application. However 'pw' is a free software and it is hosted on a > site > that so far has offered great service, and is friendly and not hostile to > free software > (at least not yet). Anybody who cares about it is free to make a mirror to > their > preferred or trusted hosting service. I do this often for the programs or > tools > that I need to use on my applications, just in case that they suddenly > disappear > from the face of the Earth. If I had hosted 'pw' on my own personal server, > this would not make it more safe, or secure, or reliable. My point is that > the > place of hosting does not matter. Oh, but it does. Maybe n
Bug#903880: RFS: pw/1.2-1 [ITP] -- simple command-line password manager
Control: tags -1 + moreinfo On Sunday, July 15 2018, Dashamir Hoxha wrote: > Dear mentors, > > I am looking for a sponsor for my package "pw" > > * Package name: pw >Version : 1.2-1 >Upstream Author : Dashamir Hoxha > * URL : https://github.com/dashohoxha/pw > * License : GPL-2+ >Section : misc > > It builds those binary packages: > > pw- Simple command-line password manager. > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/pw > > > Alternatively, one can download the package with dget using this command: > > dget -x https://mentors.debian.net/debian/pool/main/p/pw/pw_1.2-1.dsc > > More information about "pw" can be obtained from the man page: > > http://dashohoxha.github.io/pw/man/ Hello, Thank you for your interest in Debian. From the website (which unfortunately uses github): pw was written by Dashamir Hoxha (dashoho...@gmail.com). The code is on GitHub at https://github.com/dashohoxha/pw. pw started as a fork of pass (http://www.passwordstore.org/), written by Jason A. Donenfeld (ja...@zx2c4.com). pass is already packaged, works perfectly (I use it myself), has an active upstream, and doesn't use github (which IMO is a feature nowadays). What is the advantage of having "pw" in the archive? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#903668: RFS: enchive/3.4-3 [ITP]
Control: owner -1 ! Control: tags -1 + moreinfo On Thursday, July 12 2018, Zebulon McCorkle wrote: > Dear mentors, Hello Zebulon, > I am looking for a sponsor for my package "enchive" > > * Package name: enchive >Version : 3.4-3 >Upstream Author : Christopher Wellons > * URL : https://github.com/skeeto/enchive > * License : Unlicense >Section : utils > > It builds those binary packages: > > enchive- long-term archive encryption tool > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/enchive > > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/e/enchive/enchive_3.4-3.dsc > > Or from Salsa using this command: > > gbp clone https://salsa.debian.org/zebmccorkle-guest/enchive.git > > More information about hello can be obtained from > https://github.com/skeeto/enchive > and https://nullprogram.com/blog/2017/03/12/. Thanks for the package. There are some issues with it that you need to address before we move forward. I'll enumerate them. 1) Under the debian/ directory, you're distributing 3 files that are not needed: debhelper-build-stamp enchive.debhelper.log enchive.substvars If you run dh_clean on your package, you'll see that it removes these files. So please remove them. 2) You're bumping the package version (on d/changelog) every time you make a modification, however, the package hasn't been released yet. Your initial version should always be "3.4-1", even if you have to make modifications. Then, when it's released, you should start bumping the version. 3) I like git-buildpackage and appreciate that you're using a repository to package the software: https://salsa.debian.org/zebmccorkle-guest/enchive However, I noticed that you haven't pushed the "upstream" branch, and therefore it's not possible to use "gbp buildpackage" directly because it can't reconstruct the upstream tarball. Please push this branch. 4) On d/control, Standards-Version should be 4.1.5. 5) Instead of overriding dh_installchangelogs (on d/rules), you can instead create a "debian/docs" file and list whatever files you would like to install. For example, I think it's a good idea to install README.md as well. 6) You need to provide a watch file for the package. 7) On d/copyright, the "Format:" field should use https. 8) On d/copyright, instead of listing all files of the project in the first license specification, you can just use "*" instead. The other license specifications below it will take care of specific cases. 9) While I commend you for choosing to license your work under the debian/ directory with GPLv3+, in this specific case I suggest you relicense it using the project's license (or using a license that is compatible with it). This is useful because sometimes you might want to submit Debian-specific patches to upstream, and if the licenses don't match you'll find yourself in a difficult situation. In your case, either the "Unlicense" public domain license, or the BSD-3-clause license should be fine (but IANAL). 10) Still on d/copyright, the license of the first set of files should be "public-domain", and not "UNLICENSE". The license for src/sha256.h is the same as the one for the .c file, and there's no need to put the "Copyright: Public Domain" text in the "License:" field, so you can have something like: Files: src/sha256.* Copyright: Brad Conte (brad AT bradconte.com) License: public-domain This code is presented "as is" without any guarantees. 11) Please remove the "Disclaimer:" field on d/copyright. 12) The program offers an Emacs mode, and therefore it should be installed. Take a look at how/where to install .el files. Hm, I'll stop here. There are more things I noticed, but let's start with this list first. Let me know if you have any questions. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#903670: RFS: pius/2.2.6-1 -- Tools to help before and after key-signing parties
Control: owner -1 ! On Thursday, July 12 2018, Felix Lechner wrote: > Dear mentors, > > I am looking for a sponsor for my package "pius" > >Package name: pius >Version : 2.2.6-1 >Upstream Author : Phil Dibowitz >URL : http://www.phildev.net/pius/ >License : GPL-2 >Section : utils > > It builds those binary packages: > > pius - Tools to help before and after key-signing parties > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/pius > > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/p/pius/pius_2.2.6-1.dsc > > Changes since the last upload: > > * New upstream release (Closes: #873741) > * Set Build-Depends: and Depends: to python3 and friends (Closes: #902328) > * Removed X-Python-Version: > * Set Depends: gnupg (>= 2) (Closes: #864431) > * Switched to upstream manpages (submitted from Debian) > * Set Vcs-Browser: https://salsa.debian.org/lechner-guest/pius > * Set Vcs-Git: https://salsa.debian.org/lechner-guest/pius.git > * Switched to secure URI in copyright > * Set Priority: optional (from extra) > * Set Build-Depends: debhelper (>= 11) > * Set compat to 11 > * Set Standards-Version: 4.1.5 I'm taking a look at this package. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
