Bug#1059442: gitg: Commit dialog overrides Ctrl+Left/Right

2023-12-25 Thread Stefan Tauner 
Package: gitg
Version: 41-2
Severity: important
Tags: patch upstream
X-Debbugs-Cc: stefan.tau...@gmx.at

Dear Maintainers,

after upgrading to Bookworm I have noticed that Ctrl+Left/Right does not work
as expected in the commit dialog of gitg. Usually Ctrl+Left/Right moves the
cursor one word to the left or right, respectively. This is true for GUI text
boxes like the one in reportbug I am currently typing in but also terminal
applications etc. The version of gitg in Bookworm has added a commit message
history feature to the commit dialog that is navigated via said shortcuts,
unfortunately, and it drives me a little bit crazy.

This problem has been reported (1) and fixed (2) upstream by using
Alt+Page up/Page down. I have added the upstream patch to the bookworm branch
of my salsa fork of gitg (3). "debuild -b -uc -us" isn't working due to an
unrelated lintian error:
"E: gitg: library-not-linked-against-libc
[usr/lib/gitg/gitg/plugins/libdiff.so]"
But "fakeroot debian/rules binary" spat out a working .deb that seems to work
fine.

I believe this is a candidate for being backported to Bookworm as the source
change is tiny and the bug is a regression introduced by Bookworm. I am happy
to help if need be (but I am not a Debian maintainer).

KR

1: https://gitlab.gnome.org/GNOME/gitg/-/issues/351
2:
https://gitlab.gnome.org/GNOME/gitg/-/commit/d768b107aef1944d945e73ecf14d74746338afe4
3:
https://salsa.debian.org/stefanct/gitg/-/commit/bdb80f0a76c789cdb3a78d5e4270f7d3daa4f67f


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (89, 'testing'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gitg depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-1~deb12u1
ii  dbus-x11 [dbus-session-bus]   1.14.10-1~deb12u1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gir1.2-peas-1.0   1.34.0-1+b1
ii  git   1:2.39.2-1.1
ii  gsettings-desktop-schemas 43.0-1
ii  libc6 2.36-9+deb12u3
ii  libcairo2 1.16.0-7
ii  libdazzle-1.0-0   3.44.0-1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgee-0.8-2  0.20.6-1
ii  libgirepository-1.0-1 1.74.0-3
ii  libgit2-glib-1.0-01.1.0-1+b1
ii  libglib2.0-0  2.74.6-2
ii  libgspell-1-2 1.12.0-1+b2
ii  libgtk-3-03.24.38-2~deb12u1
ii  libgtksourceview-4-0  4.8.4-4
ii  libjson-glib-1.0-01.6.6-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpeas-1.0-0 1.34.0-1+b1
ii  libsecret-1-0 0.20.5-3
ii  libxml2   2.9.14+dfsg-1.3~deb12u1

gitg recommends no packages.

gitg suggests no packages.

-- no debconf information

Bug#1034655: lightdm: Login dialog after resuming from standby should match xflock4

2023-04-20 Thread Stefan Tauner 
Package: lightdm
Version: 1.26.0-8
Severity: normal
X-Debbugs-Cc: stefan.tau...@gmx.at

Dear Maintainer,

since I am using autologin (because I am using FDE and have to unlock the OS
before boot anyway)
there are usually only two ways to interact with the lightdm: after locking the
session with xflock4
and after resuming from standby. While the UI behaves as I which after locking
manually it does not
when resuming: I'd like to simply enter my password to unlock the session after
resume but the UI is
blank in that case instead of having the username predefined and the focus on
the password field.
Objectively, this is a minor thing but for me it's about 50% of my interactions
:)

It's also a regression IMhO - at least in Debian 10 this worked perfectly (I
kinda skipped 11).
I presume the behavior is due to lightdm itself but maybe it is because of how
the session gets
locked when entering suspend (which is via systemctl suspend)?
The only changes I made to lightdm.conf are setting autologin-user to my
username and
autologin-user-timeout=0. This is a pretty fresh install of Bookworm.

KR


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser3.132
ii  dbus   1.14.6-1
ii  debconf [debconf-2.0]  1.5.82
ii  libaudit1  1:3.0.9-1
ii  libc6  2.36-9
ii  libgcrypt201.10.1-3
ii  libglib2.0-0   2.74.6-2
ii  libpam-systemd [logind]252.6-1
ii  libpam0g   1.5.2-6
ii  libxcb11.15-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.8-2+b1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+23

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.20-2
pn  xserver-xephyr   

-- Configuration Files:
/etc/lightdm/lightdm.conf changed [not included]

-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm

Bug#967933: marked as pending in ant

2022-07-10 Thread Stefan Tauner 
On Mon, 11 Jul 2022 00:06:35 +
Tony Mancill  wrote:

> Control: tag -1 pending
> 
> Hello,
> 
> Bug #967933 in ant reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/java-team/ant/-/commit/b15414ef50d903860f6264e0b49d4658231aa3d5

Hi Tony,

thanks!
What do you think about the junit5 dependencies mentioned earlier that I
have included in my attempt
(https://salsa.debian.org/stefanct/ant/-/commit/3ca052c0b7a1c7300659a791ab18989af6fc25bd)?
I forgot about everything I did back then TBH though.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#967933: ant-optional: Missing ant-junitlauncher.jar

2021-07-15 Thread Stefan Tauner 
Ok, got it. I missed some additional build requirements for Ant on
Junit5 if one wants to build junitlauncher completely and the whole
confined stuff threw me off.

Interestingly, junit5 is then not needed at runtime anymore - at least
not for how josm uses it. I have not tested other applications though.

I have made some additional useful changes but I do not intend to do a
NMU (yet) - it would be my first and I am not really confident that
this does not break anything - unless instructed to do so.
Feel free to copy any of it:
https://salsa.debian.org/stefanct/ant/-/commits/master

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#967933: ant-optional: Missing ant-junitlauncher.jar

2021-07-14 Thread Stefan Tauner 
On Wed, 05 Aug 2020 09:55:57 +0200 Matthijs Kooijman
 wrote:
>
> If my analysis is correct, could you make the changes so
> ant-junitlauncher is included?

Hello,

the good news is, adding that module is not a big deal. I think I have
done that correctly. Even better, it gets rid of the specific error you
reported!

However, that does not make josm test successfully for me. I get
another message that could either mean I built ant-optional not
correctly or there is something weird going on in josm:

test:
[echo] Running unit tests with JUnit
[junitlauncher] Error: Could not find or load main class 
org.apache.tools.ant.taskdefs.optional.junitlauncher.StandaloneLauncher
[junitlauncher] Caused by: java.lang.ClassNotFoundException: 
org.apache.tools.ant.taskdefs.optional.junitlauncher.StandaloneLauncher

The documentation of StandaloneLauncher hints at it should not actually
be used externally. However, it is referenced in
JUnitLauncherTaskTest.java (which is part of the exposed/"confined"
classes) in a test... it's a bit weird.

Since there is some discussion about a newer ant release in some of the
josm tickets with similar problems I tried updating to the currently
available upstream releases (1.10.10 and 1.10.11) but it doesn't fix
that issue.

One of the devs pointed me to the CI configuration that builds on
Ubuntu. Maybe there is some hint in there but I dont see it...
https://github.com/openstreetmap/josm/blob/master/.github/workflows/ant.yml

I am out of ideas. At least it builds fine and is executable...

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#969728: claws-mail-vcalendar-plugin: Incorrect timezone handling

2020-09-07 Thread Stefan Tauner 
Package: claws-mail-vcalendar-plugin
Version: 3.17.3-2
Severity: important

Dear Maintainer,

with claws-mail from Buster (3.17.3-2) the vcal plugin seems to
miscalculate some timestamps due to insufficient timezone handling.
This has been addressed a few times in the past but I think the
following .ics triggers something differently since all reports
(of fixed bugs) that I could find are way older than my version.


BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
CREATED:20200901T141753Z
DESCRIPTION:blabla\nmore bla\n
DTEND;TZID=Europe/Vienna:20200907T14
DTSTART;TZID=Europe/Vienna:20200907T13
LOCATION:https://some.url/bla?blub
SUMMARY;LANGUAGE=us-EN:some text
UID:{dfdf450b-8eea-457b-9a73-8aa1d5bf1e9b}
BEGIN:VALARM
TRIGGER:-PT10M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR


It is displayed at
 - starting at "Mon,  7 Sep 2020 15:00:00 CEST"
 - ending at   "Mon,  7 Sep 2020 16:00:00 CEST"

Since my local time is according to the Europe/Vienna timezone just
like in the .ics (which is correctly displayed as CEST) the correct
time would be 13:00 to 14:00. It seems like the DST is applied
twice or something?



-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (91, 'testing'), (10, 'unstable'), (5, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 claws-mail-vcalendar-plugin depends on:
ii  claws-mail   3.17.3-2
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcurl3-gnutls  7.64.0-4+deb10u1
ii  libdb5.3 5.3.28+dfsg1-0.5
ii  libetpan20   1.9.3-2
ii  libexpat12.2.6-2+deb10u1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgnutls30  3.6.7-4+deb10u5
ii  libgtk2.0-0  2.24.32-3
ii  libical3 3.0.4-3
ii  liblockfile1 1.14-1.1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpangoft2-1.0-01.42.4-8~deb10u1
ii  libsasl2-2   2.1.27+dfsg-1+deb10u1

claws-mail-vcalendar-plugin recommends no packages.

claws-mail-vcalendar-plugin suggests no packages.

-- no debconf information

Bug#958929: git: Regression due to CVE-2020-11008 fix

2020-04-26 Thread Stefan Tauner 
Package: git
Version: 1:2.20.1-2+deb10u3
Severity: normal

Dear Maintainer,

the vulnerability in CVE-2020-11008 is related to the handling
of credential helpers in git. In Buster this has been fixed in
1:2.20.1-2+deb10u3. This broke my existing configuration where
repositories have credential.helper=store set. This is
documented in /usr/share/man/man1/git-credential-store.1.gz
and other files from git, git-doc etc.
I am unsure how to proceed... is this helper now unsupported?
Is this a simple regression that should be fixed?
Do other alternatives like git-credential-cache still work or
are they broken as well?



-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (91, 'testing'), (10, 'unstable'), (5, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 git depends on:
ii  git-man  1:2.20.1-2+deb10u3
ii  libc62.28-10
ii  libcurl3-gnutls  7.64.0-4+deb10u1
ii  liberror-perl0.17027-2
ii  libexpat12.2.6-2+deb10u1
ii  libpcre2-8-0 10.32-5
ii  perl 5.28.1-6
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages git recommends:
ii  ca-certificates  20190110
ii  less 487-0.1+b1
ii  openssh-client [ssh-client]  1:7.9p1-10+deb10u2
ii  patch2.7.6-3+deb10u1

Versions of packages git suggests:
ii  gettext-base  0.19.8.1-9
ii  git-cvs   1:2.20.1-2+deb10u3
pn  git-daemon-run | git-daemon-sysvinit  
ii  git-doc   1:2.20.1-2+deb10u3
pn  git-el
ii  git-email 1:2.20.1-2+deb10u3
pn  git-gui   
pn  git-mediawiki 
ii  git-svn   1:2.20.1-2+deb10u3
ii  gitk  1:2.20.1-2+deb10u3
pn  gitweb

-- no debconf information

Bug#940992: firefoxdriver: does not work with firefox > 47 at all

2020-04-25 Thread Stefan Tauner 
On Mon, 23 Sep 2019 12:56:48 +0200 Sascha Girrulat 
wrote:
> Hi,
> 
> the error below does not depend to firefox driver. The firefoxdriver ist
> a leftover for older firefox versions. The package documentation[3]
> describes how to enable the geckodriver and there is a bug[1] (#874207)
> filed for firefox too.
> 
> The packge firefoxdriver will be removed with the next update of
> python-selenium in a few days[2].
> 
> Regards
> Sascha
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874207
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939398
> [3] /usr/share/doc/python-selenium/README.Debian

Hi,

[3] is not installed by python3-selenium (nor an equivalent).
The respective NEWS.Debian.gz of python3-selenium refers to that
non-existent README.Debian though.

It basically suggests fetching the binary from
https://github.com/mozilla/geckodriver/releases and install it in a
directory in $PATH. I can confirm that this works on Debian Buster
(python3-selenium 3.14.1+dfsg1-1) with the latest geckodriver (v0.26.0
from 2019-10-12).

What's the purpose of this bug? If it shouldn't be closed, shouldn't it
depend on #874207?

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#573254: (no subject)

2020-01-07 Thread Stefan Tauner 
On Thu, 24 Oct 2019 00:45:50 -0500
Michael Lustfield  wrote:

> This was reported against 1.3.1, however 1.4.2 is available in oldstable. Can
> you confirm if this issue is still present? If so, would you also be able to
> also check against the latest git revision (many bug fixes are not released)?
> 

Hi,

I have checked with the one in Debian Buster (1.4.2-1) and Bullseye
(1.4.3-1). The same error is emitted for the du command. The code in
git as of now does not look like it has been changed either:
https://github.com/rsnapshot/rsnapshot/blob/3b3fc2c1676b5f93f33671dd07d6569ec95c4dd4/rsnapshot-program.pl#L1086

KR
-- 
Dipl.-Ing. Stefan Tauner
PhD Student @ https://ti.tuwien.ac.at/ecs/

Bug#947819: regression: iwlwifi hangs kernel completely sometimes

2019-12-30 Thread Stefan Tauner 
Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: important

Dear Maintainer,

my Intel Centrino 6205 in my Thinkpad T430 sometimes hangs the hole
system with Linux 4.19. I *think* it always related to the hardware
kill switch and reloading the driver afterwards, but I am not
completely sure since my "analysis" was done on several lock up
occasions over the period of a few months. I cannot reproduce it
effectively but it has incurred data loss thus I have set the elevated
importance in this bug report.

The reason why I tinker with the kill switch and/or the module at all
is that auto-reconnecting (with nm-manager) does not work consistently.
Both, the non-working reconnect and the lock ups, are a regression to
Debian 9 stretch where everything worked flawlessly.

I have attached some kernel log snippets that I was able to gather that
show some warnings related to iwlwifi but I am not 100% sure they are
actually related to the lock ups.

Since it's very hard to reproduce and it is quite annoying I will now switch to
Buster's backport kernel (5.3) and see if that helps.

KR



-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 root=/dev/mapper/vg-root ro quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Model information
sys_vendor: LENOVO
product_name: 2349PT4
product_version: ThinkPad T430
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: G1ETB7WW (2.77 )
board_vendor: LENOVO
board_name: 2349PT4
board_version: No DPK

** Loaded modules:
iwldvm
mac80211
iwlwifi
cfg80211
btrfs
zstd_compress
zstd_decompress
xxhash
ufs
qnx4
hfsplus
hfs
minix
vfat
msdos
fat
jfs
xfs
ctr
ccm
rfcomm
fuse
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
cmac
cpufreq_userspace
vboxdrv(OE)
cpufreq_conservative
cpufreq_powersave
bnep
binfmt_misc
btusb
btrtl
btbcm
btintel
uvcvideo
bluetooth
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
drbg
ansi_cprng
ecdh_generic
media
intel_rapl
msr
arc4
snd_hda_codec_hdmi
x86_pkg_temp_thermal
intel_powerclamp
coretemp
kvm_intel
mei_wdt
snd_hda_codec_realtek
snd_hda_codec_generic
kvm
snd_hda_intel
irqbypass
intel_cstate
snd_hda_codec
intel_uncore
snd_hda_core
snd_hwdep
intel_rapl_perf
pcspkr
serio_raw
wmi_bmof
sg
snd_pcm
iTCO_wdt
iTCO_vendor_support
thinkpad_acpi
snd_timer
nvram
tpm_tis
tpm_tis_core
snd
mei_me
tpm
mei
pcc_cpufreq
soundcore
rfkill
ac
battery
rng_core
evdev
parport_pc
ppdev
lp
parport
sunrpc
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
algif_skcipher
af_alg
dm_crypt
dm_mod
raid10
raid1
raid0
multipath
linear
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
md_mod
sd_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
i915
ahci
libahci
aesni_intel
libata
aes_x86_64
crypto_simd
cryptd
glue_helper
psmouse
scsi_mod
i2c_i801
sdhci_pci
xhci_pci
i2c_algo_bit
cqhci
xhci_hcd
drm_kms_helper
sdhci
lpc_ich
mmc_core
ehci_pci
ehci_hcd
drm
e1000e
usbcore
thermal
usb_common
wmi
video
button

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM
Controller [8086:0154] (rev 09)
Subsystem: Lenovo 3rd Gen Core processor DRAM Controller [17aa:21f3]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ivb_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Lenovo 3rd Gen Core processor Graphics Controller
[17aa:21f3]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo 7 Series/C210 Series Chipset Family USB xHCI Host
Controller (ThinkPad T430) [17aa:21f3]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216
Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Lenovo 7 Series/C216 Chipset Family MEI Controller
[17aa:21f3]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-

Bug#945782: python(3)-libtmux should depend on tmux package

2019-11-28 Thread Stefan Tauner 
Package: python-libtmux
Version: 0.8.0-1
Severity: normal

Hi,

when tmux is not installed one will encounter libtmux.exc.TmuxCommandNotFound
exceptions as soon as one tries to do anything useful with the package.
For example the following Python snipped provokes this behavior:

import libtmux
server = libtmux.Server()
session = server.new_session(session_name="test")

The same behavior can be observed with the Python 3 version.
My conclusion is that both versions of the package should
depend on tmux.

KR



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 
'stable'), (91, 'testing'), (10, 'unstable'), (5, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 python-libtmux depends on:
ii  python  2.7.16-1

python-libtmux recommends no packages.

python-libtmux suggests no packages.

-- no debconf information

Bug#909041: xorg: Xorg log filling up with (EE) modeset(0): Failed to get GBM bo for flip to new front.

2019-11-13 Thread Stefan Tauner 
Hi,

this is the upstream bug report:
https://gitlab.freedesktop.org/xorg/xserver/issues/68

There is some discussion about the implementation to be found here:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/131

The resulting patch has been merged:
https://gitlab.freedesktop.org/xorg/xserver/merge_requests/193

It would be nice to get this backported to stable IMHO since running
out of space on / (as just happened to me) is rather bad... ;)
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#942100: openssh-server: /etc/ssh/sshd_config unconditionally overwritten by update

2019-10-10 Thread Stefan Tauner 
Package: openssh-server
Version: 1:7.9p1-10+deb10u1
Severity: important

Hi,

this just bit me on current stable (Buster) while updating from the
security repo:

The following packages will be upgraded:
   openssh-client (1:7.9p1-10 => 1:7.9p1-10+deb10u1)
   openssh-server (1:7.9p1-10 => 1:7.9p1-10+deb10u1)
   openssh-sftp-server (1:7.9p1-10 => 1:7.9p1-10+deb10u1)
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1.178 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://security.debian.org/debian-security buster/updates/main amd64
openssh-sftp-server amd64 1:7.9p1-10+deb10u1 [44,6 kB]
Get:2 http://security.debian.org/debian-security buster/updates/main amd64
openssh-server amd64 1:7.9p1-10+deb10u1 [352 kB]
Get:3 http://security.debian.org/debian-security buster/updates/main amd64
openssh-client amd64 1:7.9p1-10+deb10u1 [782 kB]
Fetched 1.178 kB in 0s (4.945 kB/s)
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 498927 files and directories currently installed.)
Preparing to unpack .../openssh-sftp-server_1%3a7.9p1-10+deb10u1_amd64.deb ...
Unpacking openssh-sftp-server (1:7.9p1-10+deb10u1) over (1:7.9p1-10) ...
Preparing to unpack .../openssh-server_1%3a7.9p1-10+deb10u1_amd64.deb ...
Unpacking openssh-server (1:7.9p1-10+deb10u1) over (1:7.9p1-10) ...
Preparing to unpack .../openssh-client_1%3a7.9p1-10+deb10u1_amd64.deb ...
Unpacking openssh-client (1:7.9p1-10+deb10u1) over (1:7.9p1-10) ...
Setting up openssh-client (1:7.9p1-10+deb10u1) ...
Setting up openssh-sftp-server (1:7.9p1-10+deb10u1) ...
Setting up openssh-server (1:7.9p1-10+deb10u1) ...
Replacing config file /etc/ssh/sshd_config with new version
rescue-ssh.target is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u1) ...

The important line is the forth from the bottom.
Since I have changed the port of SSHD this makes it impossible to
open new connections afterwards. I can't believe that making computers
secure by essentially disconnecting their admins is the desired behavior
of this package (update). Arguably, changing the port back to its default
(as in my case) might even increase security risks. ;)
AFAIK there is no way to override the settings from the standard
config file (by files in a *.d directory as requested in other bug
reports). If there is no other (well-documented) workaround I strongly
consider this behavior a bug.



-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (91, 'testing'), (10, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 openssh-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  dpkg   1.19.7
ii  libaudit1  1:2.8.4-3
ii  libc6  2.28-10
ii  libcom-err21.44.5-1+deb10u2
ii  libgssapi-krb5-2   1.17-3
ii  libkrb5-3  1.17-3
ii  libpam-modules 1.3.1-5
ii  libpam-runtime 1.3.1-5
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1d-0+deb10u1
ii  libsystemd0241-7~deb10u1
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400
ii  openssh-client 1:7.9p1-10+deb10u1
ii  openssh-sftp-server1:7.9p1-10+deb10u1
ii  procps 2:3.3.15-2
ii  ucf3.0038+nmu1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  241-7~deb10u1
ii  ncurses-term 6.1+20181013-2+deb10u1
ii  xauth1:1.0.10-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  rssh  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded

Bug#725859: pdfchain: running the program fails with segmentation fault

2019-10-09 Thread Stefan Tauner 
Hi,

this is still a problem in Debian Buster (current stable(!), still
version 1:0.4.4.2-1). Launching it from the command line is enough to
trigger the segfault. I did not try the patch yet or compiling from
source and debugging. However, I found a workable (albeit slot)
workaround: running pdfchain in valgrind ;)

This bug has been open for a long time despite its severity. Is there
still an active maintainer or should we file an "orphaned" bug because
of that?

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#941911: g++: Broken -x/suffix handling leads to spurious -Wc++-compat warnings

2019-10-07 Thread Stefan Tauner 
Package: g++-8
Version: 8.3.0-6
Severity: normal

Dear Maintainer,

I noticed a bug in handling -Wc++-compat when (not) using the -x option.
Suppose you have two files containing valid C saved in files a.c and b.c,
for example, "int main(void) {}" in a.c and just a newline in b.c.

According to the documentation AFAICT you should be able to compile this
without errors in a single step by executing
g++ -Wc++-compat a.c b.c
since the correct language of the file should be determined automatically by
the suffix.

However, this leads to two times
cc1plus: warning: command line option ‘-Wc++-compat’ is valid for
C/ObjC but not for C++

One should be able to remove the warnings by forcing the language used to C
by prepending "-x c" as in
g++ -Wc++-compat -x c a.c b.c
since the manual states that -x  "applies to all following input files
until the next -x option".

However, this is not the case because only the first spurious warning is fixed
by this and ony adding another -x c just before the second file, i.e.,
g++ -Wc++-compat -x c a.c -x c b.c
works as expected without any warnings.

This problem is not depending on any arch specifics (tested with native g++
8.3.0
on amd64, and cross compilers for riscv64-linux-gnu, and arm-linux-gnueabihf).
A quick test with g++ 6.3.0-18+deb9u1 on amd64 revealed the same behavior.

I did not (and do not intend to but could if need be) report this upstream.

KR, Stefan



-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (91, 'testing'), (10, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 g++-8 depends on:
ii  gcc-88.3.0-6
ii  gcc-8-base   8.3.0-6
ii  libc62.28-10
ii  libgmp10 2:6.1.2+dfsg-4
ii  libisl19 0.20-2
ii  libmpc3  1.1.0-1
ii  libmpfr6 4.0.2-1
ii  libstdc++-8-dev  8.3.0-6
ii  zlib1g   1:1.2.11.dfsg-1

g++-8 recommends no packages.

Versions of packages g++-8 suggests:
pn  g++-8-multilib
ii  gcc-8-doc 8.3.0-1~bpo10+1
pn  libstdc++6-8-dbg  

-- no debconf information

Bug#918754: bash: $PATH in bash does not include /sbin and /usr/sbin

2019-09-23 Thread Stefan Tauner 
On Wed, 11 Sep 2019 14:18:32 + "Jakubith, Boris"
 wrote:

> I think this no _not_ a good idea. The semantics of 'su' is correct. The
> only error is that many users up to day count on the wrong behaviour. 
> […]
> 
> You can set 'ALWAYS_SET_PATH yes' for your installation, but generally - in
> a default install - this would be sooo wrong, especially because there many
> alternatives.

I can't argue with that, however I want to point out that the root
terminal (at least on Mate) as described in the Debian wiki[1] is
executed via "gksu /usr/bin/x-terminal-emulator"
that lacks the correct (PATH) environment too (I did an upgrade so maybe
this is a relic).
Changing the command to use gksudo instead sets up the right
directories AFAICT. This definitely looks like a bug to me. Can anybody
confirm the behavior (of launching a root terminal in a desktop
environment and not having the sbin directories in PATH) on a fresh
Gnome and/or Mate install? If this is deemed a bug shall we repurpose
this one or create a new one?

Sidenote: It is also no longer possible to launch X applications from
such a (root) terminal which used to work (can't remember if I had to
persuade it to do so with some configuration files though).

1: https://wiki.debian.org/Root
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#896063: gcc-default-ports: cross compiler for RISC-V 32bit

2019-01-10 Thread Stefan Tauner 
On Fri, 20 Apr 2018 10:22:05 +0200 Aurelien Jarno
 wrote:
> On 2018-04-20 12:40, Paul Wise wrote:
> > On Fri, Apr 20, 2018 at 12:05 PM, Karsten Merker wrote:
> > 
> > > I'm CCing the debian-riscv list in case somebody there should
> > > have further insights regarding riscv32 support in glibc.
> > 
> > I think Heinrich was looking for a bare-metal compiler for
> > microcontroller-class RISC-V rather than one for a hypothetical Debian
> > riscv32 port?
> 
> In that case gcc-default-ports is probably the wrong package. Someone
> has to package it as a different package similar to gcc-arm-none-eabi.

So this should actually be an RFP class bug?
Should this one be converted or closed and another one opened?

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#898516: cryptroot: verbosity of keyfile copy operation

2018-05-12 Thread Stefan Tauner 
Package: cryptsetup
Version: 2:2.0.2-1

Hi,

it took me quite some time to figure out how to set up my initrd to
include the correct key file. The documentation is actually quite clear
*when* one finds the correct bits (search engines find way too many
outdated tutorials instead unfortunately... due to
https://anonscm.debian.org/robots.txt).

One thing that could have saved me some time (and looking into the
actual source code of the cryptroot hook) would be a clear indication
when key files are copied like it is done for other operations in
initramfs scripts. I have expected something like
"Adding keyfile ${KEYFILE} as /cryptroot-keyfiles/${node}.key"
or similar when updating the initramfs using -v. I would have sent a
patch, however, I am not entirely sure how to add a message to
add_device() properly since it uses stdout/echo to return required
kernel modules. I guess the best would be to refactor the function and
use the generic copy_file() function of the hook-functions library
that prints a suitable message?

Also, since the name and destination directory of the key files are
chosen by the script and not influenced by the source name/user it might
be nice to document the (naming) scheme.

The problem exists since the code was added in r1044 (cf. bug #786578):
https://anonscm.debian.org/viewvc/pkg-cryptsetup/cryptsetup/trunk/debian/initramfs/cryptroot-hook?r1=1043=1044=1044;

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#850892: gcc should not warn about the assignment-allocation character 'm' when POSIX is enabled

2017-01-10 Thread Stefan Tauner 
On Wed, 11 Jan 2017 00:14:03 +0100
Matthias Klose <d...@debian.org> wrote:

> Please could you forward that upstream yourself?

Sure, upstream bug report is at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79055

KR
-- 
Dipl.-Ing. Stefan Tauner
Research and Development
Embedded Systems Department

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 6, 1200 Vienna, Austria
T: +43 1 333 40 77-316
E: stefan.tau...@technikum-wien.at
I: embsys.technikum-wien.at
I: www.technikum-wien.at

Bug#850892: gcc should not warn about the assignment-allocation character 'm' when POSIX is enabled

2017-01-10 Thread Stefan Tauner 
package: gcc
version: 4:6.2.1-1

Hi,

there was a previous bug report about the issue in question (#584511)
but it was closed and archived because it was targeting gcc-4.4 which
was removed from Debian (I tried to reopen it to no avail). However,
the problem persists in (probably) all versions including the gcc in
Ubuntu 16.04 and up to the one in Debian testing at the moment of this
writing (4:6.2.1-1). The allocation modifier in question is specified
here:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fscanf.html

Attached you can find an example program that shows the problem and
explains it in more detail.

-- 
Dipl.-Ing. Stefan Tauner
Research and Development
Embedded Systems Department

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 6, 1200 Vienna, Austria
T: +43 1 333 40 77-316
E: stefan.tau...@technikum-wien.at
I: embsys.technikum-wien.at
I: www.technikum-wien.at#include 
#include 

int main() {
char *s, *p, *c;
scanf("%ms %mc %m[a-z]", , , );
printf("s is %s, c is %c, p is %s\n", s, *c, p);
free(s);
free(c);
free(p);
}

/*

This produces...

scanfm.c: In function ‘main’:
scanfm.c:6:11: warning: ISO C does not support the 'm' scanf flag [-Wformat=]
 scanf("%ms %mc %m[a-z]", , , );
   ^
scanfm.c:6:11: warning: ISO C does not support the 'm' scanf flag [-Wformat=]
scanfm.c:6:11: warning: ISO C does not support the 'm' scanf flag [-Wformat=]

etc. when compiled with GCC even if _POSIX_C_SOURCE is set to 200809L, e.g.,

gcc -Wall -D_POSIX_C_SOURCE=200809L -pedantic -std=c99 scanfm.c -o scanfm

The 'm' allocation character is specified in POSIX 2008[1] and thus I think
gcc should not warn if _POSIX_C_SOURCE or _XOPEN_SOURCE are set appropriately.

1: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fscanf.html

*/

Bug#834957: flashrom: please make the build reproducible

2016-08-21 Thread Stefan Tauner 
On Sun, 21 Aug 2016 00:34:08 +0100
Chris Lamb <la...@debian.org> wrote:

> Source: flashrom
> Version: 0.9.9+r1954-1
> Severity: wishlist
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Hi,
> 
> Whilst working on the Reproducible Builds effort [0], I noticed
> that flashrom could not be built reproducibly.

Hi Chris,

if I read the specs right then the date formatting should not happen at
build time but at runtime to catch user locales.

"Formatting MUST be deferred until runtime if an end user should
observe the value in their own locale or timezone."

That would make your patch not fully complying.
I'll try to improve on that upstream for the next release. Thanks for
the pointer.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#766461: gitg: upload 3.14 to unstable

2016-05-29 Thread Stefan Tauner 
Hello Dmitry, gitg users!

I became aware of the complete rewrite and UI regressions only with the
update of my Ubuntu boxes. It's amazing how far away from my daily
needs this previously useful application has been pushed by the gnome
mindset (or whatever). I assume I am not the only one who cannot stand
the new interface... I deem the 3.x version a fork.
It feels like Gnome 2 -> 3 all over again - just smaller :(

Obviously I have not followed the development of gitg but I have been
using it for over 5 years almost daily (at work and home).
I do understand that the old 0.x branches wont be maintained by anybody
in the future and that 3.x is already lurking in experimental.
I am also quite aware that maintaining it with updated (gnome)
libraries etc. would require quite some effort - at least in the
beginning. I won't be able to dedicate enough time to do that on my own
(and probably lack some gtk/glib experience as well) but I am willing
to join any group working on this in case anybody is interested...
I could not find any existing public efforts in this regard.

Dmitry, I refrained from opening another bug report to spare you from
having to close it as non-sense... no idea how such things should be
handled properly due to their subjective nature so I just appended it to
the best matching existing bug to make the above public.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#399076: Upstream

2015-10-26 Thread Stefan Tauner 
tags 399076 upstream

This is still not fixed and contained in upstream Bash as well.
I have reported it upstream.

KR
-- 
Dipl.-Ing. Stefan Tauner
Research and Development
Embedded Systems Department

University of Applied Sciences Technikum Wien
Hoechstaedtplatz 6, 1200 Vienna, Austria
T: +43 1 333 40 77-316
E: stefan.tau...@technikum-wien.at
I: embsys.technikum-wien.at
I: www.technikum-wien.at

Bug#802342: flashrom: add arm64?

2015-10-19 Thread Stefan Tauner 
On Mon, 19 Oct 2015 18:38:53 +0100
Edmund Grimley Evans <edmund.grimley.ev...@gmail.com> wrote:

> Source: flashrom
> Version: 0.9.7+r1852-1.1
> Tags: patch
> 
> I have no idea whether this package is useful on arm64, but it's easy
> enough to build it with the attached trivial patch.

Hi,

I am the upstream maintainer. Yes, it is useful and we have added
support upstream for aarch64 (as well as PPC64) in r1864.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

Bug#775428: flashrom FTBFS on mipsel

2015-02-19 Thread Stefan Tauner 
Hi Uwe,

can you please trigger building the 0.9.8-rc1 candidate (before I
release the final in about a week)?

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner


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

Bug#775428: flashrom FTBFS on mipsel

2015-01-15 Thread Stefan Tauner 
On Thu, 15 Jan 2015 16:12:23 +
Dejan Latinovic dejan.latino...@imgtec.com wrote:

 Patch that conatins needed changes is attached.
 This chage is aviale upstream, along with other changes.
 With this patch I was able to build flashrom for mipsel locally.
 
 Could you please consider including these changes?
 
 
 Here is commit that conatins my fix.
 https://github.com/stefanct/flashrom/commit/138245ea51472211ec12e7b4d176591f3f18ce38
 If needed, we could use all chages from this commit.

Hello Dejan (and Hello Uwe too),

I am planning to release a new (upstream) flashrom stable release
(0.9.8) in the next weeks. This will include said patch as well as many
other changes committed since the last snapshot was taken for Debian.
It would probably make sense to merge that one to sid instead of
backporting anything...

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner


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

Bug#746734: flashrom: Please upgrade to 0.9.7 (+ patches)

2014-05-02 Thread Stefan Tauner 
Package: flashrom
Severity: wishlist

Dear Uwe,

flashrom 0.9.7 was released on 2013-08-14. Since then an additional
patch was pushed to the stable branch (r1752). We have tried to
reach you multiple times since then on IRC to get the package
updated but we got (almost?) no response. This report shall make
this request more official and also persistent and verifiable, so
that we can orphan the package later if need be.

I would prefer if you could continue maintaining flashrom, but not
updating without any rationale for such a long time is not really
acceptable for a software like flashrom that has to cope with
changes in hardware at a very low level.

Kind regards, Stefan Tauner


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

Bug#690478: (no subject)

2012-12-26 Thread Stefan Tauner 
Control: retitle -1 flashrom does not probe as expected with no options
Tags: upstream, upstream-fixed

 Hello, According to the docs/man page: 
 
 If no operation is specified, flashrom will only probe for flash chips. It 
 is recommended that if you try flashrom 
 the first time on a system, you run it in probe-only mode and check the 
 output.
 
 However when run with no options i get an error about no programmer parameter:
 …

Hello Douglas,

it does not say If no parameter is given, … but *operation*. I 
see your point though and I have added a hint regarding the -p option
to the paragraph in question (upstream, not to the Debian package).
It now reads:
You  can  specify  one  of -h, -R, -L, -z, -E, -r, -w, -v or no 
 operation.  If no operation is specified, flashrom will only probe for flash 
 chips. It is recommended
that if you try flashrom the first time on a system, you run it in 
 probe-only mode and check the output. Also you are advised to make a backup 
 of  your  current  ROM
contents  with  -r before you try to write a new image. All operations 
 involving any chip access (probe/read/write/...) require the -p/--programmer 
 option to be used
(please see below).

I hope this is in your interest.
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner


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

Bug#637028: dmidecode does falsely use bit 7 when decoding the chassis-type

2011-08-07 Thread Stefan Tauner 
Package: dmidecode

the bug is present in all vanilla versions since at least 2.9 and in
various Debian-based distributions (Ubuntu, grml). the attached patch
was also sent upstream (and to Ubuntu). for details please see the patch.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
From 888158fc7e0c7b9bc33281c2f80c5501f01b304e Mon Sep 17 00:00:00 2001
From: Stefan Tauner stefan.tau...@student.tuwien.ac.at
Date: Sun, 7 Aug 2011 20:24:44 +0200
Subject: [PATCH] Make dmi_chassis_type aware of the lock bit.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
To: dmidecode-de...@nongnu.org

Previously all bits of the parameter passed to dmi_chassis_type were
used to derive the chassis type although the 7th bit indicates a
lock and only bits 6:0 encode the chassis type (7.4 System Enclosure
or Chassis (Type 3), offset 05h). This is ok as long as the input is
masked as it was done in dmi_decode, but it was forgotten in
dmi_table_string, resulting in wrong output if there is a lock
present:
dmidecode -s chassis-type
OUT OF SPEC
although the normal output is correct:
[…]
Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
	Manufacturer: Chassis Manufacture
	Type: Desktop
	Lock: Present
	[…]

dump (the 5th byte (83) is the interesting one):
dmidecode -t chassis -u
SMBIOS 2.3 present.

Handle 0x0003, DMI type 3, 17 bytes
Header and Data:
03 11 03 00 01 83 02 03 04 03 03 03 03 01 00 00
00

Tested with current CVS code on a Laptop without a lock (by me)
and on the Desktop board dumped above (by Florian Zumbiehl, thanks!).
---
 dmidecode.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/dmidecode.c b/dmidecode.c
index f7b23c1..af2bfc5 100644
--- a/dmidecode.c
+++ b/dmidecode.c
@@ -532,6 +532,7 @@ static const char *dmi_chassis_type(u8 code)
 		Blade Enclosing /* 0x1D */
 	};
 
+	code = 0x7F; /* bits 6:0 are chassis type, 7th bit is the lock bit */
 	if (code = 0x01  code = 0x1D)
 		return type[code - 0x01];
 	return out_of_spec;
@@ -3237,7 +3238,7 @@ static void dmi_decode(const struct dmi_header *h, u16 ver)
 			printf(\tManufacturer: %s\n,
 dmi_string(h, data[0x04]));
 			printf(\tType: %s\n,
-dmi_chassis_type(data[0x05]  0x7F));
+dmi_chassis_type(data[0x05]));
 			printf(\tLock: %s\n,
 dmi_chassis_lock(data[0x05]  7));
 			printf(\tVersion: %s\n,
-- 
1.7.1

Bug#626119: New upstream version of avr-libc available (1.7.1)

2011-05-08 Thread Stefan Tauner 
Package: avr-libc
Version: 1:1.6.8-2: all

Hello Hakan (et al)!

please consider updating avr-libc. It is quite outdated (1.6.7 is 22
months old) and misses support for a lot of new models; see:
http://svn.savannah.nongnu.org/viewvc/tags/?root=avr-libc
and
http://www.nongnu.org/avr-libc/NEWS.txt

Thank you!
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner



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

Bug#573254: BTS#573254 rsnapshot shouldn't bail on absent backup points

2011-02-23 Thread Stefan Tauner 
hello

the problem is that rsnapshot does fear the unknown (line 1004 in
ubuntu's rsnapshot). below is the last else clause checking
different formats of the backup source inside the sub parse_config_file:

# fear the unknown
} else {
config_err($file_line_num, $line - Source directory \$src\
doesn't exist); next;
}

in some situations it should not fear, because it does not need (the
unknown) source directory:
- as mentioned by the op it should not fear if it is just rotating
- when invoking diff or du

this leads to situations where 'rsnapshot -c ... diff' with one config
file bails but using another config file, where the source exists (but
does not matter) _to diff directories of the same snapshot root_ works
flawlessly:

/data/backup/system# rsnapshot
-c /root/backup-scripts/settings/hostname/rsnapshot-root.conf diff
bootly.[01]

rsnapshot encountered an error! The program was invoked with these
options: /usr/bin/rsnapshot -c
\ /root/backup-scripts/settings/hostname/rsnapshot-root.conf diff
bootly.0 \ bootly.1

ERROR: /root/backup-scripts/settings/hostname/rsnapshot-root.conf on
line 223: ERROR: backup /mnt/root-snapshot root/ \
exclude=dev,exclude=tmp,exclude=lib/udev/,exclude=var/spool \
 - Source directory /mnt/root-snapshot doesn't exist 
ERROR:
-
ERROR: Errors were found
in /root/backup-scripts/settings/hostname/rsnapshot-root.conf, ERROR:
rsnapshot can not continue. If you think an entry looks right, make
ERROR: sure you don't have spaces where only tabs should be.


the second one uses the default config file (which i don't use
normally) with this backup points which all exist:
backup  /home/  localhost/
backup  /etc/   localhost/
backup  /usr/local/ localhost/

/data/backup/system# rsnapshot diff bootly.[01]
Comparing bootly.1 to bootly.0
Between bootly.1 and bootly.0:
  92 were added, taking 6362802 bytes;
  85 were removed, saving 6292118 


my perl skills are non-existent and i did not read a lot of
rsnapshot's code, but my general idea to fix this problem would be:
- define all cases where the source directory is not need
- set a global variable or argument of parse_config_file to indicate
  when this is the case
- skip the source directory check in parse_config_file according to
  this information

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner



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

Bug#611784: geteltorito in genisoimage doesn't extract hard drive images properly

2011-02-01 Thread Stefan Tauner 
Package: genisoimage
Source: cdrkit
Version: 9:1.1.11-1
Version: 9:1.1.10-1ubuntu3

geteltorito is outdated in Debian and Ubuntu. Please update.
I'm quoting the Ubuntu bug report[1] below:
geteltorito fails to extract hard drive images from el torito boot
cd's. The example I have currently is extracting Thinkpad BIOS update
images from the boot CDs available from Lenovo. This has been fixed in
a newer version of the geteltorito script.

The updated script can be found at
http://www.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/geteltorito

1: http://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/530530
-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner



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