Bug#1027130: Bug may still be open
Dear Maintainer; This "grave" bug has been marked as closed in 1.0.0-dfsg-1 however it is still open in 0.103.7-dfsg-0+deb11u1 and there is no indication that it has been resolved in 0.103.8+dfsg-0+deb11u1 which is promulgated to solve the "serious" CVEs handled in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031509 for "Buster". As such trying to upgrade my system is warning me that this grave bug is present. It is not clear whether this is indeed the case or not. I must note that I am running Devuan Stable "Chimaera" but it seems that this issue will also arise for Debian Stable "Bulleye". Regards Stephen Lyons
Bug#982743: Hurd: grub-probe returning invalid HDD numbers for several --target options
Package: grub-common
Version: 2.02-2
Severity: important
Dear Maintainer,
I have a Debian/Hurd installation on an (oversized, it is 160GB but only
138GB can, I understand, be accessed) PATA HDD - i.e. on real hardware.
It is an old Dell Dimension 5150 which is a Pentium D unit so it is a
64-Bit Dual core machine with 1GB of memory - though none of that is
really important I think.
The installation was done on another machine where - due to the vagaries
of the multiple HDD interfaces it was presenting as - as far as the
Debian Hurd Installer (the 2020/07/31 Full DVD version) was concerned
meant it was "/dev/hd2" - though it was the sole hard-drive in the
system. However - and since it was a few days ago and I have been trying
things I cannot be certain so this next bit, between lines of "+"s may
NOT be the case:
+
When the installation was booted I *think* it started Grub and got to
the normal mode menu, but it wouldn't boot. I reviewed the commands that
Grub intended to perform and I spotted that instead of "hd2s1" being
used for the root device it was using "hd-47s1"! However I was able to
get it to boot by changing all those entries back to "hd2s1".
+
Note that due to a second bug which I haven't yet reported, there is a
duplicate call to:
prepare_grub_to_access_device "${GRUB_DEVICE}" | grub_add_tab| sed
"s/^/$submenu_indentation/"
at around line 127 of /etc/grub.d/10_hurd which means there is a batch
of extra, duplicated, commands in the Grub menu item that - fortunately
- would seem to be idempotent but also had to be edited to correct the
bogus "hd-47s1" entries.
Moving on, I transferred the HHD to the system I am SSHing into ("hunt")
to write this and expected to need to edit the same entries to be
"hd0s1" as the drive is now the only drive and the BIOS is happy for it
to be the first drive. Once booted I was able to run grub-update and
expected that to make things work upon the next boot. However on
inspecting the Grub menu item in the new system I have found that the
"/dev/hd0" drive is being misnumbered as "hd-49". Note that the bogus
designation has changed by the same amount as the correct one:
"2" -> "-47"
"0" -> "-49"
to my mind that suggests something is doing some maths or C code to
convert between a C char type to a C int type when it shouldn't or
vise-versa. This is confirmed by the following command and its output:
> root@hunt:~# /usr/sbin/grub-probe -v -d /dev/hd0s1 -t bios_hints
> /usr/sbin/grub-probe: info: cannot open `/boot/grub/device.map': No
such file or directory.
> /usr/sbin/grub-probe: info: /dev/hd0s1 is not present.
> /usr/sbin/grub-probe: info: Looking for /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0 is a parent of /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0s1 is present.
> /usr/sbin/grub-probe: info: Looking for /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0 is a parent of /dev/hd0s1.
> /usr/sbin/grub-probe: info: /dev/hd0s1 is present.
> /usr/sbin/grub-probe: info: /dev/hd0 is a parent of /dev/hd0s1.
> /usr/sbin/grub-probe: info: opening hostdisk//dev/hd0,1.
> /usr/sbin/grub-probe: info: drive = 0.
> /usr/sbin/grub-probe: the size of hostdisk//dev/hd0 is 268435455.
> hd-49,msdos1
> root@hunt:~#
Running the same commands for the other relevant -t targets shows the
same defect.
Obviously I would have expected the outcome for this command to have
been that the output was "hd0,msdos1" rather than "hd-49.msdos1".
It seems fair to assume that this is specifically a Hurd issue and
only affecting "real" hardware...
Stephen Lyons
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0
/dev/hd0s7 /tmp /hurd/ext2fs writable,no-inherit-dir-group 0 0
/dev/hd0s5 /var /hurd/ext2fs writable,no-inherit-dir-group 0 0
/dev/hd0s8 /home /hurd/ext2fs writable,no-inherit-dir-group 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too
If I refer you back to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959221#15 it was the Debian Sid DVD image: https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/current/debian-sid-hurd-i386-DVD-1.iso which report that it is: "DVD Binary-1 20200731-17:45". signature.asc Description: OpenPGP digital signature
Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too
I guess that was the case - I resorted to jurying rigging the disk and DVD-ROM in my main system which had all the other drives disconnected and that one worked fine - though it did have a PS/2 keyboard. After returning them to the original system; booting from a Knoppix thumb-drive to correct the numbering in `/etc/fstab` and temporarily editing the GRUB entry to also compensate for the drive being differently numbered compared to when it was on the installation system I now have a bootable system - hooray! So I have worked around the problem - which seems to be confined to the installer and is a nuisance - but in the scheme of things I guess this issue for me can be relegated to a low priority. For the record the system concerned was a Dell Dimension 5150 with a BIOS version A05. Having read: https://en.wikipedia.org/wiki/USB_human_interface_device_class#Keyboards I think I start to understand why things might go wrong. signature.asc Description: OpenPGP digital signature
Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too
list of options it became difficult/impossible to navigate - and that was at the point where I was trying to select the PATA HDD I was using to install to instead of the DVD-RW (a 1.7GB partition & a 3.0 GB spare on) that the installer works from but thinks it can use! Right now it is installing the base system - I'll see how much further it gets but I will likely repeat the process after removing the remnant (a 32GB FAT partition) of a previous use of the drive. It would be useful if someone who knows the guts could review the low-level keyboard handling in the installer to see what bugs might be there. It would be useful if there is a way that the number of keystrokes "pending" in the keyboard queue could be displayed temporarily in the installer (ideally with what they are) and/or if there was a way that it could be forcibly cleared - perhaps an unused key could be reserved so that so when it is seen, instead of queueing it up, it immediately flushes itself and all others from the queue. The most obvious one would be the "Windows" or equivalent key if that can be handled. Sorry that I can not be more specific about the details about what is going on - however I am not giving up just yet! 8-P Regards Stephen On 2021-02-06 09:38, Samuel Thibault wrote: > Hello, > > Stephen Lyons, le sam. 06 févr. 2021 02:30:43 +, a ecrit: >> However, now I have found #959221 > > I have to admit I had never noticed that bug report, I don't know why. > >> I have to say that trying to install >> onto a real machine with this later and different image does not seem >> any better. Some parts of the UI work acceptably fast but others, like >> around disk partitioning are dangerously unresponsive, > > That's odd, I had never seen such behavior, be it in virtual environment > or bare metal. Since you mention disk partitioning, I would guess a bad > interaction between the ahci disk driver and the disk device. Nothing I > can work on personally since on my systems I don't have the issue. Are > there timeout logs being printed? > > If you got to the second console with ctrl-alt-f2, and run there > > ps | grep R > > which processus show up? > > Samuel > -- To mitigate against EFAIL attacks email messages will be handled only as plain text, please do not send emails in an HTML form to this recipient! signature.asc Description: OpenPGP digital signature
Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too
Package: hurd Version: DVD Binary-1 20200731-17:45 --- Please enter the report below this line. --- Having been aware of the GNU/HURD for some years and seeing that Debian offered it (and being subject to the general slow down in life in the era of COVID-19) I though it was worth having a go and trying to install it on a spare system. However, now I have found #959221 I have to say that trying to install onto a real machine with this later and different image does not seem any better. Some parts of the UI work acceptably fast but others, like around disk partitioning are dangerously unresponsive, fortunately I was working on a spare machine with only a single, empty SATA hard-drive otherwise it would have been easy for unhandled but stacked up key presses to damage existing OSes installed elsewhere in the system. In effect you press a key, and... ... nothing happens, so you think "oh that wasn't valid there" and press another key, and again... ... nothing happens ... after a while ... nothing happens ... then suddenly! Nothing continues to happen ... finally, the first key that you pressed takes effect, then the next, then the next - but by then the "cursor" is in the wrong place and the wrong thing happens! Now I am aware of this Bug I will try again when I can get to the machine (it is elsewhere) and this time be very sure and deliberate about which keys I press and where - and try and note down which bits are okay and which are like wading through concrete. Stephen --- System information. --- Auto-generated details suppressed because this is not from the system concerned and I did not get far enough in to get much to report back. "Dell" something or other Desktop PC with 2.8GHz Pentium D 1GB Memory 2x SATA: 500GB HDD 2x PATA: DVD-ROM drive connected --- Package information. - Not applicable. signature.asc Description: OpenPGP digital signature
Bug#960026: [release-notes] KDE is no longer supported as a Desktop Environment without systemd as init-system (PID 1)
Package: release-notes
Version: Buster
Severity: important
--- Please enter the report below this line. ---
As I tried to report in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935304#10 - but it
seems to have been overlooked in the wilder scheme of things. If one is
using something other than systemd as the init system under "Stretch"
and use KDE Plasma as your Desktop Environment then you will find the
latter gets removed during the upgrade as there is a dependency chain
that DEMANDS systemd-sysv which is, of course, not satisfiable without
systemd as PID 1.
This is because libpam-systemd has been revised in "Buster" to "require"
not only systemd but also systemd-sysv . I did experiment with building
a systemd set of packages where the "require" from `libpam-systemd` for
'systemd-sysv' was reduced to a "suggest" specifically BECAUSE I WAS NOT
INTENDING TO USE SYSTEMD AS MY INIT SYSTEM which was sufficient to get
most of the KDE Plasma Desktop working - although with the breakage in
the login system it wasn't possible to sleep/hibernate/shutdown from the
DE. However a either a recent change - or a failed attempt to switch to
elogind just as systemctl was updated {possibly
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959920 applies} has
broken my system and I cannot get several DEs to properly start up any more.
I am aware that Devuan has a replacement elogind / libpam-elongind which
does work to enable KDE to operate without libpam-systemd but this seems
to have been rejected for Debian.
As a consequence it looks like I will have to switch my main PC to
Devuan "Beowulf" if I want to keep using KDE.
Stephen Lyons
--- System information. ---
Architecture:
Kernel: Linux 4.19.0-8-amd64
Debian Release: 10.3
500 stable security.debian.org
500 stable ftp.uk.debian.org
500 stable apt.spideroak.com
--- Package information. ---
Package's Depends field is empty.
Package's Recommends field is empty.
Package's Suggests field is empty.
--
To mitigate against EFAIL attacks email messages will be handled only as
plain text, please do not send emails in an HTML form to this recipient!
signature.asc
Description: OpenPGP digital signature
Bug#944382: [xscreensaver-data-extra] /usr/share/application/screensavers/glitchpeg.desktop file error
Package: xscreensaver-data-extra Version: 5.42+dfsg1-1 --- Please enter the report below this line. --- The problem seems to be a spurious line-feed part way through the "Comment" entry for that file which then appears to break something when it tries to parse that glitchpeg.desktop file. It is not immediately clear to me from reading https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html whether that filed may contain Line-Feeds within its contents, but given the behaviour in this case I suspect not! HTH Stephen --- System information. --- Architecture: Kernel: Linux 4.19.0-8-amd64 Debian Release: 10.3 500 stable security.debian.org 500 stable ftp.uk.debian.org 500 stable apt.spideroak.com --- Package information. --- Depends(Version) | Installed -+-= dictionaries-common | 1.28.1 libjpeg-turbo-progs | 1:1.5.2-2+b1 netpbm | 2:10.0-15.3+b2 xscreensaver-data| 5.42+dfsg1-1 libc6 (>= 2.27) | 2.28-10 libgdk-pixbuf2.0-0 (>= 2.22.0) | 2.38.1+dfsg-1 libglib2.0-0 (>= 2.16.0) | 2.58.3-2+deb10u2 libice6 (>= 1:1.0.0) | 2:1.0.9-2 libsm6 | 2:1.2.3-1 libx11-6 | 2:1.6.7-1 libxext6 | 2:1.3.3-1+b2 libxft2 (>> 2.1.1) | 2.3.2-2 libxmu6 | 2:1.1.2-2+b3 libxt6 | 1:1.1.5-1+b3 Package's Recommends field is empty. Package's Suggests field is empty. -- To mitigate against EFAIL attacks email messages will be handled only as plain text, please do not send emails in an HTML form to this recipient! signature.asc Description: OpenPGP digital signature
Bug#935304: [libpam-systemd] This bug also prevents KDE Plasma5 Desktop from being used in Buster for SysV init users
Package: libpam-systemd Version: 241-5 Control: severity -1 important --- Please enter the report below this line. --- I was using the KDE Plasma 5 Desktop in Stretch but during the upgrade process to Buster this dependency broke things for me as a SysV init user as the following dependency chain exists: plasma-desktop -> plasma-workspace -> udisks2 -> libpam-systemd -> systemd AND systemd-sysv The dependency on systemd-sysv did NOT appear in the previous "Stretch" and I was happy to tolerate systemd on my system as long as it was NOT PID1 i.e. with a SysV init. This bug thus seems to be a regression in that I can no longer have this. As this forces a change of Desktop and all the packages associated with it I feel this warrants remarking this as an "important" bug and I have attempted to do so... Stephen --- System information. --- Architecture: Kernel: Linux 4.19.0-5-amd64 Debian Release: 10.0 500 stable security.debian.org 500 stable ftp.uk.debian.org 500 stable apt.spideroak.com --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- To mitigate against EFAIL attacks email messages will be handled only as plain text, please do not send emails in an HTML form to this recipient! signature.asc Description: OpenPGP digital signature
Bug#928778: [libqt5core5a] System Qt version no longer supported upstream
Package: libqt5core5a Version: 5.7.1+dfsg-3+deb9u1 Severity: normal Tags: security X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org --- Please enter the report below this line. --- I was aware that Qt 5.6.3 (LTS) has recently reached end-of-support (2019/03/16) but I hadn't stopped to think that 5.7.1 is well past the end-point for non-Long Term Support upstream (2017/06/16) - that being the case and for Debian "Stretch" being the current *stable* version until "Buster" gets out the door in the next few months, isn't it a good idea, at least from a security and safety point of view, for Debian to upgrade to a version, such as Qt 5.9.7 which has long-term support from Qt until 2020/05/31...? --- System information. --- Architecture: Kernel: Linux 4.9.0-8-amd64 Debian Release: 9.9 500 stable security.debian.org 500 stable ftp.uk.debian.org 500 stable apt.spideroak.com 100 stretch-backports deb.debian.org --- Package information. --- Depends (Version) | Installed ===-+-== libc6 (>= 2.14) | 2.24-11+deb9u4 libdouble-conversion1(>= 2.0.0) | 2.0.1-4 libgcc1 (>= 1:3.4) | 1:6.3.0-18+deb9u1 libglib2.0-0(>= 2.22.0) | 2.50.3-2 libicu57 (>= 57.1-1~) | 57.1-6+deb9u2 libpcre16-3 (>= 2:8.35-4) | 2:8.39-3 libstdc++6 (>= 5) | 6.3.0-18+deb9u1 zlib1g (>= 1:1.1.4) | 1:1.2.8.dfsg-5 Recommends(Version) | Installed ===-+-=== qttranslations5-l10n| 5.7.1~20161021-1 Suggests (Version) | Installed ===-+-=== libthai0| 0.1.26-1 -- To mitigate against EFAIL attacks email messages will be handled only as plain text, please do not send emails in an HTML form to this recipient! signature.asc Description: OpenPGP digital signature
Bug#925484: [plasma-workspace] /usr/start/startkde not exporting correct XDG_DATA_DIR
Package: plasma-workspace Version: 4:5.8.6-2.1+deb9u1 Severity: normal --- Please enter the report below this line. --- It appears that plasma-workspace is replicating the bug recorded as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782285 for the package from an old Debian version of kde-workspace-bin. It does seem to be an upstream bug in that the relevant line 196 in https://cgit.kde.org/plasma-workspace.git/tree/startkde/startkde.cmake is not respecting the XDG standards for XDG_DATA_DIR and insisting on putting its CMake build time variable KDE_INSTALL_FULL_DATAROOTDIR in the first (highest priority) position in that list. Unfortunately for Debian builds this happens to correspond to an existing directory so the value used is: "/usr/share:/usr/share:/usr/local/share" whereas it should be - IMHO - work out to be: "/usr/local/share:/usr/share" Whether the KDE people are taking coding shortcuts and ONLY using the first directory listed or correctly considering them all in order I cannot say... --- System information. --- Architecture: Kernel: Linux 4.9.0-8-amd64 Debian Release: 9.8 500 stable security.debian.org 500 stable ftp.uk.debian.org 500 stable apt.spideroak.com 100 stretch-backports deb.debian.org --- Package information. --- Depends (Version) | Installed =-+-== dbus-x11 | 1.10.26-0+deb9u1 frameworkintegration | 5.28.0-1 gdb-minimal | OR gdb | 7.12-6 iso-codes | 3.75-1 kactivitymanagerd | 5.8.4-1 kde-cli-tools | 4:5.8.4-2 kded5 | 5.28.0-1 kinit | 5.28.0-1 kio | 5.28.0-2 libkf5globalaccel-bin (>= 5.7.0) | 5.28.0-1 libkf5service-bin | 5.28.0-1 milou | 4:5.8.4-1 plasma-framework | 5.28.0-2 plasma-integration | 5.8.6-1 qdbus-qt5 | 5.7.1-1 qml-module-org-kde-draganddrop | 5.28.0-1 qml-module-org-kde-extensionplugin | 5.28.0-1 qml-module-org-kde-kcoreaddons | 5.28.0-1 qml-module-org-kde-kholidays | 16.04.2-1 qml-module-org-kde-kquickcontrols | 5.28.0-1 qml-module-org-kde-kquickcontrolsaddons | 5.28.0-1 qml-module-org-kde-kwindowsystem | 5.28.0-1 qml-module-org-kde-solid | 5.28.0-3 qml-module-qt-labs-folderlistmodel | 5.7.1-2+b2 qml-module-qtgraphicaleffects | 5.7.1~20161021-3 qml-module-qtqml-models2 | 5.7.1-2+b2 qml-module-qtquick-controls | 5.7.1~20161021-2 qml-module-qtquick-dialogs | 5.7.1~20161021-2 qml-module-qtquick-layouts | 5.7.1-2+b2 qml-module-qtquick-window2 | 5.7.1-2+b2 qml-module-qtquick2 | 5.7.1-2+b2 qttools5-dev-tools (>= 5.7~) | 5.7.1-1 udisks2 | 2.1.8-1 x11-utils | 7.7+3+b1 x11-xserver-utils | 7.7+7+b1 kpackagetool5 | 5.28.1-1 libc6 (>= 2.15) | 2.24-11+deb9u4 libcln6 | 1.3.4-2+b1 libdbusmenu-qt5-2 (>= 0.6.6) | 0.9.3+16.04.20160218-1 libgcc1(>= 1:3.0) | 1:6.3.0-18+deb9u1 libgps22 (>= 3.3) | 3.16-4 libice6 (>= 1:1.0.0) | 2:1.0.9-2 libkf5activities5 (>= 4.96.0) | 5.28.0-1 libkf5auth5 (>= 4.96.0) | 5.28.0-2 libkf5baloo5 (>= 5.3.0+git20150512) | 5.28.0-2 libkf5bookmarks5 (>= 4.96.0) | 5.28.0-1 libkf5calendarevents5 | 5.28.0-1 libkf5completion5 (>= 4.97.0) | 5.28.0-1 libkf5configcore5 (>= 5.24.0) | 5.28.0-2 libkf5configgui5 (>= 4.97.0) | 5.28.0-2 libkf5configwidgets5 (>= 4.96.0) | 5.28.0-2 libkf5coreaddons5 (>= 5.20.0) | 5.28.0-2 libkf5crash5 (>= 4.96.0) | 5.28.0-1 libkf5dbusaddons5 (>= 4.99.0) | 5.28.0-1 libkf5declarative5(>= 5.12.0) | 5.28.0-1 libkf5globalaccel5(>= 5.10.0) | 5.28.0-1 libkf5guiaddons5 (>= 4.96.0) | 5.28.0-1 libkf5holidays5 (>= 15.12.0) | 16.04.2-1 libkf5i18n5 (>= 4.97.0) | 5.28.0-2 libkf5iconthemes5 (>= 5.25.0) | 5.28.0-2 libkf5idletime5
Bug#880053: [plasma-widgets-addons] Error has corrected itself following the end of the extra Wall-clock hour
Package: plasma-widgets-addons Version: 4:5.8.5-2 --- Please enter the report below this line. --- It seems that the defect only persists for the duration of the time when the wall clock is back at the end of DST, at the *end* of the hour the time zone has been corrected to the expected "GMT" from the "BST" value - so the bug would seem to be in the logic that changes the timezone information in that it made the change at the end of the hour not the beginning...! The display is still wrong for that hour but I guess one hour out of approximately four and a half thousands is enough to downgrade the seriousness a bit? Stephen signature.asc Description: OpenPGP digital signature
Bug#880053: [plasma-widgets-addons] Ending of DST not updating TimeZone display
Package: plasma-widgets-addons Version: 4:5.8.5-2 Severity: important --- Please enter the report below this line. --- With the ending of Daylight Saving Time for the TimeZone of Europe/London at 01:00:00 UTC on 2017/10/29 I noted the displayed time jumping back from 01:59:50 to 01:00:00 as anticipated however the timezone information displayed alongside remained as "(BST)" i.e. "British Summer Time" - this means that the displayed information is WRONG. The display should have switched to "GMT" i.e. "Greenwich Mean Time" at the same time as the clock was adjusted. With this error it is possible in the short term (for the remainder of the hour or so) to be uncertain as to what the time actually is. 8-P I am not entirely sure this is the correct package to report this bug against if it is not please advise me and/or move it to the correct package if possible. I would note that a command line invocation of date(1) in conjunction with the line "TZ='Europe/London'; export TZ" in my ~/.profile yields the expected "GMT". It may be that a log out and log back in again to restart the KDE desktop will correct this - if this does *not* happen I will update the bug-report when I next restart KDE but that may be some days down the line... Stephen --- System information. --- Architecture: Kernel: Linux 4.12.0-0.bpo.2-amd64 Debian Release: 9.2 500 stable-updates ftp.uk.debian.org 500 stable security.debian.org 500 stable ftp.uk.debian.org 500 stable apt.spideroak.com 100 stretch-backports ftp.uk.debian.org --- Package information. --- Depends(Version) | Installed -+-== kdeplasma-addons-data (= 4:5.8.5-2) | 4:5.8.5-2 kpackagetool5| 5.28.1-1 plasma-dataengines-addons (= 4:5.8.5-2) | 4:5.8.5-2 plasma-framework | 5.28.0-2 plasma-workspace | 4:5.8.6-2.1 qml-module-org-kde-draganddrop | 5.28.0-1 qml-module-org-kde-purpose | 1.1-4 qml-module-org-kde-kcoreaddons | 5.28.0-1 qml-module-org-kde-kio | 5.28.0-1 qml-module-qtgraphicaleffects| 5.7.1~20161021-3 qml-module-qtwebkit | 5.7.1+dfsg-1 kio | 5.28.0-2 libc6 (>= 2.14) | 2.24-11+deb9u1 libkf5archive5 (>= 4.96.0) | 5.28.0-2 libkf5completion5(>= 4.97.0) | 5.28.0-1 libkf5configcore5(>= 4.97.0) | 5.28.0-2 libkf5configgui5 (>= 4.97.0) | 5.28.0-2 libkf5coreaddons5(>= 4.99.0) | 5.28.0-2 libkf5i18n5 (>= 4.97.0) | 5.28.0-2 libkf5iconthemes5(>= 4.96.0) | 5.28.0-2 libkf5kiocore5 (>= 4.96.0) | 5.28.0-2 libkf5kiowidgets5(>= 4.96.0) | 5.28.0-2 libkf5newstuff5 (>= 5.0.0) | 5.28.0-1 libkf5notifications5 (>= 5.8.0+git20150317.0114+15.04) | 5.28.0-1 libkf5plasma5(>= 5.21.0) | 5.28.0-2 libkf5service-bin| 5.28.0-1 libkf5service5 (>= 4.96.0) | 5.28.0-1 libkf5unitconversion5(>= 4.98.0) | 5.28.0-1 libkf5widgetsaddons5 (>= 4.96.0) | 5.28.0-3 libkf5windowsystem5(>= 5.6.0+git20150112.0023+15.04) | 5.28.0-2 libkf5xmlgui5(>= 4.96.0) | 5.28.0-1 libqt5core5a (>= 5.7.0) | 5.7.1+dfsg-3+b1 libqt5dbus5 (>= 5.4) | 5.7.1+dfsg-3+b1 libqt5gui5(>= 5.7.0) | 5.7.1+dfsg-3+b1 libqt5qml5(>= 5.0.2) | 5.7.1-2+b2 libqt5quick5 (>= 5.1.0) | 5.7.1-2+b2 libqt5widgets5 (>= 5.4) | 5.7.1+dfsg-3+b1 libstdc++6(>= 4.1.1) | 6.3.0-18 Package's Recommends field is empty. Package's Suggests field is empty. signature.asc Description: OpenPGP digital signature
Bug#870208: [Mudlet] Bug in Version 3.2.0 and (3.3.0) causes loss of user created content
Package: Mudlet
Version: 1:3.2.0-1
Severity: grave
--- Please enter the report below this line. ---
ADVISORY FROM UPSTREAM:
A defect present in the Mudlet Version currently included in "Testing"
and "Unstable" causes user created content
("Triggers"/"Aliases"/"Buttons"/"Keys"/"Scripts") to be lost when a MUD
session/profile is closed and saved then opened and reloaded then closed
and saved a second time. Due to a flag not being initialised when each
instance of any of the above "items" are loaded they can be incorrectly
marked as being "temporary" and thus not to be saved at the end of a
session.
This issue was reported in Issue:
https://github.com/Mudlet/Mudlet/issues/1174
and corrected by Pull-Request:
https://github.com/Mudlet/Mudlet/pull/1179 which was incorporated into
Version: 3.3.1
I am one of the "Mudlet Makers" (Upstream coders) and wish to ensure
that fellow Debian users do not suffer problems that we have already
fixed. 8-)
Stephen
signature.asc
Description: OpenPGP digital signature
Bug#835649: [flashplugin-nonfree] OldStable (Wheezy) version of package is critically out of date
According to
https://helpx.adobe.com/security/products/flash-player/apsb16-25.html
the listed CVEs are:
CVE-2016-4172, CVE-2016-4173, CVE-2016-4174, CVE-2016-4175,
CVE-2016-4176, CVE-2016-4177, CVE-2016-4178, CVE-2016-4179,
CVE-2016-4180, CVE-2016-4181, CVE-2016-4182, CVE-2016-4183,
CVE-2016-4184, CVE-2016-4185, CVE-2016-4186, CVE-2016-4187,
CVE-2016-4188, CVE-2016-4189, CVE-2016-4190, CVE-2016-4217,
CVE-2016-4218, CVE-2016-4219, CVE-2016-4220, CVE-2016-4221,
CVE-2016-4222, CVE-2016-4223, CVE-2016-4224, CVE-2016-4225,
CVE-2016-4226, CVE-2016-4227, CVE-2016-4228, CVE-2016-4229,
CVE-2016-4230, CVE-2016-4231, CVE-2016-4232, CVE-2016-4233,
CVE-2016-4234, CVE-2016-4235, CVE-2016-4236, CVE-2016-4237,
CVE-2016-4238, CVE-2016-4239, CVE-2016-4240, CVE-2016-4241,
CVE-2016-4242, CVE-2016-4243, CVE-2016-4244, CVE-2016-4245,
CVE-2016-4246, CVE-2016-4247, CVE-2016-4248, CVE-2016-4249
I am sorry but I have not tried to pin down which of them actually
related to the Linux OS, but at least one of them seems to be "bad"
enough for steps to have been taken to address the issue for "Stable"
and "Testing", it is just that this has not made it back into "OldStable".
As for "affected flashplayer versions" 11.2.202.626 is a victim
according to the same web-page and 11.2.202.632 is "the cure",
regrettably, flashplugin-nonfree 3.2 from the "OldStable" distribution
will leave "626" in place as it does not have the "fixes" that the later
versions 3.6.1 or 3.7 have.
I believe that the needed changes are the ones that:
* replaces the "get-upstream-version.pl" if it is older than 2016-08-04
09:35" in /usr/sbin/update-flashplugin-nonfree
* revises the user-agent string in the file referred to, i.e.
/var/cache/flashplugin-nonfree/get-upstream-version.pl (so it does not
have a "KH" in it?) AND does NOT use "fp10"(?) (as a download source).
I would be lying if I said I fully understood the revisions that have
been made to the package but as I understand these are so that the
package does not try and download something with a 20.xxx version
numbers which "is NOT the file that we are looking for"!
As I said, FireFox is now actively blocking that older flash version so
there is a loss of functionality as it attempts to protect users from
the vulnerabilities...
I hope that helps!
Regards
Stephen
On 28/08/16 07:05, Bart Martens wrote:
> Control tags 835649 moreinfo
>
> On Sat, Aug 27, 2016 at 11:41:02PM +0100, Stephen Lyons wrote:
>> I believe the version of this package for Debian 7 installations
>> ("OldStable") is *critically* out of date and still has the CVEs that
>> have been addressed by later versions 1:3.6.1 in "Stable" or 1:3.7
>> "Testing" and "Unstable".
>
> Which CVEs exactly?
>
>> For the record, backporting by hand-editing in the differences between
>> 3.2 and 3.7 into the 3.2 version does seem to do the job
>
> Which differences exactly matter?
>
> Regards,
>
> Bart Martens
>
signature.asc
Description: OpenPGP digital signature
Bug#835649: [flashplugin-nonfree] OldStable (Wheezy) version of package is critically out of date
Package: flashplugin-nonfree
Version: 1:3.2+wheezy1
Severity: critical
Tags: security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org
--- Please enter the report below this line. ---
I believe the version of this package for Debian 7 installations
("OldStable") is *critically* out of date and still has the CVEs that
have been addressed by later versions 1:3.6.1 in "Stable" or 1:3.7
"Testing" and "Unstable". Whilst I appreciate that "Wheezy" is long in
the tooth, it still should be getting security updates for a little
while longer!
For the record, backporting by hand-editing in the differences between
3.2 and 3.7 into the 3.2 version does seem to do the job - the
diagnostic stuff below does not represent the exact state of a Wheezy
system because I got fed up with the FireFox blacklisting of the old
flashplayer version so manually installed it myself and dropped it into
the "alternatives" system but other users of "OldStable" might not be so
able to munge things themselves...
Regards
Stephen
--- System information. ---
Architecture: amd64
Kernel: Linux 3.16.0-0.bpo.4-amd64
Debian Release: 7.11
500 wheezy-backports mozilla.debian.net 500 stable
apt.spideroak.com 500 oldstable-updates mirror.sov.uk.goscomb.net
500 oldstable-proposed-updates mirror.sov.uk.goscomb.net 500 oldstable
security.debian.org 500 oldstable
mirror.sov.uk.goscomb.net 100 wheezy-backports
mirror.sov.uk.goscomb.net 100 wheezy-backports ftp.debian.org
--- Package information. ---
Depends (Version) | Installed
==-+-===
debconf| 1.5.49
OR debconf-2.0| wget |
1.13.4-3+deb7u3
gnupg | 1.4.12-7+deb7u8
libatk1.0-0| 2.4.0-2
libcairo2 | 1.12.2-3
libfontconfig1 | 2.9.0-7.1+deb7u1
libfreetype6 | 2.4.9-1.1+deb7u3
libgcc1| 1:4.7.2-5
libglib2.0-0 | 2.33.12+really2.32.4-5
libgtk2.0-0 (>= 2.14) | 2.24.10-2
libnspr4 | 2:4.9.2-1+deb7u4
libnss3| 2:3.14.5-1+deb7u8
libpango1.0-0 | 1.30.0-1
libstdc++6 | 4.7.2-5
libx11-6 | 2:1.5.0-1+deb7u2
libxext6 | 2:1.3.1-2+deb7u1
libxt6 | 1:1.1.3-1+deb7u1
libcurl3-gnutls| 7.26.0-1+wheezy14
binutils | 2.22-8+deb7u3
ca-certificates| 20130119+deb7u1
Package's Recommends field is empty.
Suggests (Version) | Installed
-+-===
iceweasel| konqueror-nsplugins
| 4:4.8.4-2
ttf-mscorefonts-installer| 3.4+nmu1
ttf-dejavu | 2.33-3
ttf-xfree86-nonfree | 4.2.1-3.1
hal | 0.5.14-8
--- Output from package bug script ---
Debian version: 7.11
Architecture: amd64
Package version: 1:3.2+wheezy1
Adobe Flash Player version: LNX 11,2,202,632
MD5 checksums:
29c85bc8504422120cf89702986ff8e1
/var/cache/flashplugin-nonfree/get-upstream-version.pl
160a01dd00527304e5291e65eb0c65e2
/var/cache/flashplugin-nonfree/get-upstream-version.pl.orig
ace1a0801f00a25fd90172f63e98e101
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
e3a1280f91b278b8832500f362d0546b
/var/cache/flashplugin-nonfree/libflashplayer-11.2.202.632.so
e3a1280f91b278b8832500f362d0546b
/var/cache/flashplugin-nonfree/libflashplayer.so
md5sum: /var/cache/flashplugin-nonfree/temp: Is a directory
e3a1280f91b278b8832500f362d0546b
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
link currently points to
/usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer-11.2.202.632.so - priority
20
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is
'/usr/lib/flashplugin-nonfree/libflashplayer.so'.
lrwxrwxrwx 1 root root 34 Jul 30 14:52
/usr/lib/mozilla/plugins/flash-mozilla.so ->
/etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to
/etc/alternatives/flash-mozilla.so
signature.asc
Description: OpenPGP digital signature
Bug#820645: [flashplugin-nonfree] Still not done on OldStable
Package: flashplugin-nonfree Version: 1:3.2+wheezy1 --- Please enter the report below this line. --- As I am speaking about OldStable the message "We believe that the bug you reported is fixed in the latest version of flashplugin-nonfree, which is due to be installed in the Debian FTP archive." does not really seem applicable! I am not seeing the fix in the repositories I'm using. In hindsight I realise that this topic pales into insignificance when compared to the failure to update to the latest CVE-fixing one! So I'll not worry about it as it will get fixed when that grave one is fixed. Stephen --- System information. --- Architecture: amd64 Kernel: Linux 3.16.0-0.bpo.4-amd64 Debian Release: 7.11 500 wheezy-backports mozilla.debian.net 500 stable apt.spideroak.com 500 oldstable-updates mirror.sov.uk.goscomb.net 500 oldstable-proposed-updates mirror.sov.uk.goscomb.net 500 oldstable security.debian.org 500 oldstable mirror.sov.uk.goscomb.net 100 wheezy-backports mirror.sov.uk.goscomb.net 100 wheezy-backports ftp.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== debconf| 1.5.49 OR debconf-2.0| wget | 1.13.4-3+deb7u3 gnupg | 1.4.12-7+deb7u8 libatk1.0-0| 2.4.0-2 libcairo2 | 1.12.2-3 libfontconfig1 | 2.9.0-7.1+deb7u1 libfreetype6 | 2.4.9-1.1+deb7u3 libgcc1| 1:4.7.2-5 libglib2.0-0 | 2.33.12+really2.32.4-5 libgtk2.0-0 (>= 2.14) | 2.24.10-2 libnspr4 | 2:4.9.2-1+deb7u4 libnss3| 2:3.14.5-1+deb7u8 libpango1.0-0 | 1.30.0-1 libstdc++6 | 4.7.2-5 libx11-6 | 2:1.5.0-1+deb7u2 libxext6 | 2:1.3.1-2+deb7u1 libxt6 | 1:1.1.3-1+deb7u1 libcurl3-gnutls| 7.26.0-1+wheezy14 binutils | 2.22-8+deb7u3 ca-certificates| 20130119+deb7u1 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== iceweasel| konqueror-nsplugins | 4:4.8.4-2 ttf-mscorefonts-installer| 3.4+nmu1 ttf-dejavu | 2.33-3 ttf-xfree86-nonfree | 4.2.1-3.1 hal | 0.5.14-8 signature.asc Description: OpenPGP digital signature
Bug#820645: [flashplugin-nonfree] Bug closure incorrect - still present on reported (Old-stable) version
Package: flashplugin-nonfree Version: 1:3.2+wheezy1 --- Please enter the report below this line. --- --- System information. --- Architecture: amd64 Kernel: Linux 3.16.0-0.bpo.4-amd64 Debian Release: 7.11 500 wheezy-backports mozilla.debian.net 500 stable apt.spideroak.com 500 oldstable-updates mirror.sov.uk.goscomb.net 500 oldstable-proposed-updates mirror.sov.uk.goscomb.net 500 oldstable security.debian.org 500 oldstable mirror.sov.uk.goscomb.net 100 wheezy-backports mirror.sov.uk.goscomb.net 100 wheezy-backports ftp.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== debconf| 1.5.49 OR debconf-2.0| wget | 1.13.4-3+deb7u3 gnupg | 1.4.12-7+deb7u7 libatk1.0-0| 2.4.0-2 libcairo2 | 1.12.2-3 libfontconfig1 | 2.9.0-7.1 libfreetype6 | 2.4.9-1.1+deb7u3 libgcc1| 1:4.7.2-5 libglib2.0-0 | 2.33.12+really2.32.4-5 libgtk2.0-0 (>= 2.14) | 2.24.10-2 libnspr4 | 2:4.9.2-1+deb7u4 libnss3| 2:3.14.5-1+deb7u8 libpango1.0-0 | 1.30.0-1 libstdc++6 | 4.7.2-5 libx11-6 | 2:1.5.0-1+deb7u2 libxext6 | 2:1.3.1-2+deb7u1 libxt6 | 1:1.1.3-1+deb7u1 libcurl3-gnutls| 7.26.0-1+wheezy13 binutils | 2.22-8+deb7u3 ca-certificates| 20130119+deb7u1 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== iceweasel| konqueror-nsplugins | 4:4.8.4-2 ttf-mscorefonts-installer| 3.4+nmu1 ttf-dejavu | 2.33-3 ttf-xfree86-nonfree | 4.2.1-3.1 hal | 0.5.14-8 --- Output from package bug script --- Debian version: 7.11 Architecture: amd64 Package version: 1:3.2+wheezy1 Adobe Flash Player version: LNX 11,2,202,626 MD5 checksums: 160a01dd00527304e5291e65eb0c65e2 /var/cache/flashplugin-nonfree/get-upstream-version.pl 48a2167247b42b04f3610eb7350a053f /var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz e3a1280f91b278b8832500f362d0546b /var/cache/flashplugin-nonfree/libflashplayer.so md5sum: /var/cache/flashplugin-nonfree/temp: Is a directory 1b0b549f4c1e1d60bd0bbc6799c87824 /usr/lib/flashplugin-nonfree/libflashplayer.so Alternatives: flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. lrwxrwxrwx 1 root root 34 Jul 30 14:52 /usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so /usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to /etc/alternatives/flash-mozilla.so signature.asc Description: OpenPGP digital signature
Bug#820645: [flashplugin-nonfree] With reversion to Firefox from Iceweasel flashplugin-nonfree should have both as "suggests"
Package: flashplugin-nonfree Version: 1:3.2+wheezy1 Severity: normal --- Please enter the report below this line. --- Whilst trying to fix a report that my flashplayer plug-in was vulnerable (from the plug-in checker within FireFox) I spotted in aptitude that although *IceWeasel* is something that is suggested by this package (note the Suggests table below), *FireFox* is not, this might be something that ought to be tweaked given that Debian is reverting to a FireFox branded Mozilla web-browser... FTR I have been running both browsers and had just un-installed IceWeasel so am puzzled why it is still shown as "Installed"! --- System information. --- Architecture: amd64 Kernel: Linux 3.16.0-0.bpo.4-amd64 Debian Release: 7.10 500 wheezy-backports mozilla.debian.net 500 stable apt.spideroak.com 500 oldstable-updates mirror.sov.uk.goscomb.net 500 oldstable-proposed-updates mirror.sov.uk.goscomb.net 500 oldstable security.debian.org 500 oldstable mirror.sov.uk.goscomb.net 100 wheezy-backports mirror.sov.uk.goscomb.net 100 wheezy-backports ftp.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== debconf| 1.5.49 OR debconf-2.0| wget | 1.13.4-3+deb7u2 gnupg | 1.4.12-7+deb7u7 libatk1.0-0| 2.4.0-2 libcairo2 | 1.12.2-3 libfontconfig1 | 2.9.0-7.1 libfreetype6 | 2.4.9-1.1+deb7u3 libgcc1| 1:4.7.2-5 libglib2.0-0 | 2.33.12+really2.32.4-5 libgtk2.0-0 (>= 2.14) | 2.24.10-2 libnspr4 | 2:4.9.2-1+deb7u3 libnss3| 2:3.14.5-1+deb7u5 libpango1.0-0 | 1.30.0-1 libstdc++6 | 4.7.2-5 libx11-6 | 2:1.5.0-1+deb7u2 libxext6 | 2:1.3.1-2+deb7u1 libxt6 | 1:1.1.3-1+deb7u1 libcurl3-gnutls| 7.26.0-1+wheezy13 binutils | 2.22-8+deb7u2 ca-certificates| 20130119+deb7u1 Package's Recommends field is empty. Suggests (Version) | Installed -+-=== iceweasel| 44.0.2-1~bpo70+1 konqueror-nsplugins | 4:4.8.4-2 ttf-mscorefonts-installer| 3.4+nmu1 ttf-dejavu | 2.33-3 ttf-xfree86-nonfree | 4.2.1-3.1 hal | 0.5.14-8 --- Output from package bug script --- Debian version: 7.10 Architecture: amd64 Package version: 1:3.2+wheezy1 Adobe Flash Player version: LNX 11,2,202,577 MD5 checksums: 160a01dd00527304e5291e65eb0c65e2 /var/cache/flashplugin-nonfree/get-upstream-version.pl b6edd26db2067c7ccf4c0354d63517fd /var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz 2f6901557105d2d51a96a07d85cad6fe /usr/lib/flashplugin-nonfree/libflashplayer.so Alternatives: flash-mozilla.so - auto mode link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so /usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50 Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'. lrwxrwxrwx 1 root root 34 Mar 19 13:48 /usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so /usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to /etc/alternatives/flash-mozilla.so signature.asc Description: OpenPGP digital signature
Bug#774046: [adduser] weak username check provided by --force-badname does not match useradd capability
Package: adduser
Version: 3.113+nmu3
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
In the man page for this command is written:
> --force-badname
> By default, user and group names are checked against the
> configurable regular expression NAME_REGEX specified in
> the configuration file. This option forces adduser and
> addgroup to apply only a weak check for validity of the
> name.
Also:
> root@Kirk:/home# adduser --help
> adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
> [--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
> [--disabled-password] [--disabled-login] USER
>Add a normal user
>
> adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
> [--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password]
> [--disabled-login] USER
>Add a system user
>
> adduser --group [--gid ID] GROUP
> addgroup [--gid ID] GROUP
>Add a user group
>
> addgroup --system [--gid ID] GROUP
>Add a system group
>
> adduser USER GROUP
>Add an existing user to an existing group
>
> general options:
> --quiet | -q don't give process information to stdout
> --force-badname allow usernames which do not match the
> NAME_REGEX configuration variable
> --help | -h usage message
> --version | -vversion number and copyright
> --conf | -c FILE use FILE as configuration file
>
It is not obvious what that weak check *IS* however the --help
reiterates that --force-badname should bypass the NAME_REGEX
configuration variable - which I found (commented out) lurking at the
bottom of /etc/adduser.conf:
> root@Kirk:/home# tail -4 /etc/adduser.conf
>
>
> # check user and group names also against this regular expression.
> #NAME_REGEX="^[a-z][-a-z0-9_]*\$"
I have found that what is accepted does not include accented characters
when encoded in Utf-8. Perusing the Perl code for this command reveals
this:
> # checkname: perform some sanity checks
> # parameters:
> # none
> # return values:
> # none (exits on error)
> sub checkname {
> my ($name) = @_;
> if ($name !~ /^[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$/) {
> printf STDERR
> (gtx("%s: To avoid problems, the username should consist only of
> letters, digits, underscores, periods, at signs and dashes, and not start with
> a dash (as defined by IEEE Std 1003.1-2001). For compatibility with Samba
> machine accounts \$ is also supported at the end of the username\n"), $0);
> exit RET_INVALID_CHARS_IN_NAME;;
> }
> if ($name !~ qr/$config{"name_regex"}/) {
> if ($allow_badname) {
> print (gtx("Allowing use of questionable username.\n")) if ($verbose);
> }
> else {
> printf STDERR
> (gtx("%s: Please enter a username matching the regular expression configured
> via the NAME_REGEX configuration variable. Use the `--force-badname'
> option to relax this check or reconfigure NAME_REGEX.\n"), $0);
> exit RET_INVALID_CHARS_IN_NAME;
> }
> }
> }
so this suggests that the pertinent expression is:
[_.A-Za-z0-9][-\@_.A-Za-z0-9]*\$?$
However this seems unduly strong for a *weak* check when compared to the
documentation for the useradd ELF-executable, in particular in the
CAVEATS section is:
> It is usually recommended to only use usernames that begin with a lower case
> letter or an underscore, followed by lower case letters, digits, underscores,
> or dashes. They can end with a dollar sign. In regular expression terms:
> [a-z_][a-z0-9_-]*[$]?
>
> On Debian, the only constraints are that usernames must neither start with a
> dash('-') nor plus ('+') nor tilde ('~') nor contain a colon (':'), a comma
> (',') or a whitespace (space: ' ', end of line: '\n', tab: '\t', etc.) Note
> that using a slash ('/') may break the default algorithm for the definition
> of the user's home directory.
>
> Usernames may only be up to 32 characters long.
Sadly, I am not a Perlmunger, but it strikes me that if anyone can
express the above and plug it into that first "if" in the Perl
sub-routine then, on principle of least surprise, what adduser will
accept if *forcible* *told* *to* will actually match what useradd will
handle.
I originally had a much stronger worded post about how adduser seems to
be broken because "adduser --force-badname cáfé" would not work as
described and how by commenting out that 8-line "if" in the Perl
sub-routine I *was* able to create such a user with accented characters.
I now realise that adduser is a Debian wrapper around useradd and it
enforces (or is supposed to) Debian policies - however it still seems
that the documentation could be clearer than it is.
The reason for my raising this is that I am working on a project that
runs on a range of OSs - some of which make no claim to meet
POSIX.1-2008 {that outfit based in Redmond, Washington for instance}
however THAT system permits u
Bug#762194: An end-users perspective on an automatic switch to systemd on wheezy->jessie upgrades
Can I offer the view of a concerned end-user here?
I have worries about the proposal to force me to change from a sysV init
system about which I'm still learning things despite first starting with
GNU/Linux perhaps twenty years ago, to a new-fangled systemd system
that, to me, does not (yet) seem stable and which possesses significant
gaps in functionality especially in regards to non-main stream
configurations.
Over time one of the features that attracted me to Debian was the
conservative but robust attitude it had compared to some other
distributions - you won't necessarily get the latest bells and whistles
but you could get a well tested and relatively stable platform. For
that reason - and the fact that I'm not running bleeding edge hardware -
I would wish to choose not to adopt sure a core component {and from what
I've read of it today its developers do seem to want it to be *the* core
component on many linux systems} as systemd until either there was
absolutely no other choice or it was pretty much foolproof. At this
time I can't see either of these being the case.
For new system installs, yes I can see that it might be reasonable to
try as a default - generally a new system install is either going to be
someone trying a *nix OS for the first time or someone who is preparing
to change from another distribution. In those cases the user is not
going to have data and configuration already present or they will have
taken steps to save what they want to transplant from one setup to
another. If, for some reason, things don't work out they likely to have
an alternative direction to try. For upgrades, it is a different kettle
of worms, the user has tweaked things to their likings and will have
some, if not a lot, of data that they want to hang on to; they may be
willing to try some new features or changes if those enhances their user
experience but they won't necessarily want to throw the baby out with
the bathwater. A default upgrade path that has even just a small chance
of leaving them with an unbootable system and with, I suspect, no quick
and easy way to backout from does not seem the optimum choice!
A concerned Debian Wheezy(-backports) User
Stephen Lyons
P.S. I'm speaking also as someone who got clobbered by an Xorg server
upgrade earlier this week - still not entirely sure what went wrong but
glad I only upgraded one machine at a time because a blank Xserver
screen on a machine not accepting keyboard/mouse input is no use to
anyone. Sorta got it back into life but udev/dbus and networking no
longer start automatically on bootup, stopping gmd3 no longer kills the
X server it sometimes manages to spawn which stalls indefinitely
expecting data from the non-existent udev - and I wasted a whole day
getting back to THAT state.
signature.asc
Description: OpenPGP digital signature
Bug#733249: [libreoffice-writer] "Variable" type field with NNNN, NNN and NN date format codes return day name one day in advance
On 27/12/13 20:02, Eike Rathke wrote: > Hi Stephen, > > On Friday, 2013-12-27 19:28:37 +, Stephen Lyons wrote: > >> one displayed field to include a "DD/MM/YY" format code to show the >> name of the day so I could cross-check I had entered the raw date >> correctly but instead of the "Friday, 27/12/13" date I got for an >> entered value of 5110 I got "Saturday, 27/12/13" instead. > > 5110 is the serial date number of Saturday 1913-12-27, check with > a 4 digit format code. Friday 2013-12-27 would be serial date > number 41635. > > Eike > *eek* hadn't spotted I was a century out, I guess I ought to check out this newfangled Gregorian Calendar thing then. 😥 Flag as invalid then signature.asc Description: OpenPGP digital signature
Bug#733249: [libreoffice-writer] Bug appears to affect both "Show Variable" and "Insert Formula" field types
Package: libreoffice-writer Version: 1:4.1.2-2~bpo70+1 --- Please enter the report below this line. --- Upon checking I find that both the "Show Variable" field, where a previously entered value is displayed and the "Inserted formula" where additional maths can be done on previously entered values, display this issue. --- System information. --- As previous --- Package information. --- As previous signature.asc Description: OpenPGP digital signature
Bug#733249: [libreoffice-writer] "Variable" type field with NNNN, NNN and NN date format codes return day name one day in advance
Package: libreoffice-writer Version: 1:4.1.2-2~bpo70+1 Severity: minor --- Please enter the report below this line. --- I was updating a form I created to produce a report every couple of weeks with many fields containing calculated dates set from a single hidden field variable I set at the start of the document. I had changed one displayed field to include a "DD/MM/YY" format code to show the name of the day so I could cross-check I had entered the raw date correctly but instead of the "Friday, 27/12/13" date I got for an entered value of 5110 I got "Saturday, 27/12/13" instead. A cursory search of the LibreOffice bugzilla page did not reveal any obvious reports of this. Adding a time code to the beginning of the format, i.e. changing to: "HH:MM:SS on NNN,DD/MM/YY" and changing the value to 5110.25 yields a result of "06:00:00 on Saturday, 27/12/13" which suggests to me that (as I am on Zulu / UTC time) that this is not a time zone issue. Using the formats on both an inserted "Date" and "Date(fixed)" fields DOES display the correct Day... --- System information. --- Architecture: i386 Kernel: Linux 3.10-0.bpo.3-rt-686-pae Debian Release: 7.3 500 wheezy-backports mozilla.debian.net 500 stable-updates ftp.uk.debian.org 500 stable security.debian.org 500 stable mirror.home-dn.net 500 stable ftp.uk.debian.org 500 stable apt.spideroak.com 500 proposed-updates ftp.uk.debian.org 500 debswww.duinsoft.nl 100 wheezy-backports ftp.debian.org --- Package information. --- Depends (Version) | Installed =-+-== libreoffice-base-core (= 1:4.1.2-2~bpo70+1) | 1:4.1.2-2~bpo70+1 libreoffice-core(= 1:4.1.2-2~bpo70+1) | 1:4.1.2-2~bpo70+1 libc6(>= 2.4) | 2.13-38+deb7u1 libgcc1 (>= 1:4.1.1) | 1:4.7.2-5 libicu48 (>= 4.8-1) | 4.8.1.1-12+deb7u1 libstdc++6 (>= 4.6) | 4.7.2-5 libwpd-0.9-9 | 0.9.4-3 libwpg-0.2-2 | 0.2.1-1 libwps-0.2-2 | 0.2.7-1 libxml2(>= 2.7.4) | 2.8.0+dfsg1-7+nmu2 uno-libs3(>= 4.1.0~alpha) | 4.1.2-2~bpo70+1 ure | 4.1.2-2~bpo70+1 zlib1g (>= 1:1.1.4) | 1:1.2.7.dfsg-13 fontconfig| 2.9.0-7.1 fonts-opensymbol | 2:102.3+LibO4.1.2-2~bpo70+1 libreoffice-common (>> 1:4.1.2) | 1:4.1.2-2~bpo70+1 ure (>= 4.1.2~) | 4.1.2-2~bpo70+1 libatk1.0-0 (>= 1.12.4) | 2.4.0-2 libboost-date-time1.49.0(>= 1.49.0-1) | 1.49.0-3.2 libc6 (>= 2.11) | 2.13-38+deb7u1 libcairo2 (>= 1.2.4) | 1.12.2-3 libcups2 (>= 1.4.0) | 1.5.3-5+deb7u1 libcurl3-gnutls (>= 7.16.2) | 7.26.0-1+wheezy7 libdbus-1-3(>= 1.0.2) | 1.6.8-1+deb7u1 libdbus-glib-1-2(>= 0.78) | 0.100.2-1 libexpat1 (>= 2.0.1) | 2.1.0-1+deb7u1 libexttextcat0 (>= 2.2-8) | 3.2.0-2 libfontconfig1 (>= 2.9.0) | 2.9.0-7.1 libfreetype6 (>= 2.2.1) | 2.4.9-1.1 libgcc1 (>= 1:4.1.1) | 1:4.7.2-5 libgdk-pixbuf2.0-0(>= 2.22.0) | 2.26.1-1 libglib2.0-0 (>= 2.15.0) | 2.33.12+really2.32.4-5 libgraphite2-2.0.0| 1.1.3-1 libgstreamer-plugins-base0.10-0 (>= 0.10.0) | 0.10.36-1.1 libgstreamer0.10-0(>= 0.10.7) | 0.10.36-1.2 libgtk2.0-0 (>= 2.24.0) | 2.24.10-2 libhunspell-1.3-0 | 1.3.2-4 libhyphen0 (>= 2.7.1) | 2.8.3-2 libice6 (>= 1:1.0.0) | 2:1.0.8-2 libicu48 (>= 4.8-1) | 4.8.1.1-12+deb7u1 libjpeg8 (>= 8c) | 8d-1 liblcms2-2| 2.2+git20110628-2.2 libldap-2.4-2 (>= 2.4.7) | 2.4.31-1+nmu2 libmythes-1.2-0 | 2:1.2.2-1 libneon27-gnutls | 0.29.6
Bug#722489: [xfce4-fsguard-plugin] Tooltip does not handle FS <1GB size
Package: xfce4-fsguard-plugin
Version: 1.0.1-1+b1
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
I believe there is a bug in this plug-in all current Debian (including
my Wheezy) distributions which results in a tool-tip type message of
"could not check mountpoint XXX, please check your config" when the file
system that the path XXX concerns is of size less than around 1GBytes.
From inspection of the source from the latest upstream "master" from its
repository at git://git.xfce.org/panel-plugins/xfce4-fsguard-plugin I
see the problem originates there. I have formulated a patch (attached)
which I think will correct this problem.
--- System information. ---
Architecture: i386
Kernel: Linux 3.10-0.bpo.2-rt-686-pae
Debian Release: 7.1
500 wheezy-backports mozilla.debian.net
500 stable-updates mirrors.melbourne.co.uk
500 stable security.debian.org
500 stable mirrors.melbourne.co.uk
500 stable apt.spideroak.com
500 release apt.spideroak.com
500 debswww.duinsoft.nl
100 wheezy-backports ftp.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-==
libatk1.0-0 (>= 1.12.4) | 2.4.0-2
libc6 (>= 2.4) | 2.13-38
libcairo2 (>= 1.2.4) | 1.12.2-3
libfontconfig1(>= 2.9.0) | 2.9.0-7.1
libfreetype6 (>= 2.2.1) | 2.4.9-1.1
libgdk-pixbuf2.0-0 (>= 2.22.0) | 2.26.1-1
libglib2.0-0 (>= 2.18.0) | 2.33.12+really2.32.4-5
libgtk2.0-0 (>= 2.8.0) | 2.24.10-2
libpango1.0-0(>= 1.14.0) | 1.30.0-1
libxfce4ui-1-0 | 4.8.1-1
libxfce4util4 (>= 4.3.99.2) | 4.8.2-1
xfce4-panel (>= 4.7.7) | 4.8.6-4
xfce4-panel (<< 4.9) | 4.8.6-4
Package's Recommends field is empty.
Package's Suggests field is empty.
commit 7f8c65afe0d7cc658ac453a46c0f4f3bf15d7fb9
Author: Stephen Lyons
Date: Mon Sep 9 22:05:21 2013 +0100
BugFix: Tool-tip giving wrong message for fs size < ~1GB.
Signed-off-by: Stephen Lyons
diff --git a/panel-plugin/fsguard.c b/panel-plugin/fsguard.c
index 8d97574..10cf6e8 100644
--- a/panel-plugin/fsguard.c
+++ b/panel-plugin/fsguard.c
@@ -291,10 +291,15 @@ fsguard_check_fs (FsGuard *fsguard)
(*(fsguard->name) != '\0' && strcmp(fsguard->path,
fsguard->name)) ?
_("%s/%s space left on %s (%s)") : _("%s/%s space left on
%s"),
msg_size, msg_total_size, fsguard->path, fsguard->name);
-} else {
+} else if (total > 0 ) {
g_snprintf (msg_total_size, sizeof (msg_total_size), _("%.0f MB"),
total);
g_snprintf (msg_size, sizeof (msg_size), _("%.0f MB"), freespace);
g_snprintf (msg, sizeof (msg),
+(*(fsguard->name) != '\0' && strcmp(fsguard->path,
fsguard->name)) ?
+_("%s/%s space left on %s (%s)") : _("%s/%s space left on
%s"),
+msg_size, msg_total_size, fsguard->path, fsguard->name);
+} else {
+g_snprintf (msg, sizeof (msg),
_("could not check mountpoint %s, please check your
config"),
fsguard->path);
}
signature.asc
Description: OpenPGP digital signature
