from:"Eduard Bloch"

Bug#858168: New upstream version

2017-03-19 Thread Eduard Bloch

Package: terminator
Version: 1.91-1
Severity: serious
Tags: upstream patch

Hi,

Upstream released a new minor stable version weeks ago and it seems to
fix at least a couple of bugs reported here.

Setting serious severity because I consider #857562 and #852282 actually
RC (it breaks popular user features on XFCE and partly with IceWM and
probably others) and because the maintainer(s) are basically MIA.

Patch attached with NMU ultimatum, 10 days from now.

Best regards,
Eduard.

-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0+ (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages terminator depends on:
ii  gir1.2-glib-2.0   1.50.0-1+b1
ii  gir1.2-gtk-3.03.22.8-1
ii  gir1.2-pango-1.0  1.40.3-3
ii  gir1.2-vte-2.91   0.46.1-1
ii  python-cairo  1.8.8-2.1
ii  python-dbus   1.2.4-1
ii  python-gi 3.22.0-2
ii  python-gi-cairo   3.22.0-2
ii  python-psutil 5.0.1-1
pn  python:any

Versions of packages terminator recommends:
ii  gir1.2-keybinder-3.0  0.3.1-1
ii  gir1.2-notify-0.7 0.7.7-1+b1
ii  xdg-utils 1.1.1-1

terminator suggests no packages.

-- no debconf information

-- 
Trost gibt der Himmel, von den Menschen erwartet man Beistand.
-- Ludwig Börne
Index: debian/changelog
===
--- debian/changelog	(Revision 13918)
+++ debian/changelog	(Arbeitskopie)
@@ -1,3 +1,14 @@
+terminator (1.91-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream version
++ opening in folder works with thunar (closes: #857562)
++ crazy new window handling fixed (closes: #852282, LP: #1646437)
+  * dropped Debian patches applied upstream (add-keywords-entry.diff,
+gi-require-exception.diff, subwindows-zero-size.patch)
+
+ -- Eduard Bloch   Sun, 19 Mar 2017 11:12:18 +0100
+
 terminator (1.90+bzr-1705-1) unstable; urgency=medium
 
   * New upstream snapshot.
Index: debian/patches/add-keywords-entry.diff
===
--- debian/patches/add-keywords-entry.diff	(Revision 13918)
+++ debian/patches/add-keywords-entry.diff	(nicht existent)
@@ -1,16 +0,0 @@
-Description: Add Keywords entry to the desktop file.
-Forwarded: https://bugs.launchpad.net/bugs/1241052
-Author: Julián Moreno Patiño 
-Last-Update: 2013-10-17
 a/data/terminator.desktop.in
-+++ b/data/terminator.desktop.in
-@@ -9,8 +9,8 @@
- StartupNotify=true
- X-Ubuntu-Gettext-Domain=terminator
- X-Ayatana-Desktop-Shortcuts=NewWindow;
-+Keywords=terminal;shell;prompt;command;commandline;
- [NewWindow Shortcut Group]
- Name=Open a New Window
- Exec=terminator
- TargetEnvironment=Unity
--
Index: debian/patches/gi-require-exception.diff
===
--- debian/patches/gi-require-exception.diff	(Revision 13918)
+++ debian/patches/gi-require-exception.diff	(nicht existent)
@@ -1,28 +0,0 @@
-Author: Emilio Pozuelo Monfort 
-Bug: https://bugs.launchpad.net/terminator/+bug/1574399
-Description: catch all exceptions
-
-As gi.require_version throws ValueErrors
-
 a/terminatorlib/window.py
-+++ b/terminatorlib/window.py
-@@ -23,7 +23,7 @@
- gi.require_version('Keybinder', '3.0')
- from gi.repository import Keybinder
- Keybinder.init()
--except ImportError:
-+except:
- err('Warning: python-keybinder is not installed. This means the \
- hide_window shortcut will be unavailable')
- 
 a/terminatorlib/plugins/activitywatch.py
-+++ b/terminatorlib/plugins/activitywatch.py
-@@ -21,7 +21,7 @@
- # This is inside this try so we only make the plugin available if pynotify
- #  is present on this computer.
- AVAILABLE = ['ActivityWatch', 'InactivityWatch']
--except ImportError:
-+except:
- err(_('ActivityWatch plugin unavailable: please install python-notify'))
- 
- config = Config()
Index: debian/patches/series
===
--- debian/patches/series	(Revision 13918)
+++ debian/patches/series	(Arbeitskopie)
@@ -1,4 +1 @@
 not-install-terminator-wrapper.diff
-add-keywords-entry.diff
-gi-require-exception.diff
-subwindows-zero-size.patch
Index: debian/patches/subwindows-zero-size.patch
===
--- debian/patches/subwindows-zero-size.patch	(Revision 13918)
+++ debian/patches/subwindows-zero-size.patch	(nicht existent)
@@ -1,38 +0,0 @@
-From: Emilio Pozuelo Monfort 
-
-https://bugs.launchpad.net/terminator/+bug/1646257
-
-=== m

Bug#921450: fetchmail: Fetchmail segfaults upon execution

2019-02-05 Thread Eduard Bloch

On Tue, 5 Feb 2019 19:22:21 +0100 
=?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?=  wrote:
> Control: tags -1 +unreproducible moreinfo
> 
> Hi James,
> 
> On Tue, Feb 5, 2019 at 6:09 PM James Henried  wrote:
> > fetchmail has stopped working in version 6.4.0~beta4-2.
>  Which previous version did you use?
> 
> > Running the daemon gets the first mail in the queue delivered, but then it 
> > segfaults.
>  Please install fetchmail-dbgsym if it may give more information.
> 
> What happens if you stop the daemon and run it from the command line?
> What's the output if it still fails?
> Are you open to provide detailed log like the following produces?
> $ env LC_ALL=C fetchmail -v -v -v  --nodetach --nosyslog -b 2

I can reproduce it well if it's the same problem.
Here is your stack information, with minimal anonymization.

For me it's not crashing ASAP, it skips two messages with "bad header"
status and crashes upon encountering the first good message.

(gdb) bt
#0  pop3_delete (sock=, ctl=0x555b4db0, number=3) at 
pop3.c:1362
#1  0x555669b0 in fetch_messages (msgsizes=0x5559f480 , 
transient_errors=, 
deletions=, dispatches=, 
fetches=, maxfetch=1000, 
count=, ctl=0x555b4db0, mailserver_socket=3) at 
driver.c:812
#2  do_session (ctl=ctl@entry=0x555b4db0, proto=proto@entry=0x5559a200 
, maxfetch=maxfetch@entry=1000)
at driver.c:1435
#3  0x55567df9 in do_protocol (ctl=0x555b4db0, proto=0x5559a200 
) at driver.c:1677
#4  0xfb48 in query_host (ctl=0x555b4db0) at fetchmail.c:1546
#5  0xa37b in main (argc=, argv=0x7fffe5d8) at 
fetchmail.c:793
(gdb) display ctl
1: ctl = (struct query *) 0x555b4db0
(gdb) display *ctl
2: *ctl = {server = {pollname = 0x555b4cf0 "MYSERVER", via = 0x0, akalist = 
0x0, localdomains = 0x0, protocol = 3, 
service = 0x0, interval = 0, authenticate = 1, timeout = 300, envelope = 
0x0, envskip = 0, qvirtual = 0x0, 
skip = 0 '\000', dns = 1 '\001', uidl = 0 '\000', sdps = 0 '\000', 
checkalias = 0 '\000', tracepolls = 0 '\000', 
principal = 0x0, esmtp_name = 0x0, esmtp_password = 0x0, badheader = 
BHREJECT, interface = 0x0, monitor = 0x0, 
monitor_io = 0, interface_pair = 0x0, plugin = 0x0, plugout = 0x0, 
base_protocol = 0x5559a200 , poll_count = 0, 
queryname = 0x555b3f90 "MYSERVER", truename = 0x555b4020 
"MYSERVER", trueaddr = 0x555fcf50, 
trueaddr_len = 16, lead_server = 0x0, esmtp_options = 3, workarounds = 0}, 
localnames = 0x555b4d50, wildcard = 0, 
  remotename = 0x555b4cd0 "ANON", password = 0x555b4d10 "ANON", 
mailboxes = 0x555b4080, 
  smtphunt = 0x555b4060, domainlist = 0x0, smtpaddress = 0x0, smtpname = 
0x0, antispam = 0x555b4d90, mda = 0x0, 
  bsmtp = 0x0, listener = 83 'S', preconnect = 0x0, postconnect = 0x0, keep = 0 
'\000', fetchall = 1 '\001', flush = 0 '\000', 
  limitflush = 0 '\000', rewrite = 1 '\001', stripcr = 0 '\000', forcecr = 0 
'\000', pass8bits = 0 '\000', 
  dropstatus = 0 '\000', dropdelivered = 0 '\000', mimedecode = 0 '\000', idle 
= 0 '\000', limit = 0, warnings = 3600, 
  fetchlimit = 0, fetchsizelimit = 100, fastuidl = 4, fastuidlcount = 0, 
batchlimit = 70, expunge = 1000, use_ssl = 1 '\001', 
  sslkey = 0x0, sslcert = 0x0, sslproto = 0x0, sslcertfile = 0x0, sslcertpath = 
0x0, sslcertck = 1 '\001', 
  sslcommonname = 0x0, sslfingerprint = 0x0, properties = 0x0, active = 1 
'\001', destaddr = 0x5564c7e0 "localhost", 
  errcount = 0, authfailcount = 0, wehaveauthed = 1, wehavesentauthnote = 0, 
wedged = 0, 
  smtphost = 0x555b4040 "localhost", smtphostmode = 83 'S', smtp_socket = 
4, uid = 103, skipped = 0x0, oldsaved = {
pat_root = 0x555b41c0, records = 0x555dbd00, records_max = 2048, 
records_next = 1888, num_ndx = {records = 0x0, 
  pos_0_value = 4294967295, end_value = 4294967295}}, newsaved = {pat_root 
= 0x0, records = 0x555b4130, 
records_max = 16, records_next = 0, num_ndx = {records = 0x0, pos_0_value = 
4294967295, end_value = 4294967295}}, 
  lastdigest = '\000' , folder = 0x0, mimemsg = 1, digest = 
'\000' , next = 0x0}

Valgrind confirms:

==4368== Invalid write of size 4
==4368==at 0x10DDDA: pop3_delete (pop3.c:1374)
==4368==by 0x10DDDA: pop3_delete.cold.13 (pop3.c:1362)
==4368==by 0x11A9AF: fetch_messages (driver.c:812)
==4368==by 0x11A9AF: do_session (driver.c:1435)
==4368==by 0x11BDF8: do_protocol (driver.c:1677)
==4368==by 0x113B47: query_host (fetchmail.c:1546)
==4368==by 0x10E37A: main (fetchmail.c:793)
==4368==  Address 0x14 is not stack'd, malloc'd or (recently) free'd
==4368== 
==4368== 
==4368== Process terminating with default action of signal 11 (SIGSEGV)
==4368==  Access not within mapped region at address 0x14
==4368==at 0x10DDDA: pop3_delete (pop3.c:1374)
==4368==by 0x10DDDA: pop3_delete.cold.13 (pop3.c:1362)
==4368==by 0x11A9AF: fetch_messages (driver.c:812)
==4368==by 0x11A9AF: do_sessi

Bug#796601: encfs: password gets modified in keystore after umount

2015-08-23 Thread Eduard Bloch

Control: tag 796601 +notreproducible
Control: severity 796601 important

> When using encfs to scramble a backup to an alternate media, the password gets
> modified somehow during umount.Any further attempts to mount the media fail,
> even if the password is correct.

Cannot reproduce. Please show a sample .encfs6.xml and matching password
or we cannot do much for you.

> I copy the password from keepass to a text file, then copy the password to the

There is no keepass package in Debian. Do you mean keepassx or keepass2?

> terminal.You cannot directly copy from keepass to the terminal due to its
> "secure storage and wiping"  feature with the clipboard. The password has not
> been changed by me since initial creation of the encfs storage.

After using a terminal... seriously? Terminals hide a lot of "invisible"
but effective characters.

Regards,
Eduard.

Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i965_dri.so

2023-01-01 Thread Eduard Bloch

Am Sun, Jan 01, 2023 at 11:02:08PM +0100 schrieb Eduard Bloch:
> reopen 1025389
> severity 1025389 serious
> thanks
> 
> Am Sun, Jan 01, 2023 at 02:29:01PM +0100 schrieb Fabio Pedretti:
> > Version: 22.3.0-3
> > 
> > 22.3.0-3 reenabled two intel drivers missing in previou release.
> 
> Why the heck are you closing this when the very specific issue in the
> subject is not resolved?

And the fun goes on. After some websearch, I found:
https://www.phoronix.com/review/ivy-bridge-crocus

So was THAT supposed to replace i965 support in mesa-22?

Well, then it simply DOES NOT WORK. Yes, I found that crocus lib. But:

MESA_LOADER_DRIVER_OVERRIDE=crocus strace -f -o wtf.log vlc ...
$ grep crocus wtf.log 
21999 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
21999 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/crocus_dri.so", 
O_RDONLY|O_CLOEXEC) = 23
21999 write(2, "failed to load driver: crocus\n", 30) = 30
22019 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
22019 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/crocus_dri.so", 
O_RDONLY|O_CLOEXEC) = 28
22019 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
22011 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/dri/tls/crocus_dri.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
22011 write(2, "failed to load driver: crocus\n", 30) = 30

So, and now? Is that internal implementation change something which was
supposed to be communicated to users? If yes, where are the docs?
If not, why is this not at least sufficiently transparent to developers,
and made easy to debug?

In any case, it seems to be broken as of now.

Bug#1025389: libgl1-mesa-dri: AIGLX error: dlopen of /usr/lib/x86_64-linux-gnu/dri/i965_dri.so

2023-01-02 Thread Eduard Bloch

severity 1025389 normal
thanks

Hallo,
* Fabio Pedretti [Mon, Jan 02 2023, 10:10:24AM]:
> Hi, i965 driver was removed, and replaced by iris, crocus and (gallium
> version of) i915.
>
> Did you have any reference to i965 in your configuration?
>
> cd /etc/ && grep -ri i965
>
> If so try to remove them, the system should be able to pick up the
> proper driver.

Okay, the devil is in the details. Multiple issues were involved. First,
I had a custom config snippet in xorg.conf.d which has activated the
intel drivers. I had to add this in earlier times in order to get rid of
tearing.

Another part in the puzzle was an environment setting which I have added
some time ago to work around crashes (first VLC crashes, then all
applications crashes in the major driver loader fu*up a few weeks ago).
So it seems like it was the MESA_LOADER_DRIVER_OVERRIDE=i965 which
actually triggered the Xorg.0.log messages which I have mistakenly
attributed to the incorrect X configuration itself.

So after changing all that, it's now apparently loading the proper
driver (iris in the log), with no errors, and most GL using applications
also work properly. VLC is still crashing on certain video formats but
that is probably due to some internal bug of VLC's vaapi usage (there is
another bugreport for that). But mplayer works mostly fine, except for
some gamma problems.

So in the end, it would be good if there was at least some notice about
the driver configuration change, something in NEWS.Debian, for example.
Maybe with a longer explanation in README.Debian. I can imagine that
more users with customized configurations are affected like I was.

Best regards,
Eduard.

Bug#933001: returns 1 to plymouth initramfs hook, breaks initramfs creation

2019-07-25 Thread Eduard Bloch

Package: fontconfig
Version: 2.13.1-2
Severity: grave

After recent upgrades, initramfs update fails here. When I patch
/usr/share/initramfs-tools/hooks/plymouth with "set -x", this is what we
get. And this error handling = NOT helpfull.

+ '[' n = y ']'
+ cp -pP /usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1 
/var/tmp/mkinitramfs_n38cu7//usr/lib/x86_64-linux-gnu/libbsd.so.0.9.1
+ cp -a /usr/share/plymouth/themes/details 
/var/tmp/mkinitramfs_n38cu7//usr/share/plymouth/themes
+ cp -a /usr/share/plymouth/themes/text 
/var/tmp/mkinitramfs_n38cu7//usr/share/plymouth/themes
+ '[' -f /etc/os-release ']'
+ cp /etc/os-release /var/tmp/mkinitramfs_n38cu7/etc
+ case "${THEME_NAME}" in
+ cp /usr/share/plymouth/debian-logo.png 
/var/tmp/mkinitramfs_n38cu7/usr/share/plymouth
+ mkdir -p /var/tmp/mkinitramfs_n38cu7/etc/fonts/conf.d
+ cp -a /etc/fonts/fonts.conf /var/tmp/mkinitramfs_n38cu7/etc/fonts
+ cp -rL /etc/fonts/conf.d/60-latin.conf 
/var/tmp/mkinitramfs_n38cu7/etc/fonts/conf.d
+ mkdir -p /var/tmp/mkinitramfs_n38cu7/var/cache/fontconfig
+ mkdir -p /var/tmp/mkinitramfs_n38cu7/usr/local/share/fonts
+ '[' -e /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf ']'
+ mkdir -p /var/tmp/mkinitramfs_n38cu7/usr/share/fonts/truetype/dejavu
+ cp -a /usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf 
/var/tmp/mkinitramfs_n38cu7/usr/share/fonts/truetype/dejavu
+ cp -a /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf 
/var/tmp/mkinitramfs_n38cu7/usr/share/fonts/truetype/dejavu
+ fc-cache -s -y /var/tmp/mkinitramfs_n38cu7
E: /usr/share/initramfs-tools/hooks/plymouth failed with return 1.
update-initramfs: failed for /boot/initrd.img-5.2.2+ with 1.

Ok, trying more verbosity, still does not work. I expect
"--really-force" to fix everything, but it doesn't.

+ fc-cache --verbose --really-force -s -y /var/tmp/mkinitramfs_OYu7kU
[/var/tmp/mkinitramfs_OYu7kU]/usr/share/fonts: caching, new cache contents: 0 
fonts, 1 dirs
[/var/tmp/mkinitramfs_OYu7kU]/usr/share/fonts/truetype: caching, new cache 
contents: 0 fonts, 1 dirs
[/var/tmp/mkinitramfs_OYu7kU]/usr/share/fonts/truetype/dejavu: caching, new 
cache contents: 2 fonts, 0 dirs
[/var/tmp/mkinitramfs_OYu7kU]/usr/X11R6/lib/X11/fonts: 
"/usr/X11R6/lib/X11/fonts": scanning error
[/var/tmp/mkinitramfs_OYu7kU]/usr/local/share/fonts: caching, new cache 
contents: 0 fonts, 0 dirs
[/var/tmp/mkinitramfs_OYu7kU]/usr/share/fonts/truetype: skipping, looped 
directory detected
[/var/tmp/mkinitramfs_OYu7kU]/usr/share/fonts/truetype/dejavu: skipping, looped 
directory detected
/var/tmp/mkinitramfs_OYu7kU//var/cache/fontconfig: cleaning cache directory
fc-cache: failed

And now? The used font does exist!

$ debsums fonts-dejavu-core
/usr/share/doc/fonts-dejavu-core/AUTHORS  OK
/usr/share/doc/fonts-dejavu-core/BUGS OK
/usr/share/doc/fonts-dejavu-core/README.mdOK
/usr/share/doc/fonts-dejavu-core/changelog.Debian.gz  OK
/usr/share/doc/fonts-dejavu-core/changelog.gz OK
/usr/share/doc/fonts-dejavu-core/copyrightOK
/usr/share/doc/fonts-dejavu-core/langcover.txt.gz OK
/usr/share/doc/fonts-dejavu-core/status.txt.gzOK
/usr/share/doc/fonts-dejavu-core/unicover.txt.gz  OK
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf  OK
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf   OK
/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf  OK
/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf   OK
/usr/share/fonts/truetype/dejavu/DejaVuSerif-Bold.ttf OK
/usr/share/fonts/truetype/dejavu/DejaVuSerif.ttf  OK

EOF

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0+ (SMP w/12 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fontconfig depends on:
ii  fontconfig-config  2.13.1-2
ii  libc6  2.28-10
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-4

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information

--
 Im Amazon find ich nur englische Thesauren, das ist ja krank
 Thesaurüsse?
 Ah! Thesauri.
 Thesaurier?

Bug#933001: Acknowledgement (returns 1 to plymouth initramfs hook, breaks initramfs creation)

2019-07-25 Thread Eduard Bloch

Hallo,
* Debian Bug Tracking System [Thu, Jul 25 2019, 05:24:04PM]:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 933001: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933001.

Ok, I grepped around for the last occurrence of the path
/usr/X11R6/lib/X11/fonts and I found it in /etc/fonts/fonts.conf .
And removing this XML node manually does fix the problem.
So my question it, why is fontconfig-config adding this to fonts.conf
when fc-cache fails on that path?

FYI:

$ find /usr/X11R6/lib/X11/fonts/
/usr/X11R6/lib/X11/fonts/
/usr/X11R6/lib/X11/fonts/75dpi
/usr/X11R6/lib/X11/fonts/75dpi/fonts.alias
/usr/X11R6/lib/X11/fonts/75dpi/.uuid
/usr/X11R6/lib/X11/fonts/misc
/usr/X11R6/lib/X11/fonts/misc/fonts.alias
/usr/X11R6/lib/X11/fonts/misc/.uuid
/usr/X11R6/lib/X11/fonts/cyrillic
/usr/X11R6/lib/X11/fonts/cyrillic/fonts.alias
/usr/X11R6/lib/X11/fonts/cyrillic/.uuid
/usr/X11R6/lib/X11/fonts/.uuid
/usr/X11R6/lib/X11/fonts/100dpi
/usr/X11R6/lib/X11/fonts/100dpi/fonts.alias
/usr/X11R6/lib/X11/fonts/100dpi/.uuid

Best Regards, Eduard.

Bug#989193: breaks apt-cacher-ng by blocking link operation

2021-05-27 Thread Eduard Bloch

Package: apparmor-profiles-extra
Version: 1.33
Severity: serious
Tags: patch

Hi,

see attachment, your config which doesn't allow link calls, which
sporadically breaks operation of apt-cacher-ng in unexpected ways.

The suggested change should probably be improved, I am no apparmor
expert.


[ 1451.927739] audit: type=1400 audit(1622048089.493:85): apparmor="ALLOWED" 
operation="link" profile="apt-cacher-ng" 
name="/var/cache/apt-cacher-ng/debrep/dists/unstable/InRelease.1622048089" 
pid=36785 comm="apt-cacher-ng" requested_mask="l" denied_mask="l" fsuid=121 
ouid=121 target="/var/cache/apt-cacher-ng/debrep/dists/unstable/InRelease"


Eduard.

-- System Information:
Debian Release: 11.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.12.0+ (SMP w/12 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apparmor-profiles-extra depends on:
ii  apparmor  2.13.6-10

apparmor-profiles-extra recommends no packages.

apparmor-profiles-extra suggests no packages.

-- Configuration Files:
/etc/apparmor.d/usr.sbin.apt-cacher-ng changed:
@{APT_CACHER_NG_CACHE_DIR}=/var/cache/apt-cacher-ng
profile apt-cacher-ng /usr/sbin/apt-cacher-ng {
  #include 
  #include 
  #include 
  #include 
  /etc/apt-cacher-ng/ r,
  /etc/apt-cacher-ng/** r,
  /etc/hosts.{deny,allow} r,
  /usr/sbin/apt-cacher-ng mr,
  /var/lib/apt-cacher-ng/** r,
  /{,var/}run/apt-cacher-ng/* rw,
  @{APT_CACHER_NG_CACHE_DIR}/ r,
  @{APT_CACHER_NG_CACHE_DIR}/** rwl,
  /var/log/apt-cacher-ng/ r,
  /var/log/apt-cacher-ng/* rw,
  /{,var/}run/systemd/notify w,
  /{usr/,}bin/dash ixr,
  /{usr/,}bin/ed ixr,
  /{usr/,}bin/red ixr,
  /{usr/,}bin/sed ixr,
  /usr/lib/apt-cacher-ng/acngtool ixr,
  # Allow serving local documentation
  /etc/mime.types r,
  /usr/share/doc/apt-cacher-ng/html/** r,
  # used by libevent
  @{PROC}/sys/kernel/random/uuid r,
  # Site-specific additions and overrides. See local/README for details.
  #include 
}


-- no debconf information

From 5eeca40ec3c93dc0d91ce3db0d9f652310087a12 Mon Sep 17 00:00:00 2001
From: Eduard Bloch 
Date: Fri, 28 May 2021 07:11:52 +0200
Subject: [PATCH] Stop breaking latest apt-cacher-ng by blocking link
 operations

---
 profiles/usr.sbin.apt-cacher-ng | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/profiles/usr.sbin.apt-cacher-ng b/profiles/usr.sbin.apt-cacher-ng
index 6d2f5ff..c24c2c5 100644
--- a/profiles/usr.sbin.apt-cacher-ng
+++ b/profiles/usr.sbin.apt-cacher-ng
@@ -18,7 +18,7 @@ profile apt-cacher-ng /usr/sbin/apt-cacher-ng {
   /var/lib/apt-cacher-ng/** r,
   /{,var/}run/apt-cacher-ng/* rw,
   @{APT_CACHER_NG_CACHE_DIR}/ r,
-  @{APT_CACHER_NG_CACHE_DIR}/** rw,
+  @{APT_CACHER_NG_CACHE_DIR}/** rwl,
   /var/log/apt-cacher-ng/ r,
   /var/log/apt-cacher-ng/* rw,
   /{,var/}run/systemd/notify w,
--
2.32.0.rc0

Bug#959675: libgrpc++1: endless looping with default settings

2020-05-03 Thread Eduard Bloch

Package: libgrpc++1
Version: 1.26.0-3
Severity: serious

Dear Maintainer,

   * What led up to the situation?

Tried to setup a basic POC using gRPC. Used the example source code for
Cpp from this source package, and dev package and protoc from regular
Debian Sid.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Compiled the cpp/hellworld examples and tried to run them.

   * What was the outcome of this action?

Nothing works. All sample programs get stuck in the beginning before
opening or connecting TCP ports and inf-loop on a CPU core.

Backtrace check indicates that this is a variant of
https://github.com/grpc/grpc/issues/21280 .

(gdb) bt
#0  0x77c198e0 in grpc_core::TraceFlagList::Set(char const*, bool) () 
from /usr/lib/x86_64-linux-gnu/libgrpc++.so.1
#1  0x77c19a0e in grpc_tracer_init() () from 
/usr/lib/x86_64-linux-gnu/libgrpc++.so.1
#2  0x77535401 in grpc_init () from 
/usr/lib/x86_64-linux-gnu/libgrpc.so.9
#3  0x55564988 in grpc::GrpcLibraryCodegen::GrpcLibraryCodegen(bool) ()
#4  0x77b97aee in grpc_impl::ServerBuilder::BuildAndStart() () from 
/usr/lib/x86_64-linux-gnu/libgrpc++.so.1
#5  0x55575c13 in RunServer() ()
#6  0x55575d3f in main ()

   * What outcome did you expect instead?

Bugs like this never to arrive in Debian and not remain there for months.
The Sid version is 3 months behind upstream.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgrpc++1 depends on:
ii  libc6  2.30-4
ii  libgcc-s1  10-20200418-1
ii  libgrpc9   1.26.0-3
ii  libprotobuf22  3.11.4-4
ii  libstdc++6 10-20200418-1
ii  zlib1g 1:1.2.11.dfsg-2

libgrpc++1 recommends no packages.

libgrpc++1 suggests no packages.

-- no debconf information

Bug#979562: lightdm session termination does not stop xscreensaver

2021-01-08 Thread Eduard Bloch

Hallo,

I don't fully agree. If you don't see a problem here, WHERE do you see
it?

Under my naive assumptions, it looks like SIGTERM is not sent when
lightdm stops the service. So apparently a systemd issue.

I would like to investigate more but a there seems to be no "debug" or
"trace" mode for such kind of issues in systemd. Mind to share your
knowledge?

* Michael Biebl [Fri, Jan 08 2021, 01:34:43PM]:
> Control: reassign -1 xscreensaver
> 
> I don't see a systemd problem here, so re-assigning to xscreensaver.
> 
> Am 08.01.21 um 13:04 schrieb Eduard Bloch:
> > Package: systemd
> > Version: 247.2-4
> > Severity: serious
> > 
> > Hi,
> > 
> > I am reporting this with high severity because it might affect system
> > security.
> > 
> > For details of this issue, see 978589. There are different symptoms to
> > see but the originating cause is apparently the same:
> > 
> >   - xscreensaver user service is enabled as documented in its README
> >   - lightdm starts the service in its internal user session (owned by
> > "lightdm" user)
> >   - lightdm stops its session when the login happens. However,
> > xscreensaver process is NOT terminated for unknown reason.
> >   - having this xscreensaver hanging around disturbs the startup of
> > another xscreensaver process in the new user session
> >   - after ~15s the old xscreensaver process (from lightdm) is finally
> > dead, apparently a SIGTERM is emited only then!
> > 
> > Visible symptoms:
> > 
> > In the meantime, someone might lock the system (by xscreensaver-command)
> > and go away, assuming that xscreensaver is locked. And then it suddenly
> > dies.
> > 
> > Same things happens if xscreensaver is invoked from .xsession or similar
> > contents instead of user service.
> > 
> > Best regards,
> > Eduard.
> > 
> > -- Package-specific info:
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >APT prefers unstable-debug
> >APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
> > (1, 'experimental-debug'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 5.10.5+ (SMP w/12 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE
> > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
> > not set
> > Shell: /bin/sh linked to /bin/bash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages systemd depends on:
> > ii  adduser  3.118
> > ii  libacl1  2.2.53-9
> > ii  libapparmor1 2.13.6-3
> > ii  libaudit11:3.0-2
> > ii  libblkid12.36.1-4
> > ii  libc62.31-9
> > ii  libcap2  1:2.44-1
> > ii  libcrypt11:4.4.17-1
> > ii  libcryptsetup12  2:2.3.4-1
> > ii  libgcrypt20  1.8.7-2
> > ii  libgnutls30  3.7.0-5
> > ii  libgpg-error01.38-2
> > ii  libip4tc21.8.6-1
> > ii  libkmod2 28-1
> > ii  liblz4-1 1.9.3-1
> > ii  liblzma5 5.2.5-1.0
> > ii  libmount12.36.1-4
> > ii  libpam0g 1.4.0-2
> > ii  libseccomp2  2.5.1-1
> > ii  libselinux1  3.1-2+b2
> > ii  libsystemd0  247.2-4
> > ii  libzstd1 1.4.8+dfsg-1
> > ii  mount2.36.1-4
> > ii  systemd-timesyncd [time-daemon]  247.2-4
> > ii  util-linux   2.36.1-4
> > 
> > Versions of packages systemd recommends:
> > ii  dbus  1.12.20-1
> > 
> > Versions of packages systemd suggests:
> > ii  policykit-10.105-29
> > pn  systemd-container  
> > 
> > Versions of packages systemd is related to:
> > pn  dracut   
> > ih  initramfs-tools  0.139
> > ii  libnss-systemd   247.2-4
> > ii  libpam-systemd   247.2-4
> > ii  udev 247.2-4
> > 
> > -- no debconf information
> > 
> > --
> > Chirurgen sind die einzigen Menschen, die ohne fremden Blinddarm und
> > ohne fremde Mandeln nicht leben können.
> > -- Peter Sellers
> > 
> 
> 


Best regards,
Eduard.


signature.asc
Description: PGP signature

Bug#979562: lightdm session termination does not stop xscreensaver

2021-01-11 Thread Eduard Bloch

Hallo,
* Michael Biebl [Sun, Jan 10 2021, 08:24:12PM]:
> Am 10.01.21 um 20:02 schrieb Jamie Zawinski:
> > > Why would a xscreensaver instance running for user A have any influence 
> > > on a xscreensaver instance running for user B? That seems absolutely 
> > > weird to me and something I don't understand.
> >
> > Yeah, that sounds impossible, assuming that the X server has restarted 
> > between user A and user B.
> >
> > If things have gone wrong in a weird way, the "xscreensaver-systemd" 
> > process of user A might linger, but it won't be able to communicate with 
> > user B's xscreensaver.
>
> Since Eduard has been claiming this originally:
>
> >  - having this xscreensaver hanging around disturbs the startup of
> >another xscreensaver process in the new user session
>
> I guess he needs to back this up somehow.
> Unfortunately I haven't seen any log files or anything, which would give us
> the opportunity to retrace what's happening.

Not sure which kind of backup you expect. How can I generate more useful
logfiles? IMHO I asked before for some kind of tracing functionality to
become able to get that information, i.e. to see how systemd is ticking,
to see what is happening or how the the delayed SIGTERM is triggered.

Those are basically the symptoms I see:

my .icewm/startup file at the moment contains:

xscreensaver -nosplash -log wtf-xscreensaver.txt &

When icewm starts, I see the splash screen for a brief moment (not joking, 
looks -nosplash has no effect there), but it does not happen every time.
And in wtf-xscreensaver.txt I find:

xscreensaver: 21:50:06: already running on display :0 (window 0x45)
 from process 9797 (lightdm@whitestar).

Second attempt (and a different PID):

When I run "xscreensaver-command -lock" (through ctrl-alt-del dialog of
icewm) then the screen gets locked, and pushing a key shows me the
credentials prompt for the user called "lightdm".

Or, if run ps quick enough before it's killed, I see:

user   3904  0.0  0.0   5712  1128 ?SN   21:13   0:00 
xscreensaver-systemd -verbose
lightdm11997  0.1  0.0  18948  5952 ?Ss   21:55   0:00 xscreensaver
lightdm12068  0.0  0.0   5712  1128 ?SN   21:55   0:00 
xscreensaver-systemd
user   12416  0.0  0.0   3748   664 pts/0S+   21:56   0:00 grep saver

(one of those "xscreensaver-systemd" belongs to an earlier session, this is 
another complaint of mine in #978589 but it's claimed not to cause the main 
issue).

Best regards,
Eduard.

Bug#979562: lightdm session termination does not stop xscreensaver

2021-01-13 Thread Eduard Bloch

Hallo,
* Jamie Zawinski [Mon, Jan 11 2021, 01:13:10PM]:
> > my .icewm/startup file at the moment contains:
> >
> > xscreensaver -nosplash -log wtf-xscreensaver.txt &
> >
> > When icewm starts, I see the splash screen for a brief moment (not joking, 
> > looks -nosplash has no effect there), but it does not happen every time.
>
> This kinda sounds like *something else* is launching xscreensaver at the same 
> time, and whatever that is is doing it without -nosplash. The two of them 
> racing would explain the "already running" error.

I think they are both originating from xscreensaver.service ExecStart's
command line.

> > Or, if run ps quick enough before it's killed, I see:
> >
> > user   3904  0.0  0.0   5712  1128 ?SN   21:13   0:00 
> > xscreensaver-systemd -verbose
> > lightdm11997  0.1  0.0  18948  5952 ?Ss   21:55   0:00 
> > xscreensaver
> > lightdm12068  0.0  0.0   5712  1128 ?SN   21:55   0:00 
> > xscreensaver-systemd
> > user   12416  0.0  0.0   3748   664 pts/0S+   21:56   0:00 grep 
> > saver
>
> Note that pid 11997 does not have -nosplash on its command line.

That also matches the command in the service file, including the ownership
of the process.

Best regards,
Eduard.

Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists

2021-01-25 Thread Eduard Bloch

Hallo,
* Adrian Bunk [Mon, Jan 25 2021, 07:15:35AM]:
> On Sun, Jan 10, 2021 at 12:10:16PM +0100, Eduard Bloch wrote:
> >...
> > I am setting this to RC severity because it's just NOT ok and obvious to
> > fix. Going to change mentioned things and NMU this in a couple of weeks
> > if there is no further reaction from maintainers.
>
> Could you make an upload to DELAYED instead of further waiting?

I am no longer waiting, today is timeout day. Will use 7-DAY DELAYED
queue, should be appropriate.

Best regards,
Eduard.

Bug#948346: [PATCH] Ensure graceful signal handling when the pid file exists

2021-02-08 Thread Eduard Bloch

Control: tags 948346 +patch

Hallo,
* Chris Hofstaedtler [Mon, Feb 08 2021, 01:43:52AM]:
> * Eduard Bloch  [210208 00:43]:
> > > Could you make an upload to DELAYED instead of further waiting?
> >
> > I am no longer waiting, today is timeout day. Will use 7-DAY DELAYED
> > queue, should be appropriate.
>
> That upload somehow did not make it into the archive?

Not yet. If you need a patch, please grab the repo from
https://salsa.debian.org/xorg-team/app/xdm/-/merge_requests/2 and/or
contribute to the MR review.

@Julien: okay to add myself as Uploader and upload? And/or do you
actually insist on the changes mentioned in the MR?

Best regards,
Eduard.

--
error compiling committee.c: too many arguments to function

Bug#980923: acngtools eats all the CPU and doesn’t finish daily cron with merged pdiffs

2021-02-08 Thread Eduard Bloch

notfound 980923 3.6-1
thanks

Hallo,
* Eduard Bloch [Sun, Jan 31 2021, 11:30:07PM]:

> > > Interesting. Please throw gcore at it and send me a copy of that dump
> >
> > Uploaded at <https://people.debian.org/~taffit/acng/core.669583>, thanks
> > for looking into it.
>
> Ok, thank you. I think I can reproduce the issue with a local sample
> now. This also might be the cause of another bugreport I got recently.
>
> Stay tuned, I will send you a test binary for fix verification soon.

At least that issue should be solved in 3.6 now.

Best regards,
Eduard.

Bug#973883: [apt-cacher-ng] bad exit code (=0) instead (<>0) if Check permissions of /var/log/apt-cacher-ng

2021-02-08 Thread Eduard Bloch

Control: severity 973883 normal

Hallo,
* Jean-Marc LACROIX [Fri, Nov 06 2020, 03:46:53PM]:
> Package: apt-cacher-ng
> Version: 3.2.1-1
> Severity: grave
>
> Dear maintainers,
>
> It seems there is one bad exit code issue (=0) when trying to start démon if
> internal check is bad. (/etc/init.d/apt-cacher-ng start)

Yes.

> ansible@srv-apt-cache-400:~$ sudo /etc/init.d/apt-cacher-ng start
> [] Starting apt-cacher-ng: apt-cacher-ngProblem creating log files.
> Check permissions of the log directory, //var/log/apt-cacher-ng
>  failed!
> ansible@srv-apt-cache-400:~$ echo $?
> 0
> ansible@srv-apt-cache-400:~$
>
> And, of course, this is true, because ...

Yes.

> ansible@srv-apt-cache-400:~$ sudo ls -altr /var/log/apt-cacher-ng
> total 2
> drwx-- 2 root root 1024 Nov  6 14:34 .
> drwxr-xr-x 8 root root 1024 Nov  6 14:52 ..

So you have not installed it properly. Because you have some custom way
of adding the filesystem components. This does not justify the grave
severity.

> Thanks in advance to correct this issue. In my use case, because i am using
> Ansible to make deployment, it is then not possible to detect this bug
> (because exit code = 0) in one automatic way

So am I not sure what exactly you want to see fixed. Shall it start and
go to degraded mode in this situation, rejecting all operations? Shall
it start but run all downloads in pass-through mode (therefore hiding
the problem, actually).

Best regards,
Eduard.

Bug#975137: marked as done (apt-cacher-ng: FTBFS: collect2: fatal error: ld terminated with signal 11 [Segmentation fault])

2020-11-20 Thread Eduard Bloch

reopen 975137
reassign 975137 binutils
thanks

Hi,

first I assumed that it's a GOLD issue but looking at
https://buildd.debian.org/status/package.php?p=apt%2dcacher%2dng
shows the real drama. Half of architecture builds fail due to some
obscure segfault of ld linker.

Please investigate.

Best regards,
Eduard.

Bug#849034: broadcom-sta-dkms: Can't connect to wireless, regression

2016-12-23 Thread Eduard Bloch

Control: severity 849034 important

Hallo,
* Lisandro Damián Nicanor Pérez Meyer [Wed, Dec 21 2016, 09:46:14PM]:
> Package: broadcom-sta-dkms
> Version: 6.30.223.271-5
> Severity: serious
> Justification: The package becomes unusable
> 
> I've found out that using the debian revision -5 of this package leaves
> me without being able to connect to any network, failing on every attempt.

It works for me and at least the guy who submitted the recent patch.

Are you using network-manager (probably even without knowing)?
Did you turn off MAC address randomization?

> If I downgrade to the -4 version I can get the WiFi to work again.

I doubt that this is the only reason. This driver is so buggy and
unpredictable that it's hard to attribute errors correctly.

Try adding

[device]
wifi.scan-rand-mac-address=no

to /etc/NetworkManager/NetworkManager.conf and rebooting.

Regards,
Eduard.

-- 
Every great idea is worthless without someone to do the work. --Neil Williams

Bug#849077: Attributing the problem to NM after all

2017-07-30 Thread Eduard Bloch

clone 849875 -1
reassign -1 network-manager
retitle -1 WPA usage error: Invalid passphrase character
thanks

On Sat, Jul 01, 2017 at 11:32:28PM +0200, Francesco Poli wrote:
> Dear Debian wpasupplicant Maintainers,
> I noticed that these 3 RC bugs (#849122, #849077, #849875) are marked
> as found in wpa/2.6-2, which is now superseded by versions with epoch 2.
> What seems to have happened (please correct me, if I am wrong) is that
> the upstream version 2.4 was reintroduced into unstable (with epoch 2)
> and then migrated to stretch (before the stretch release as stable).
> 
> Hence, I would say that those three bugs only affect experimental and
> are not in stretch, buster or sid.
> 
> Could you please confirm that these 3 bugs should be marked as fixed in
> wpa/2:2.4-1 and found in wpa/2:2.6-4 ?

Ok, now the problem from the original report has hit me too.

I could not figure out what is going on. I selected an AP which has been
working fine for months, and suddenly NM switched me to another AP
(which works partly since it is far away and reception quality is bad).

I tried removing wpasupplicant and network-manager. Purging config.
Nothing helps. Checking the log, and WOW... (see attachment).
So wpa_supplicant says "Line 0: Invalid passphrase character".
Line 0 of what? This is most likely the input from NM which means: NM
feeds wpa_supplicant with CRAP. But which crap? When NM asked me for
passphrase, I am absolutely sure that I entered the correct one.

So I made some experiments. First I saw really weird stuff until I
googled and realized that one MUST NOT run NM when doing anything
manually with wpa_supplicant. Ok, stopped network-manager service.
Stopped wpa_supplicant. Used wpa_passphrase tool to setup
/etc/wpa_supplicant.conf manually. And run wpa_supplicant with that
config manually.

And guess what?  Apart from some warnings, the connection the connection
was established just fine. Works like a charm, perfectly stable
link, no issues whatsoever.

For me, that means: I will purge network-manager now and go old-school
until the problem is fixed.

Successfully initialized wpa_supplicant
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
wlan0: Trying to associate with 00:1f:3f:15:f4:2d (SSID='FOO_nomap' freq=2472 
MHz)
wlan0: CTRL-EVENT-DISCONNECTED bssid=00:1f:3f:15:f4:2d reason=0
ioctl[SIOCSIWSCAN]: Device or resource busy
wlan0: CTRL-EVENT-SCAN-FAILED ret=-1 retry=1
wlan0: Associated with 00:00:00:00:00:00
wlan0: WPA: No SSID info found (msg 1 of 4)
wlan0: WPA: No SSID info found (msg 1 of 4)
wlan0: WPA: No SSID info found (msg 1 of 4)
wlan0: WPA: No SSID info found (msg 1 of 4)
wlan0: CTRL-EVENT-DISCONNECTED bssid=00:00:00:00:00:00 reason=0
wlan0: Trying to associate with 00:1f:3f:15:f4:2d (SSID='FOO_nomap' freq=2472 
MHz)
wlan0: Associated with 00:1f:3f:15:f4:2d
wlan0: WPA: Key negotiation completed with 00:1f:3f:15:f4:2d [PTK=CCMP GTK=TKIP]
wlan0: CTRL-EVENT-CONNECTED - Connection to 00:1f:3f:15:f4:2d completed [id=0 
id_str=]
wlan0: WPA: Group rekeying completed with 00:1f:3f:15:f4:2d [GTK=TKIP]

Regards,
Eduard.

Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.6262] manager: 
startup complete
Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.7215] device 
(wlan0): disconnecting for new activation request.
Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.7216] device 
(wlan0): state change: activated -> deactivating (reason 'new-activation', 
internal state 'managed')
Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.7230] manager: 
NetworkManager state is now DISCONNECTING
Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.7588] audit: 
op="connection-activate" uuid="6f48a4fc-94ec-49c0-be4b-6c6e4f9224b7" 
name="FOO_nomap" pid=1219 uid=1000 result="
Jul 30 19:25:32 idefix nm-dispatcher[7254]: req:6 'connectivity-change': new 
request (1 scripts)
Jul 30 19:25:32 idefix nm-dispatcher[7254]: req:6 'connectivity-change': start 
running ordered scripts...
Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.7716] device 
(wlan0): state change: deactivating -> disconnected (reason 'new-activation', 
internal state 'managed')
Jul 30 19:25:32 idefix avahi-daemon[697]: Withdrawing address record for 
fe80::4a5a:b6ff:fedb:b295 on wlan0.
Jul 30 19:25:32 idefix avahi-daemon[697]: Leaving mDNS multicast group on 
interface wlan0.IPv6 with address fe80::4a5a:b6ff:fedb:b295.
Jul 30 19:25:32 idefix avahi-daemon[697]: Interface wlan0.IPv6 no longer 
relevant for mDNS.
Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.7942] dhcp4 
(wlan0): canceled DHCP transaction, DHCP client pid 7285
Jul 30 19:25:32 idefix NetworkManager[7274]:   [1501435532.7943] dhcp4 
(wlan0): state changed bound -> done
Jul 30 19:25:32 idefix wpa_supplicant[6958]: wlan0: CTRL-EVENT-DISCONNECTED 
bssid=00:24:fe:04:fc:bb reason=3 locally_generated=1
Jul 30 19:25:32 idefix wpa_supplicant[6958]: nl80211: Was expecting local 
disconnect but got an

Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input

2017-02-01 Thread Eduard Bloch

Hallo,
* Francesco Namuri [Tue, Jan 31 2017, 06:06:01PM]:

> > Yes, I agree that it's easily discoverable--which is why I'm concerned
> > that simply removing the entire functionality of the package without
> > any kind of notification to the user isn't the best way to address the
> > problem. Again: removing the package simply ensures that people
> > upgrading to stretch will either end up with a cryptkeeper package
> > that exhibits this bug, or will remove their cryptkeeper package and
> > not know how to access their stored data, right?
> > 
> > Mike Stone
> 
> Hello Mike,
> thanks for the comments.
> 
> This issue only affectes the cryptkeeper working with encfs 1.9.1-3, in
> stable we have 1.7.4-5 that works as cryptkeeper expects.
> 
> People that upgrades from jessie to stretch simple "loses" cryptkeeper,
> package, of course they are still able to access their stored data using
> encfs or any other frontend to it.
> 
> IMHO it's better to remove the program in any envrionment that is affected
> by this issue, putting a note in the README or also on the debconf isn't
> enough to balance the gravity of the issue. Users can think they lost data
> because of a wrong password, or even worst they can trust on a worthless
> data encryption.

Also many thanks from my side...

So I guess I better upload an encfs package which simply conflicts with
cryptkeeper or does anyone have a better idea?

Best Regards,
Eduard.


signature.asc
Description: PGP signature

Bug#871270: encfs: requires rebuild against GCC 7 and symbols/shlibs bump

2017-08-15 Thread Eduard Bloch

Hallo,
* jcowg...@debian.org [Mon, Aug 07 2017, 03:20:41PM]:
> Package: encfs
> Version: 1.9.2-1
> Severity: serious
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: gcc-7-op-mangling
> 
> Hi,
> 
> It appears that your package provides an external symbol that is
> affected by the recent name mangling changes in GCC 7. See:
> https://gcc.gnu.org/gcc-7/porting_to.html#conversion-op-mangling

It might be the case, however, the library inside is for internal use
only. So I think the report and advise are not appropriate here. If you
agree, please close the bug report and maybe also adjust the scan script
to consider the hints from lintian overrides, like those:

$ cat /usr/share/lintian/overrides/encfs
encfs: non-dev-pkg-with-shlib-symlink usr/lib/libencfs.so.6.0.1 
usr/lib/libencfs.so
encfs: no-shlibs-control-file usr/lib/libencfs.so.6.0.1
encfs: postinst-must-call-ldconfig usr/lib/libencfs.so.6.0.1
encfs: package-name-doesnt-match-sonames libencfs6

Best regards,
Eduard.

Bug#841431: apt-cacher-ng: FTBFS on mips/mipsel: undefined reference to '__atomic_fetch_add_8'

2016-10-20 Thread Eduard Bloch

Control: retitle 841431 FTBFS on m68k/powerpcspe
Control: reopen 841431

I wanted to extend this patch to a couple of other architectures and
failed to commit the change prior to release :-(

To be fixed in an upstream release soon.

Regards,
Eduard.

Bug#928390: unable to upgrade if previous version was not operational

2019-05-03 Thread Eduard Bloch

Package: virtualbox-ext-pack
Version: 6.0.6-1
Severity: serious

Just what the subject says. Tries to upgrade from 6.0.4-1, and fails.
What it's doing there? No idea, looks like it tries to do some checks
but stumbles on the results if they are not what it has expected.

The recommendation to install virtualbox-dkms is nonsense. The problems
here happens while I trying to get the modules installed with
module-assistant. Even if I would use DKMS, the message is nonsense for
people who want to install it now but not load the modules yet.

The following packages will be upgraded:
  virtualbox-ext-pack
1 upgraded, 0 newly installed, 0 to remove and 1062 not upgraded.
3 not fully installed or removed.
Need to get 0 B/12.7 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 685533 files and directories currently installed.)
Preparing to unpack .../virtualbox-ext-pack_6.0.6-1_all.deb ...
WARNING: The character device /dev/vboxdrv does not exist.
 Please install the virtualbox-dkms package and the appropriate
 headers, most likely linux-headers-5.0.5+.

 You will not be able to start VMs until this problem is fixed.
0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to uninstall "Oracle VM VirtualBox Extension Pack"
VBoxManage: error: The installer failed with exit code 1: VBoxExtPackHelperApp: 
error: The owner is not root: '/usr/lib'
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component 
ExtPackManagerWrap, interface IExtPackManager
VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 
1402 of file VBoxManageMisc.cpp
dpkg: warning: old virtualbox-ext-pack package pre-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
WARNING: The character device /dev/vboxdrv does not exist.
 Please install the virtualbox-dkms package and the appropriate
 headers, most likely linux-headers-5.0.5+.

 You will not be able to start VMs until this problem is fixed.
0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to uninstall "Oracle VM VirtualBox Extension Pack"
VBoxManage: error: The installer failed with exit code 1: VBoxExtPackHelperApp: 
error: The owner is not root: '/usr/lib'
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component 
ExtPackManagerWrap, interface IExtPackManager
VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 
1402 of file VBoxManageMisc.cpp
dpkg: error processing archive 
/var/cache/apt/archives/virtualbox-ext-pack_6.0.6-1_all.deb (--unpack):
 new virtualbox-ext-pack package pre-removal script subprocess returned error 
exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/virtualbox-ext-pack_6.0.6-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.5+ (SMP w/12 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virtualbox-ext-pack depends on:
ii  debconf [debconf-2.0]  1.5.70
iu  virtualbox 6.0.6-dfsg-1
ii  wget   1.20.1-1

virtualbox-ext-pack recommends no packages.

virtualbox-ext-pack suggests no packages.

-- debconf information:
* virtualbox-ext-pack/license: true

--
 Ah, weasel macht einen auf google.
 Kontextsensitiver Spam. ;)

Bug#928390: Acknowledgement (unable to upgrade if previous version was not operational)

2019-05-03 Thread Eduard Bloch

Control: retitle 928390 unable to remove/upgrade where installed version is not 
operational
Control: severity 928390 grave

Even worse:

The following packages will be REMOVED:
  virtualbox-ext-pack
0 upgraded, 0 newly installed, 1 to remove and 1062 not upgraded.
3 not fully installed or removed.
After this operation, 130 kB disk space will be freed.
Do you want to continue? [Y/n]
(Reading database ... 685523 files and directories currently installed.)
Removing virtualbox-ext-pack (6.0.4-1) ...
WARNING: The character device /dev/vboxdrv does not exist.
 Please install the virtualbox-dkms package and the appropriate
 headers, most likely linux-headers-5.0.5+.

 You will not be able to start VMs until this problem is fixed.
0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to uninstall "Oracle VM VirtualBox Extension Pack"
VBoxManage: error: The installer failed with exit code 1: VBoxExtPackHelperApp: 
error: The owner is not root: '/usr/lib'
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component 
ExtPackManagerWrap, interface IExtPackManager
VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line 
1402 of file VBoxManageMisc.cpp
dpkg: error processing package virtualbox-ext-pack (--remove):
 installed virtualbox-ext-pack package pre-removal script subprocess returned 
error exit status 1
Errors were encountered while processing:
 virtualbox-ext-pack
E: Sub-process /usr/bin/dpkg returned an error code (1)

Regards,
Eduard.

Bug#928957: expiration task fails on non-existent files

2019-05-13 Thread Eduard Bloch

Package: apt-cacher-ng
Version: 3.2-1
Severity: serious

This bug is basically reminder to myself and not to whoever runs into
this issue.

Looks like apt-cacher-ng expiery manages to maneuver itself into a state
which cannot be recovered. It reports non-existent files from apparently
guessed sources, like:

Error summary:
debrep/dists/jessie/main/installer-amd64/current/images/SHA256SUMS: 404 Not 
Found
debrep/dists/stretch/main/installer-amd64/20170615+deb9u5+b2/images/SHA256SUMS: 
404 Not Found
localhost/ftp.de.debian.org/debian/dists/stretch/main/installer-amd64/20170615+deb9u5+b2/images/SHA256SUMS:
 404 Not Found
localhost/ftp.de.debian.org/debian/dists/stretch/main/installer-amd64/20170615/images/SHA256SUMS:
 404 Not Found

I have a vague idea where it comes from (old heuristics which fetched
voluntarily additional metadata which was not well linked in old Debian
versions, like 10 years ago). This needs to be investigated (digging
through history) and probably removed, or fixed.

-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Bug#917273: overwritting files from libservlet2.5-java

2018-12-25 Thread Eduard Bloch

Package: libel-api-java
Version: 3.0.0-1
Severity: grave

The usual story, not installable, breaks upgrade.
Please resolve this conflict:

Unpacking libel-api-java (3.0.0-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libel-api-java_3.0.0-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/maven-repo/javax/el/el-api/debian/el-api-debian.pom', which is also 
in package libservlet2.5-java 6.0.45+dfsg-1
Errors were encountered while processing:
 /var/cache/apt/archives/libel-api-java_3.0.0-1_all.deb

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.20.0-rc7 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

-- 
"Lassen Sie sich 'Sklaventreiber' auf die Stirn tätowieren. Das ist
ehrlich, da wissen wir alle woran wir sind".
-- Volker Pispers

Bug#912380: endless looping, breaks dpkg

2018-10-30 Thread Eduard Bloch

Package: man-db
Version: 2.8.4-2+b1
Severity: serious
File: /usr/bin/mandb

Hello,

I am no longer able to install many packages. The man-db hook keeps
running and running for ages.

I have monitored it with strace and it seems to run over the same files
in man1 folder all over again, never ending. See the logs (also
filtered for open* syscalls):

https://www.unix-ag.uni-kl.de/~bloch/misc/wtf_mandb_dead_loop.txt.gz
https://www.unix-ag.uni-kl.de/~bloch/misc/wtf_mandb_dead_loop.strace.log

Best regards,
Eduard.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-rc8 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.2
ii  groff-base 1.22.3-10
ii  libc6  2.27-6
ii  libgdbm6   1.18-2
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.3-3
ii  zlib1g 1:1.2.11.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor   2.13-8
ii  chromium [www-browser] 70.0.3538.54-2
ii  elinks [www-browser]   0.12~pre6-13
ii  firefox [www-browser]  62.0.3-1
ii  firefox-esr [www-browser]  60.2.2esr-1
ii  groff  1.22.3-10
ii  less   487-0.1+b1
ii  lynx [www-browser] 2.8.9rel.1-2
ii  qupzilla [www-browser] 2.2.5~dfsg1-1
ii  w3m [www-browser]  0.5.3-36+b1

-- debconf information:
  man-db/build-database: true
  man-db/rebuild-database: true
* man-db/install-setuid: true
  man-db/auto-update: true

-- 
Naja, Garbage Collector eben. Holt den Müll sogar vom Himmel.
   (Heise Trollforum über Java in der Flugzeugsteuerung)

Bug#912380: endless looping, breaks dpkg

2018-10-31 Thread Eduard Bloch

Hallo,
* Colin Watson [Wed, Oct 31 2018, 11:38:31AM]:
> On Tue, Oct 30, 2018 at 10:27:22PM +0100, Eduard Bloch wrote:
> > I am no longer able to install many packages. The man-db hook keeps
> > running and running for ages.
> > 
> > I have monitored it with strace and it seems to run over the same files
> > in man1 folder all over again, never ending. See the logs (also
> > filtered for open* syscalls):
> > 
> > https://www.unix-ag.uni-kl.de/~bloch/misc/wtf_mandb_dead_loop.txt.gz
> > https://www.unix-ag.uni-kl.de/~bloch/misc/wtf_mandb_dead_loop.strace.log
> 
> Are you sure it's looping endlessly?  Your logs don't support that
> theory.  Some file names are repeated, but that's because they're the
> basenames of manual pages that exist in a number of different languages.
> I haven't so far seen any page being processed more than once in your
> log.  (Note that each file is opened twice in relatively quick
> succession for different phases of processing, which is a little bit
> suboptimal but not evidence of an endless loop.)
> 
> I think what's happening is simply that man-db was rebuilt against a new
> version of gdbm and therefore has to rebuild its database from scratch,
> and that this is unfortunately rather slow.  I'd need more evidence to
> determine that there's an endless-loop-type bug here.

No, not sure. But it was running for minutes and didn't seem to finish.
The system was not under load, FS is running on SSD, plenty of RAM
available too.

Today, after reboot, it works again like nothing happened. So, assuming
you are right, it looks like a sudden performance degradation but
without any obvious reason and not reproducible anymore.

Maybe I should have waited a few minutes more. So I guess we should
close the BR then?

Best regards,
Eduard.

Bug#874843: [cdcat] Future Qt4 removal from Buster

2019-08-26 Thread Eduard Bloch

reassign 874843 wnpp
retitle 874843 RFA: cdcat - maintain disk media contents catalog
thanks

Hallo Moritz,
* Moritz Mühlenhoff [Thu, Aug 22 2019, 11:16:12PM]:
> On Sat, Sep 09, 2017 at 09:03:03PM +0200, Lisandro Damián Nicanor Pérez Meyer 
> wrote:
> > Source: cdcat
> >
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> >
> > [announced] 
> > 
> >
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether there 
> > are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
>
> Eduard,
> cdcat is dead upstream, are you planning to port it to Qt5 yourself or should
> it be removed from the archive?

IMHO, unless some wants to contribute here, it can go for good.

TBH it was not just porting to Qt5 but also architectural issues in later
versions which I refused to package the way they were designed
(depending on build-time config and weird 3rd party libs). And I don't
have time nor much interest to continue here.

Thanks for pushing, I am making this request RFA for now and it can
become RoM by the time you are RoMing qt4.

Best regards,
Eduard.

--
 .oO( Graphischer installier fuer Debian:  ein xterm und drinnen d-i )
 weasel: ATERM!
 s/xterm/x-terminal-emulator/

Bug#874843: RC bug ignored

2019-09-08 Thread Eduard Bloch

clone 874843 -1
reassign -1 cdcat
thanks

> As you reassigned the bug to wnpp cdcat lost it's RC bug. Do you mind if I 
> clone it and reassign the clone to cdcat?
>
> We are targetting at removing Qt4 from testing as a first step.

Right, I am sorry. I just applied what you suggested.

Regards, Eduard.

Bug#996730: Certain menus don't work right when chrome is in the Normal Layer

2021-10-19 Thread Eduard Bloch

Control: severity 996730 important
Control: tags 996730 +notreproducible +upstream

Hallo,
* 積丹尼 Dan Jacobson [Mon, Oct 18 2021, 03:42:00AM]:
> Package: icewm
> Version: 2.8.0-1
> Severity: grave
>
> Are there any other users who can confirm
> https://github.com/ice-wm/icewm/issues/62 ?

I have no idea what you mean and this is definitively not "grave". Tried
to reproduce with different settings and chromium 93.0.4577.82-1 and it
just works.

Maybe some issue with other software on your system which is
manipulating properties?

Maybe gijsbers finds something. Does it work if you downgrade icewm (and
icewm-common) to the Testing version?

Best regards,
Eduard.

Bug#872565: encfs: FTBFS on mips, mipsel: undefined reference to `__atomic_store_8'

2017-08-18 Thread Eduard Bloch

Hallo,
* James Cowgill [Fri, Aug 18 2017, 05:02:52PM]:
> Source: encfs
> Version: 1.9.2-1
> Severity: serious
> Tags: sid buster
> 
> Hi,
> 
> ensfc FTBFS on mips, mipsel and various ports architectures with the error:
> > libencfs.so.1.9.2: undefined reference to `__atomic_store_8'
> > libencfs.so.1.9.2: undefined reference to `__atomic_fetch_add_8'
> > collect2: error: ld returned 1 exit status
> 
> This happens because those architectures do not have native 64-bit
> atomic instructions and instead call out to libatomic to provide
> emulations of them. To allow linking on these architecture you must link
> against libatomic.
> 
> One option is to add the -latomic to LDFLAGS in the Debian package, or I
> could probably come up with a patch to be applied upstream which will
> link only on the architectures it's needed.
> 
> Note there is an upstream GCC bug about doing all this in the toolchain,
> but for the moment it has to be done per package:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358

Thank you. I will try to handcraft a patch for the build system itself
and push it upstream ASAP.

Reminds me on a similar problem with
https://buildd.debian.org/status/fetch.php?pkg=apt-cacher-ng&arch=powerpc&ver=3-5&stamp=1493319231&raw=0
which is confusing, the current solution (detection of libatomic) was
successfull on mips and most other 32-bit arches. Needs a tougher
investigation, apparently.

Best regards,
Eduard.

Bug#870171: Attributing the problem to NM after all

2017-09-03 Thread Eduard Bloch

Hallo,
* Michael Biebl [Sun, Aug 27 2017, 01:04:53PM]:
> > Ok, now the problem from the original report has hit me too.
> > 
> > I could not figure out what is going on. I selected an AP which has been
> > working fine for months, and suddenly NM switched me to another AP
> > (which works partly since it is far away and reception quality is bad).
> > 
> > I tried removing wpasupplicant and network-manager. Purging config.
> > Nothing helps. Checking the log, and WOW... (see attachment).
> > So wpa_supplicant says "Line 0: Invalid passphrase character".
> > Line 0 of what? This is most likely the input from NM which means: NM
> > feeds wpa_supplicant with CRAP. But which crap? When NM asked me for
> > passphrase, I am absolutely sure that I entered the correct one.
> 
> Does the password have any special characters?

No. Actually, I have two APs here with different SSIDs but the same
password. One of them works fine, the other has the metioned problem.

> Can you change the WPA passphrase to something else (say only letters)
> and try again?

I did that and it worked. I reverted the change and then it works.

So the idea is then that something has corrupted the credentials store?
If so, why does it not drop the password from the store in case of
errors like this?

> Please also provide a full debug log from NetworkManager (and
> wpasupplicant) when the problem happens.
> https://wiki.gnome.org/Projects/NetworkManager/Debugging

Cannot do that right now. Luckily, I have a system backup and spare
hardware where it could be installed on... so I could try to reproduce
it if you want.

If you don't want, I think there should be some upstream fix which
deletes the credentials. The same way it does when the PSK has changed.

> which versions of wpasupplicant and network-manager do you have installed?

All Sid.

Best regards,
Eduard.

Bug#877613: icewm: FTBFS: icesound.cc:360:25: error: 'write' was not declared in this scope

2017-10-04 Thread Eduard Bloch

tags 877613 +upstream +pending
thanks

Shitty cmake code in audio library selection, I pushed the fix through upstream 
chain already.
That happens in experimental only, no urgency IMHO.

Bug#952811: [apt-cacher-ng] 500 Bad redirection (path)

2020-03-05 Thread Eduard Bloch

Control: tags 952811 +moreinfo

Hallo,
* Jean-Marc LACROIX [Sat, Feb 29 2020, 05:25:53PM]:
> Package: apt-cacher-ng
> Version: 3.2-2
> Severity: grave

That's hardly grave because not clearly reproducible. But I have seen
this 502 in development a couple of times, appeared and disappeared
without trace.

Please share your config, i.e. all *.conf and *.backend files.

Best regards,
Eduard.

--
Wo man am meisten drauf erpicht,
grad das bekommt man meistens nicht.
-- Wilhelm Busch

Bug#952811: [apt-cacher-ng] 500 Bad redirection (path)

2020-03-12 Thread Eduard Bloch

Control: severity 952811 important
Control: tags 952811 +upstream

Hallo,
* Eduard Bloch [Fri, Mar 06 2020, 07:48:22AM]:
> Control: tags 952811 +moreinfo
>
> Hallo,
> * Jean-Marc LACROIX [Sat, Feb 29 2020, 05:25:53PM]:
> > Package: apt-cacher-ng
> > Version: 3.2-2
> > Severity: grave
>
> That's hardly grave because not clearly reproducible. But I have seen
> this 502 in development a couple of times, appeared and disappeared
> without trace.
>
> Please share your config, i.e. all *.conf and *.backend files.

Thanks for the config but still not really reproducible. That said, I
see where the error message comes from and the code there is probably
not correct.

If you wish to rebuild your package with the fix, get this patch
https://salsa.debian.org/blade/apt-cacher-ng/-/commit/145e608a48c20ad2cd0d1a87ba63e3a9e32a62bc
or checkout the branch
https://salsa.debian.org/blade/apt-cacher-ng/-/tree/debian/sid_v3.3.x
or alternative I will probably make a release anyway in the next days.

Sorry for the delay.

Best regads,
Eduard.

--
"Lassen Sie sich 'Sklaventreiber' auf die Stirn tätowieren. Das ist
ehrlich, da wissen wir alle woran wir sind".
-- Volker Pispers

Bug#948087: Please report state

2020-06-01 Thread Eduard Bloch

Hello,

I was notified by a prominent user who is seriouly worried about the
state of this package.

Please let us know whether it will be in releasable shape in the next
weeks, or whether you need any support or a sponsored upload. Thank you.

And in case that you no longer wish to maintain it, plesae follow the
regular procedures (see policy) of orphaning, or at least consider
raising a Request-For-Help, if appropriate.

Best regards,
Eduard.

--
 man
 the AMD64 camp is not helped by the list of people supporting it
 when nerode is on your side, you know you're doing something wrong

Bug#1052547: unable to boot, no luks passwort prompt shown

2023-09-24 Thread Eduard Bloch

Package: cryptsetup-initramfs
Version: 2:2.6.1-5
Severity: grave

Hello Maintainer,

we have a problem here. After latest upgrades, I am no longer able to
boot into a system with LUKS-encrypted rootfs. This worked just fine a few
weeks ago. I jumped in circles in the search for the cause, and only
after downgrading cryptsetup-initramfs to 2:2.6.1-4 it suddenly started
working again.

The symptom:

initramfs starts more or less okay, after a second KVM switches the
screen mode. And then I see a blinking cursor. And that's all.

Normally (like before, or after after downgrading the package) I get a
LUKS passwort prompt instead, where I enter the rootfs password.

Best regards,
Eduard.


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.5 root=UUID=6e83a5a5-0c68-41e9-8bcb-ea0b50c06197 ro 
acpi=force

-- /etc/crypttab
# 
#xroot /dev/sdb2 none luks,discard
#xroot UUID=4047a384-74d1-465d-9e1b-536f40ed73d2 none luks,discard
yroot UUID=0a03cfce-d1a8-4a93-a403-d411f8ead12e none luks,discard

-- /etc/fstab
# /etc/fstab: static file system information.
#
#
proc /proc   proc   
   defaults  0  
  0
/dev/mapper/yroot  /   ext4  
defaults,errors=remount-ro,noatime,commit=1200  
  1
UUID="e69c6bbe-f493-4dc5-aed3-419654c4bf41" /boot   ext4
defaults,errors=remount-ro 01
UUID="B63D-00A4" /boot/efi vfat defaults,errors=remount-ro 01
/dev/cdrom   /media/cdrom0   
udf,iso9660   ro,user,noauto0   
 0
UUID="0a03cfce-d1a8-4a93-a403-d411f8ead12e"  /mnt/bigdata   auto noauto,user
UUID="2610550D1054E579"/mnt/d  ntfs-3g  
 utf8,user,auto,umask=000,nofail   0
0
UUID="78496414545E7C56"  /mnt/cfs2   ntfs-3g
   defaults,noauto,nofail   0   
 1
UUID=CE2E78A02E78836F /mnt/c  ntfs-3g   
utf8,user,auto,umask=000,nofail   0 
   0
none /var/cache/pbuilder/bd  tmpfs  
   defaults  0  
  0

-- lsmod
Module  Size  Used by
snd_seq_dummy  12288  0
snd_hrtimer12288  1
snd_seq   110592  7 snd_seq_dummy
cpufreq_userspace  16384  0
cpufreq_conservative16384  0
cpufreq_powersave  16384  0
nvme_fabrics   36864  0
overlay   188416  0
bnep   28672  2
uinput 20480  1
binfmt_misc28672  1
nls_ascii  12288  1
nls_cp437  16384  1
vfat   20480  1
fat94208  1 vfat
pktcdvd53248  0
uvcvideo  143360  0
videobuf2_vmalloc  20480  1 uvcvideo
uvc12288  1 uvcvideo
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 36864  1 uvcvideo
snd_usb_audio 401408  1
videodev  356352  2 videobuf2_v4l2,uvcvideo
snd_usbmidi_lib49152  1 snd_usb_audio
snd_rawmidi53248  1 snd_usbmidi_lib
videobuf2_common   77824  4 
videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops
joydev 24576  0
snd_seq_device 16384  2 snd_seq,snd_rawmidi
mc 94208  5 
videodev,snd_usb_audio,videobuf2_v4l2,uvcvideo,videobuf2_common
btusb  81920  0
btmtk  12288  1 btusb
btrtl  28672  1 btusb
btbcm  24576  1 btusb
btintel57344  1 btusb
bluetooth1110016  15 btrtl,btmtk,btintel,btbcm,bnep,btusb
intel_rapl_msr 20480  0
intel_rapl_common  36864  1 intel_rapl_msr
kvm_amd   180224  0
sha3_generic   16384  1
jitterentropy_rng  20480  1
drbg   28672  1
snd_hda_codec_realtek   192512  1
ccp   135168  1 kvm_amd
snd_hda_codec_generic   110592  1 snd_hda_codec_realtek
ansi_cprng 12288  0
ledtrig_audio  12288  1 snd_hda_codec_generic
ecdh_generic   16384  1 bluetooth
snd_hda_codec_hdmi 90112  2
rfkill 40960  4 bluetooth
snd_hda_intel  61440  3
ecc45056  1 ecdh_generic
snd_intel_dspcfg   24576  1 snd_hda_intel
kvm  1335296  1 kvm_amd
snd_hda_codec 221184  4 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek
irqbypass  12288  1 kvm
snd_hda_core  143360  5 
snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec

Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

2024-03-24 Thread Eduard Bloch

On Fri, 22 Mar 2024 23:46:02 +0100 Julian Andres Klode 
 wrote:
> Version: 1+2.12+1+b1
> 
> (this should be the right version when it gets accepted)
> 
> On Fri, Mar 22, 2024 at 06:23:06PM +0800, Tianyu Chen wrote:
> > Package: grub-efi-amd64-signed
> > Version: 1+2.12+1
> > Severity: serious
> > X-Debbugs-Cc: sweetyf...@deepin.org
> > 
> > Hi,
> > 
> > grub-efi-amd64-signed seems uninstallable now in sid. This might caused
> > by a binNMU in src:grub2.
> > 
> > The following packages have unmet dependencies:
> >  grub-efi-amd64-signed : Depends: grub-common (= 2.12-1) but it is not 
> > going to be installed
> > 
> > $ apt policy grub-common
> > grub-common:
> >   Installed: (none)
> >   Candidate: 2.12-1+b1
> >   Version table:
> >  2.12-1+b1 500
> > 500 http://mirrors.cernet.edu.cn/debian sid/main amd64 Packages
> > 
> > Please upload a new version so grub-efi-amd64-signed can be installable.
> > Thanks!
> 
> I'm getting a bit tired of this. This is normal, the packages are
> automatically generated but need to be approved by ftpteam. 
> 
> And people are probably understandably hesitant to accept them because future
> binNMUs are expected.
> 
> So Please do not file bugs for them, it is out of our hands.
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
> 
>

Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

2024-03-24 Thread Eduard Bloch

On Fri, 22 Mar 2024 23:46:02 +0100 Julian Andres Klode 
 wrote:
> Version: 1+2.12+1+b1
> 
> (this should be the right version when it gets accepted)
> 
> On Fri, Mar 22, 2024 at 06:23:06PM +0800, Tianyu Chen wrote:
> > Package: grub-efi-amd64-signed
> > Version: 1+2.12+1
> > Severity: serious
> > X-Debbugs-Cc: sweetyf...@deepin.org
> > 
> > Hi,
> > 
> > grub-efi-amd64-signed seems uninstallable now in sid. This might caused
> > by a binNMU in src:grub2.
> > 
> > The following packages have unmet dependencies:
> >  grub-efi-amd64-signed : Depends: grub-common (= 2.12-1) but it is not 
> > going to be installed
> > 
> > $ apt policy grub-common
> > grub-common:
> >   Installed: (none)
> >   Candidate: 2.12-1+b1
> >   Version table:
> >  2.12-1+b1 500
> > 500 http://mirrors.cernet.edu.cn/debian sid/main amd64 Packages
> > 
> > Please upload a new version so grub-efi-amd64-signed can be installable.
> > Thanks!
> 
> I'm getting a bit tired of this. This is normal, the packages are
> automatically generated but need to be approved by ftpteam. 
> 
> And people are probably understandably hesitant to accept them because future
> binNMUs are expected.
> 
> So Please do not file bugs for them, it is out of our hands.
> 
> -- 
> debian developer - deb.li/jak | jak-linux.org - free software dev
> ubuntu core developer  i speak de, en
> 
>

Bug#1067486: Depends: grub-common (= 2.12-1) but it is not going to be installed

2024-03-24 Thread Eduard Bloch

reopen 1067486
reassign 1067486 apt
severity 1067486 normal
thanks

Am Fri, Mar 22, 2024 at 11:46:02PM +0100 schrieb Julian Andres Klode:

> > Please upload a new version so grub-efi-amd64-signed can be installable.
> > Thanks!
> 
> I'm getting a bit tired of this. This is normal, the packages are
> automatically generated but need to be approved by ftpteam. 

This might be a normal condition but a) this is not transparent to user,
and b) it really does break apt's operation, at least partly.

For a) maybe we should make this somehow auto-checked remotely and shown
in reportbug? Or would you have a better idea?

And for b) all "dist-upgrade" or "full-upgrade" failed suddenly. Yes,
failing, user getting completely locked out. And "upgrade" operation
installed just a fraction of the potential candidates (there were more
reasons for that but the lack of dist-upgrade feature is still PITA).
And the reason has not been obvious, and even debugging with
-oDebug::pkgProblemResolver=true is NO FUN on bigger upgrades.

And the eventual solution was close examination, and some
guessing/observing that apt is confused and jumps between amd64 and
i386, and then some FORCE magic, i.e.

dpkg --remove --force-depends grub-common:i386

(don't ask me how this package got installed before, that system
installation has been migrated a lot). Another candidate was an old
iproute:i386 package which I also had to remove.

Best regards,
Eduard.

Bug#1057447: broadcom-sta-dkms: module build fails for Linux 6.6: wl_linux.c:486:12: error: 'struct net_device' has no member named 'wireless_handlers'

2024-03-02 Thread Eduard Bloch

tags 1057447 +moreinfo
thanks

Hi,

which exact kernel version is that? Which exact compiler version is
that?

At the first glance, that looks like some DKMS bug to me (see the
strange shell warning).

I just tested the module-assistant based build with a locally built
6.6.18 on Stable, works like a charm.

"/usr/share/modass/packages/default.sh" build KVERS=6.6.18 
KSRC=/lib/modules/6.6.18/build KDREV=6.6.18-5 kdist_image
Done with /usr/src/broadcom-sta-modules-6.6.18_6.30.223.271-23+6.6.18-5_all.deb 
.
dpkg -Ei /usr/src/broadcom-sta-modules-6.6.18_6.30.223.271-23+6.6.18-5_all.deb
(Reading database ... 464471 files and directories currently installed.)
Preparing to unpack 
.../broadcom-sta-modules-6.6.18_6.30.223.271-23+6.6.18-5_all.deb ...
Unpacking broadcom-sta-modules-6.6.18 (6.30.223.271-23+6.6.18-5) ...
Setting up broadcom-sta-modules-6.6.18 (6.30.223.271-23+6.6.18-5) ...
apt-mark auto broadcom-sta-modules-6.6.18
broadcom-sta-modules-6.6.18 set to automatically installed.

Please elaborate!

Eduard.

* Andreas Beckmann [Tue, Dec 05 2023, 10:33:27AM]:
> Package: broadcom-sta-dkms
> Version: 6.30.223.271-23
> Severity: important
> Tags: sid trixie
>
> Hi,
>
> broadcom-sta-dkms fails to build a module for Linux 6.6 that was just uploaded
> to experimental:
>
> DKMS make.log for broadcom-sta-6.30.223.271 for kernel 6.6-cloud-amd64 
> (x86_64)
> Tue Dec  5 08:33:20 UTC 2023
> /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64
> /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64
> Wireless Extension is the only possible API for this kernel version
> Using Wireless Extension API
> KBUILD_NOPEDANTIC=1 make -C /lib/modules/6.6-cloud-amd64/build M=`pwd`
> make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
> rule.
> make[1]: Entering directory '/usr/src/linux-headers-6.6-cloud-amd64'
> /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64
> /bin/sh: 1: [: Illegal number: 6.6-cloud-amd64
> Wireless Extension is the only possible API for this kernel version
> Using Wireless Extension API
> Kernel architecture is X86_64
>   CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/shared/linux_osl.o
>   CC [M]  /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o
> In file included from 
> /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:81:
> /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_iw.h:73: warning: 
> "isprint" redefined
>73 | #define isprint(c) bcm_isprint(c)
>   |
> In file included from 
> /usr/src/linux-headers-6.6-common/include/linux/string_helpers.h:6,
>  from 
> /usr/src/linux-headers-6.6-common/include/linux/seq_file.h:7,
>  from 
> /usr/src/linux-headers-6.6-common/include/linux/seq_file_net.h:5,
>  from 
> /usr/src/linux-headers-6.6-common/include/net/net_namespace.h:195,
>  from 
> /usr/src/linux-headers-6.6-common/include/linux/netdevice.h:38,
>  from 
> /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/include/linuxver.h:69,
>  from 
> /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:27:
> /usr/src/linux-headers-6.6-common/include/linux/ctype.h:30: note: this is the 
> location of the previous definition
>30 | #define isprint(c)  ((__ismask(c)&(_P|_U|_L|_D|_SP)) != 0)
>   |
> /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c: In 
> function 'wl_if_setup':
> /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.c:486:12: 
> error: 'struct net_device' has no member named 'wireless_handlers'
>   486 | dev->wireless_handlers = (struct iw_handler_def *) 
> &wl_iw_handler_def;
>   |^~
> make[3]: *** [/usr/src/linux-headers-6.6-common/scripts/Makefile.build:248: 
> /var/lib/dkms/broadcom-sta/6.30.223.271/build/src/wl/sys/wl_linux.o] Error 1
> make[2]: *** [/usr/src/linux-headers-6.6-common/Makefile:1938: 
> /var/lib/dkms/broadcom-sta/6.30.223.271/build] Error 2
> make[1]: *** [/usr/src/linux-headers-6.6-common/Makefile:246: __sub-make] 
> Error 2
> make[1]: Leaving directory '/usr/src/linux-headers-6.6-cloud-amd64'
> make: *** [Makefile:181: all] Error 2
>
>
> Andreas

--
error compiling committee.c: too many arguments to function

Bug#1057447: broadcom-sta-dkms: module build fails for Linux 6.6: wl_linux.c:486:12: error: 'struct net_device' has no member named 'wireless_handlers'

2024-03-02 Thread Eduard Bloch

Hallo,
* Andreas Beckmann [Fri, Feb 23 2024, 06:27:26PM]:
> Followup-For: Bug #1057447
> Control: found -1 6.30.223.271-24~exp1
> Control: tag -1 + patch
>
> This issue is caused by
> a) version parsing that expects three numeric components (6.6.1-foo) and
>fails if there are only two (6.7-rc1)
> b) broken version comparison logic
> which turn on APICHOICE=FORCE_WEXT on kernels without
> CONFIG_WIRELESS_EXT
>
> Attached patch fixes that.

Thanks, and sorry, I overlooked the last message. I guess we should take
it as is. Any opinion from Roger or Cyril?

BR,
Eduard.

--
* weasel hatte letztens eine nette idee fuer ein namensschema
 hab's aber leider wieder vergessen :(

Bug#372783: linux-image-2.6.16-2-amd64-k8: initrd symlink management sucks

2006-06-11 Thread Eduard Bloch

Package: linux-image-2.6.16-2-amd64-k8
Version: 2.6.16-14
Severity: grave

Hello,

today my machine failed to boot. What was the real reason? Something is
completely fscked up with initrd management. The chronics:

some weeks ago: install of linux-image-2.6.16-1-amd64
dist-upgrading
manual install of self-compiled linux-image-2.6.17-rc6 (without initrd)
reinstall of linux-image-2.6.16-1-amd64
deinstall of linux-image-2.6.17-rc6
today: install of linux-image-2.6.16-2-amd64
reboot

Machine does not reboot. -1-amd64 is broken because initrd.img.old
points to the _new_ initrd for -2-amd64 and initrd.img symlink is missing.

So, how could this happen? I don't know. The only suspicious thing that
I remember is that grub-install seemed to be run twice, I don't know
why. But such problems must not appear, thus the severity.

Eduard.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-rc5
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages linux-image-2.6.16-2-amd64-k8 depends on:
ii  e2fsprogs 1.39-1 ext2 file system utilities and lib
ii  initramfs-tools [linux-initra 0.60   tools for generating an initramfs
ii  module-init-tools 3.2.2-3tools for managing Linux kernel mo

linux-image-2.6.16-2-amd64-k8 recommends no packages.

-- debconf information:
  linux-image-2.6.16-2-amd64-k8/preinst/already-running-this-2.6.16-2-amd64-k8:
  linux-image-2.6.16-2-amd64-k8/postinst/depmod-error-2.6.16-2-amd64-k8: false
  linux-image-2.6.16-2-amd64-k8/preinst/abort-overwrite-2.6.16-2-amd64-k8:
  linux-image-2.6.16-2-amd64-k8/postinst/create-kimage-link-2.6.16-2-amd64-k8: 
true
  linux-image-2.6.16-2-amd64-k8/postinst/bootloader-error-2.6.16-2-amd64-k8:
  
linux-image-2.6.16-2-amd64-k8/postinst/bootloader-test-error-2.6.16-2-amd64-k8:
  linux-image-2.6.16-2-amd64-k8/postinst/depmod-error-initrd-2.6.16-2-amd64-k8: 
false
  linux-image-2.6.16-2-amd64-k8/postinst/kimage-is-a-directory:
  linux-image-2.6.16-2-amd64-k8/preinst/lilo-initrd-2.6.16-2-amd64-k8: true
  linux-image-2.6.16-2-amd64-k8/preinst/lilo-has-ramdisk:
  linux-image-2.6.16-2-amd64-k8/postinst/old-dir-initrd-link-2.6.16-2-amd64-k8: 
true
  linux-image-2.6.16-2-amd64-k8/preinst/overwriting-modules-2.6.16-2-amd64-k8: 
true
  linux-image-2.6.16-2-amd64-k8/postinst/old-initrd-link-2.6.16-2-amd64-k8: true
  
linux-image-2.6.16-2-amd64-k8/prerm/removing-running-kernel-2.6.16-2-amd64-k8: 
true
  
linux-image-2.6.16-2-amd64-k8/preinst/failed-to-move-modules-2.6.16-2-amd64-k8:
  linux-image-2.6.16-2-amd64-k8/preinst/initrd-2.6.16-2-amd64-k8:
  linux-image-2.6.16-2-amd64-k8/postinst/old-system-map-link-2.6.16-2-amd64-k8: 
true
  
linux-image-2.6.16-2-amd64-k8/prerm/would-invalidate-boot-loader-2.6.16-2-amd64-k8:
 true
  linux-image-2.6.16-2-amd64-k8/preinst/abort-install-2.6.16-2-amd64-k8:
  linux-image-2.6.16-2-amd64-k8/preinst/bootloader-initrd-2.6.16-2-amd64-k8: 
true
  linux-image-2.6.16-2-amd64-k8/preinst/elilo-initrd-2.6.16-2-amd64-k8: true

-- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#372783: Err, there is not enough information here to make a determination

2006-06-11 Thread Eduard Bloch

#include 
* Manoj Srivastava [Sun, Jun 11 2006, 05:45:56PM]:
> tags 372783 +moreinfo
> thanks
> 
> Hi,
> 
>  some weeks ago: install of linux-image-2.6.16-1-amd64
> Presumed states:
>   initrd.img ->initrd.img-2.6.16-1-amd64
> 
>   
>  dist-upgrading   
>   
>  manual install of self-compiled linux-image-2.6.17-rc6 (without initrd)  
>   
> Presumed states:
>   initrd.img.old ->initrd.img-2.6.16-1-amd64
>  reinstall of linux-image-2.6.16-1-amd64  
>   
> No change.
> 
>  deinstall of linux-image-2.6.17-rc6  
>   
> No Change.
>  today: install of linux-image-2.6.16-2-amd64
> Presumed states:
>   initrd.img -> initrd.img-2.6.16-2-amd64
>   initrd.img.old -> initrd.img-2.6.16-1-amd64
> 
> If you are using grub, why are you not using update-grub? That
>  would work out of the box.  What is calling grub-install?

postinst following kernel-img.conf?

$ cat /etc/kernel-img.conf 
do_symlinks = yes
relative_links = yes
do_bootloader = no
do_bootfloppy = no
do_initrd = yes
link_in_boot = yes
postinst_hook = /sbin/update-grub
postrm_hook   = /sbin/update-grub

> What is the content of /boot? Did the initrd image actually
>  get created? 

The image was created. Only the symlinks were not set correctly, now I
have set them manually:

$ ls -l /boot/
insgesamt 25524
-rw-r--r-- 1 root root  857123 2006-03-20 12:36 System.map-2.6.15-1-amd64-k8
-rw-r--r-- 1 root root  877128 2006-05-04 18:29 System.map-2.6.16-1-amd64-k8
-rw-r--r-- 1 root root  876046 2006-05-22 19:42 System.map-2.6.16-2-amd64-k8
-rw-r--r-- 1 root root  769641 2006-03-02 14:21 System.map-2.6.16-rc5
-rw-r--r-- 1 root root  749345 2006-06-06 19:20 System.map-2.6.17-rc6
-rw-r--r-- 1 root root   58190 2006-03-20 09:27 config-2.6.15-1-amd64-k8
-rw-r--r-- 1 root root   59814 2006-05-04 14:38 config-2.6.16-1-amd64-k8
-rw-r--r-- 1 root root   59813 2006-05-22 15:34 config-2.6.16-2-amd64-k8
-rw-r--r-- 1 root root   42223 2006-03-02 14:10 config-2.6.16-rc5
-rw-r--r-- 1 root root   43195 2006-06-06 19:06 config-2.6.17-rc6
drwxr-xr-x 2 root root4096 2006-06-11 18:48 grub
lrwxrwxrwx 1 root root  28 2006-06-11 19:13 initrd.img -> 
initrd.img-2.6.16-2-amd64-k8
-rw-r--r-- 1 root root 5056998 2006-03-22 22:44 initrd.img-2.6.15-1-amd64-k8
-rw-r--r-- 1 root root 4856904 2006-06-09 10:50 initrd.img-2.6.16-1-amd64-k8
-rw-r--r-- 1 root root 4854405 2006-06-11 18:48 initrd.img-2.6.16-2-amd64-k8
lrwxrwxrwx 1 root root  28 2006-06-11 19:13 initrd.img.old -> 
initrd.img-2.6.16-1-amd64-k8
lrwxrwxrwx 1 root root  25 2006-06-09 10:50 vmlinuz -> 
vmlinuz-2.6.16-2-amd64-k8
-rw-r--r-- 1 root root 1305247 2006-03-20 12:36 vmlinuz-2.6.15-1-amd64-k8
-rw-r--r-- 1 root root 1321458 2006-05-04 18:29 vmlinuz-2.6.16-1-amd64-k8
-rw-r--r-- 1 root root 1320736 2006-05-22 19:42 vmlinuz-2.6.16-2-amd64-k8
-rw-r--r-- 1 root root 1529169 2006-03-02 14:21 vmlinuz-2.6.16-rc5
-rw-r--r-- 1 root root 1447079 2006-06-06 19:20 vmlinuz-2.6.17-rc6
lrwxrwxrwx 1 root root  25 2006-03-27 22:00 vmlinuz.old -> 
vmlinuz-2.6.16-1-amd64-k8

> If not, were there any errors during install?

I remember only the "usual" error message about broken .../source symlink

> With some more information, ths report can be acted upon.
>  Lacking it, it is likely to languish for a bit, and then get closed.

I cannot get you much more information. It is broken, I have not touched
the boot directory except of some params tunning in menu.lst. I don't
know what has caused it. The custom linux-image package is here:
http://people.debian.org/~blade/linux-image-2.6.17-rc6_2.6.17-rc6-10.00.Custom_amd64.deb
Package install history:
2006-03-02 14:21:25 install linux-image-2.6.16-rc5  
2.6.16-rc5-10.00.Custom
2006-03-02 14:21:25 status half-installed linux-image-2.6.16-rc5 
2.6.16-rc5-10.00.Custom
2006-03-02 14:21:27 status half-configured linux-image-2.6.16-rc5 
2.6.16-rc5-10.00.Custom
2006-03-02 14:21:27 status unpacked linux-image-2.6.16-rc5 
2.6.16-rc5-10.00.Custom
2006-03-02 14:21:28 status installed linux-image-2.6.16-rc5 
2.6.16-rc5-10.00.Custom
2006-03-10 09:59:48 install linux-image-2.6.15-1-amd64-k8  2.6.15-8
2006-03-10 09:59:48 status half-installed linux-image-2.6.15-1-amd64-k8 2.6.15-8
2006-03-10 09:59:52 install linux-image-2.6-amd64-k8  2.6.15-8
2006-03-10 09:59:52 status half-configured linux-image-2.6.15-1-amd64-k8 
2.6.15-8
2006-03-10 09:59:52 status half-installed linux-image-2.6-amd64-k8 2.6.15-8
2006-03-10 09:59:52 status unpacked linux-image-2.6-amd64-k8 2.6.15-8
2006-03-10 09:59:52 status unpacked linux-image-2.6.15-1-amd64-k8 2.6.15-8
2006-03-10 10:00:04 status half-configured linux-image-2.6-amd64-k8 2.6.15-8
2006-03

Bug#365151: libmail-mbox-messageparser-perl: message splitting breaks

2006-04-28 Thread Eduard Bloch

Package: libmail-mbox-messageparser-perl
Version: 1.4002-1
Severity: grave
Justification: causes non-serious data loss

Hello,

my program mail-expire uses this module to split mbox files into
individual messages. Sometimes, however, the end of file is reported too
early and data is _lost_ because of that. I did not try to investigate
the issue yet, test data is in:
http://people.debian.org/~blade/debian-user-german.Apr_2006.bz2
and the current version of the script is attached, with debugging output
enabled. If you look at that, it stops splitting the contents at <[EMAIL 
PROTECTED]> and returns the rest as one big message.

Regards,
Eduard.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages libmail-mbox-messageparser-perl depends on:
ii  libfilehandle-unget-perl  0.1621-2   a FileHandle which supports ungett
ii  perl  5.8.8-4Larry Wall's Practical Extraction 

libmail-mbox-messageparser-perl recommends no packages.

-- no debconf information

-- 
#!/usr/bin/perl

# SEE DEBIAN CHANGELOG FOR NEWER ENTRIES

# mail-expire, Version 0.2; Fri, 16 Aug 2002 11:39:10 +0200
# Copyright: Eduard Bloch <[EMAIL PROTECTED]>
#
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details. The full text of GPL can be
# found on http://www.gnu.org or in /usr/share/common-licenses/GPL on
# modern Debian systems.
#
# --
# If you make changes to this script, please forward the new 
# version to <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]>
# --
# 
# REQUIRED PACKAGES:
#
# libcompress-zlib-perl - Perl module for creation of gzip files 
# libdate-calc-perl - Perl library for accessing dates
# 
# Changes by Johannes Kolb:
#  * use Date::Calc instead of Date::Manip to increase performance
#  * no buffering of whole mailbox-files in memory
#
# Changes by Florian Krohs <[EMAIL PROTECTED]>
#  * append old mails to mailbox.month_year.gz
#  * added zlib to free some space:]
#
# Changes by Eduard Bloch <[EMAIL PROTECTED]>
#  * small hack to vary the output filename to prevent overwritting
#  * some cosmetics, fixed typos
#  * dropped silly size comparison, trust return values of syswrite

use strict;

my $target="./";

sub help {
die "Usage: $0 [ options ] DAYS FILES
where
DAYS is an integer specifying the maximum age of a mail in days and
FILES one or more mbox file(s).

Options:
-uchoose different filenames if the target file already exists
--delete  drops the old messages. Be warned, no backup will be made!
--dry-run Just print what it would do, no real action
-t DIRnew target directory DIR

";
}

use Getopt::Long qw(:config no_ignore_case bundling pass_through);
my $uoption=0;
my $deloption=0;
my $dry_run=0;
my $help;

my %opts = (
"t=s", \$target, 
"delete", \$deloption,
"dry-run", \$dry_run,
"help|h", \$help,
"u", \$uoption
);

&help if !GetOptions(%opts);
&help if $help;
my $days=shift(@ARGV);
die "Please specify a valid day count!\n" if abs($days)<1;
die "Please specify mbox file names!\n" if ! @ARGV;
for(@ARGV) { 
die "Unable to read $_\n" if not -r $_
};

use Date::Calc qw(Parse_Date Today Delta_Days);
use Compress::Zlib ;
use Fcntl;
use Mail::Mbox::MessageParser;

my $c=-1;
my @today = Today();
my $old_all = localtime(time - $days * 86400);
$old_all =~ s/\ +/\ /g;
my @splitdate=split(/\ /,$old_all);
my $olddate=$splitdate[1] . "_" . $splitdate[4] . ".gz";

JOB: 
foreach my $filename (@ARGV) {
my @st;
my @time;
my $c;

my $oldsize = (stat($filename))[7];
if ($oldsize == 0) {
syswrite(STDOUT,"Empty file $filename, skipping.");
next JOB;
};

if(-e "$filename.new")
{ 
syswrite(STDOUT,"Temporary file $filename.new already exists, skipping 
$filename.\n");
next JOB;
};

if(!open(fh,$filename)) {
syswrite(STDOUT,"$filename could not be opened, skipping");
next JOB;
};
if(flock(fh,2|4)){
# lock when no

Bug#362885: closed by David Nusinow <[EMAIL PROTECTED]> (Re: Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty)

2006-05-15 Thread Eduard Bloch


reopen 362885
thanks


#include 

> > BTW, I'm reopening this bug: Making a symlink is bogus since
> > dpkg removes it when one removes a package that contains files
> > in /usr/X11R6/bin. Otherwise, x11-common should make sure that
> > the symlink remains (if possible).
> 
> We've found a good solution for this bug. It's closed unless you can find a
> way and submit a patch that reliably fixes the issues mentioned by Steve in
> this bug report. I invite you to do so, but in the meantime, the current
> solution, though awkward and a little annoying, will ensure that we don't
> mangle other packages.

Sorry, but what about our issues (wearing my user hat)? Steve presented
the technical problems. I agree there. I have suggested to create a
user-friendly interface to this problem and got no answer.

So would please anyone answer to this question before closing the
bugreport another time? Read:

What do you think about adding a debconf config screen, doing:

 - scan the old directory to get a list of packages
 - weed out filenames that would be removed by dpkg
 - present a list to the user, saying what the remaining files are and
   where they do come from (package names to be easily removed by $user)
 - retry or abort button

Note that this would happen in the preconfiguration step so no
dist-upgrade run will be suddenly killed by your current "solution".

So, would that be appropriate? Should I implement that?

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362885: closed by David Nusinow <[EMAIL PROTECTED]> (Re: Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty)

2006-05-15 Thread Eduard Bloch

#include 
* Vincent Lefevre [Mon, May 15 2006, 11:33:35AM]:
> On 2006-05-15 09:06:33 +0200, Eduard Bloch wrote:
> >  - present a list to the user, saying what the remaining files are and
> >where they do come from (package names to be easily removed by $user)
> 
> The user can remove these packages. But this is not sufficient,
> as the user could re-add them later. For instance:
> 
> $ ll /usr/X11R6
> total 8
> lrwxrwxrwx 1 root root8 2006-05-15 04:37:15 bin -> /usr/bin/
> drwxr-xr-x 3 root root 4096 2006-05-04 15:53:51 include/
> drwxr-xr-x 3 root root 4096 2006-05-04 16:01:19 lib/
> # dpkg -i opera_9.0-20060411.6-shared-qt_en_etch_i386.deb
> $ ll /usr/X11R6
> total 8
> lrwxrwxrwx 1 root root8 2006-05-15 04:37:15 bin -> /usr/bin/
> drwxr-xr-x 3 root root 4096 2006-05-04 15:53:51 include/
> drwxr-xr-x 3 root root 4096 2006-05-04 16:01:19 lib/
> 
> At this point there's no problem. But:
> 
> # dpkg --purge opera
> $ ll /usr/X11R6
> total 8
> drwxr-xr-x 3 root root 4096 2006-05-04 15:53:51 include/
> drwxr-xr-x 3 root root 4096 2006-05-04 16:01:19 lib/
> 
> The symbolic link has disappeared. IMHO, the problem is that x11-common

Indeed. AFAICS that is because the symlink is not part of the x11-common
package and is created on-the-fly. Another reason why the current
solution sucks.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#365151: libmail-mbox-messageparser-perl: message splitting breaks

2006-05-21 Thread Eduard Bloch

#include 
* David Coppit [Sun, May 21 2006, 01:05:29PM]:

> Today I have released Mail::Mbox::MessageParser version 1.4003, which
> incorporates Eduard Bloch's patch for the "grepmail returning all emails"
> bug.
> 
> Many thanks to all involved.

It was not my patch, kudos to the creator (JoeyH, AFAICS).

Have a nice day,
Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#339259: rlog: patch for c2a-transition

2005-11-25 Thread Eduard Bloch

#include 
* Stefan Potyra [Fri, Nov 25 2005, 04:19:31AM]:
> Package: rlog
> Followup-For: Bug #339259
> 
> Hi,
> 
> thanks for maintaining this package.
> Attached is a small patch for c2a-transition. Please also remove/rename
> debian/librlog1c2.install (new should be librlog1c2a.install, as seen
> in the patch).

Well, patches are not the problem, I have the package already. But I
cannot release it because it breaks encfs and I cannot upgrade encfs
because it does not build with current fuse.

But I guess you don't need to care about that on Ubuntu, you just
upgrade fuse as needed.

Eduard.

-- 
 Abgesehen davon,, 
 000
 Abgesehen davon, dass er eh sau langsam ist.
 Und mein Kater auf der Tastatur herumklettert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#341248: [sarge] bogus "Filesystem would be destroyed" message

2005-11-29 Thread Eduard Bloch

Package: lilo
Version: 22.6.1-6.2
Severity: grave

Hello,

I had problems upgrading an (almost) regular Woody system to Sarge
(bailed out in postinst, which is better than silent failure, though).

And its lilo version still has problems. Look:

netquarter:/# lilo
Fatal: Filesystem would be destroyed by LILO boot sector: /dev/hdc1
netquarter:/# lilo -v5
LILO version 22.6.1, Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2004 John Coffman
Released 17-Nov-2004, and compiled at 12:32:32 on May 25 2005
Debian GNU/Linux

raid_setup: dev=1602  rdev=1601
raid_setup returns offset =   ndisk = 0
 BIOS   VolumeID   Device
Reading boot sector from /dev/hdc1
geo_get: device 1601, all=1
pf_hard_disk_scan: (22,0) /dev/hdc
pf_hard_disk_scan: (22,1) /dev/hdc1
lookup_dev:  number=1600
lookup_dev:  number=1600
pf:  dev=1600  id=  name=/dev/hdc
geo_query_dev: device=1600
lookup_dev:  number=1600
lookup_dev:  number=0300
exit geo_query_dev
bios_dev:  device 1600
Warning: Int 0x13 function 8 and function 0x48 return different
head/sector geometries for BIOS drive 0x80
fn 08: 1024 cylinders, 255 heads, 63 sectors
fn 48: 29765 cylinders, 16 heads, 63 sectors
lookup_dev:  number=1600
bios_dev:  masked device 1600, which is /dev/hdc
bios_dev: geometry check found 0 matches
bios_dev: (0x80)  vol-ID=  *PT=08078DAE
bios_dev: PT match found 1 match (0x80)
NT partition: /dev/hdc 1 /dev/hdc1
pf_hard_disk_scan: (22,2) /dev/hdc2
pf_hard_disk_scan: (22,3) /dev/hdc3
pf_hard_disk_scan: (22,4) /dev/hdc4
pf_hard_disk_scan: (22,5) /dev/hdc5
pf_hard_disk_scan: (22,6) /dev/hdc6
pf_hard_disk_scan: (22,7) /dev/hdc7
pf_hard_disk_scan: (22,8) /dev/hdc8
pf_hard_disk_scan: (22,9) /dev/hdc9
  1600    /dev/hdc
pf_hard_disk_scan: ndevs=1
  1600    /dev/hdc
Resolve invalid VolumeIDs
Resolve duplicate VolumeIDs
  1600    /dev/hdc
device codes (user assigned pf) = 1
device codes (user assigned) = 1
device codes (BIOS assigned) = 1
device codes (canonical) = 1
geo_query_dev: device=1601
lookup_dev:  number=1601
exit geo_query_dev
bios_dev:  device 1601
lookup_dev:  number=1600
bios_dev:  masked device 1600, which is /dev/hdc
bios_dev: geometry check found 0 matches
bios_dev: (0x80)  vol-ID=  *PT=08078DAE
bios_dev: PT match found 1 match (0x80)
Device 0x1601: BIOS drive 0x80, 255 heads, 1867 cylinders,
   63 sectors. Partition offset: 63 sectors.
registering bios=0x80  device=0x1601
Using Volume ID  on bios 80
part_verify:  dev_nr=1601, type=1
geo_get: device 1600, all=1
geo_query_dev: device=1600
lookup_dev:  number=1600
exit geo_query_dev
bios_dev:  device 1600
lookup_dev:  number=1600
bios_dev:  masked device 1600, which is /dev/hdc
bios_dev: geometry check found 0 matches
bios_dev: (0x80)  vol-ID=  *PT=08078DAE
bios_dev: PT match found 1 match (0x80)
Device 0x1600: BIOS drive 0x80, 255 heads, 1867 cylinders,
   63 sectors. Partition offset: 0 sectors.
registering bios=0x80  device=0x1600
Using Volume ID  on bios 80
lookup_dev:  number=1600
part_verify:  part#=1
Fatal: Filesystem would be destroyed by LILO boot sector: /dev/hdc1
netquarter:/# lilo -P ignore
Fatal: Filesystem would be destroyed by LILO boot sector: /dev/hdc1
netquarter:/# lilo -F
WARNING: '-F' override used. Filesystem on  /dev/hdc1  may be destroyed.

Proceed? [N/y]y
Added Linux *
Skipping /vmlinuz.old
Added Linux(hdc1)
You have new mail in /var/mail/root
netquarter:/# umount /boot 
netquarter:/# mount /boot/

The filesystem is still allright. No wonder, it is a pure ext2 FS.
netquarter:/# mount 
...
/dev/hdc1 on /boot type ext2 (rw)

The only problem I can see is that this system has been migrated from Windows
environment and I assume that hdc1 has been a windows boot partitition in the
past because "strings" shows me typical messages in the bootblock, created by
the format.exe utility from german Windows 9x.

However, no such problems appeared while Woody has been installed on that box
few years ago.

I will attach lilo.conf and the bootblock from hdc1 to this report.

Eduard.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.2
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages lilo depends on:
ii  debconf  1.4.59  Debian configuration management sy
ii  libc62.3.5-8.1   GNU C Library: Shared libraries an
ii  libdevmapper1.01 2:1.01.05-1 The Linux Kernel Device Mapper use

lilo recommends no packages.

-- debconf information excluded

-- 
* Alfie hätte auch gerne was von dem, was Joey geraucht hat, als er das
geschrieben hat...
# /etc/lilo.conf - See: `lilo(8)' and `lilo.conf(5)',
# ---   `install-mbr(8)', `/usr/share/doc/lilo/',
#   and `/u

Bug#339688: any ETA for this bug?

2005-12-16 Thread Eduard Bloch

Hello,

this bug is blocking some development. I have heard about troubles with
user management in fuse-utils but this should not prevent other package
upgrades. In my case it blocks the latest C++ transition.

I plan to NMU fuse with the new version and maybe some obvious fixes
before this year ends!

Eduard.
-- 
Delenn: We are star stuff. We are the universe made manifest trying to figure
itself out.
 -- Quotes from Babylon 5 --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-03-21 Thread Eduard Bloch

#include 
* Joerg Schilling [Mon, Mar 20 2006, 11:21:30PM]:

> It seems that you never did read and understand the GPL :-(
> 
> The GPL is as holey as a Swiss cheese when talking about the compile
> environment:

...

Joerg, could you please stay ontopic and not flame? We try to discuss
with you...
And we *do* understand the GPL, and its not only one interpretation of
the GPL. You can read our -legal list too see much more of that, please
look at [URLS] for more information.

Also there is AFAICS nobody happy with your efforts to restrict the GPL
claiming that it gives you means to force everybody do things
unrelated to GPL§2c (slandering about Linux in control output, for
example). Neither does anything give you means to forbid us the
replacement of license-incompatible files with GPL compatible versions.

And finally, in the last mail I have already presented the exact chain
of conclusions, including the intent of the OP. I expect you (as
programmer knowing how logic works) to be able to find the wrong link
there -- so would you consider answering this (uncomfortable) question?

URLS:
http://lists.debian.org/debian-legal/2006/03/msg00362.html
http://lists.debian.org/debian-legal/2006/03/msg00391.html
http://lists.debian.org/debian-legal/2006/03/msg00375.html
http://lists.debian.org/debian-legal/2006/03/msg00376.html

> If you would understand enough from the topic, you would understand that
> the "related" makefiles of my software are always present under the same
> license as the rest of the project but the unrelated (because project 
> indepentent) makefilesystem is just available under it's native license.

Somehow all our other GPLed software has "related build software" either
licensed under GPL compatible license (*) or beeing that far different that
its maker can declare the outcome as a product rather than a derivate
(compilers).

Eduard.

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-03-21 Thread Eduard Bloch

#include 
* Eduard Bloch [Tue, Mar 21 2006, 05:32:17PM]:

> And finally, in the last mail I have already presented the exact chain
> of conclusions, including the intent of the OP. I expect you (as
> programmer knowing how logic works) to be able to find the wrong link
> there -- so would you consider answering this (uncomfortable) question?

PS: 

Also please state which license does actually cover the cdrecord
source.

If I remember correctly, our consens was that we keep displaying of the
copyright and code change notice which _may_ be explained with GPL §2.c
but you have to change the restrictions to
recommendations/explanations. However, in the current versions I
discovered again:

/*
 * Warning: you are not allowed to modify or to remove this
 * version checking code!
 */
vers = scg_version(0, SCG_VERSION);
auth = scg_version(0, SCG_AUTHOR);
printf("Using libscg version '%s-%s'.\n", auth, vers);
if (auth == 0 || strcmp("schily", auth) != 0) {
errmsgno(EX_BAD,
"Warning: using inofficial version of libscg (%s-%s 
'%s').\n",
auth, vers, scg_version(0, SCG_SCCS_ID));
}

This is a GPL-incompatible restriction. There is nothing in §2c that
forces the derivates to display every single change when executing a
program (or even worse - merge that output with regular non-interactive
program output or call such notes "Warnings").

Can you explain that please?

Assuming it is not the GPL, can you tell us which license you use?  And
also: have you made sure that all recent changes come from sources that
are aware about the license change? And that there is no code in the
gpl-incompatible files that is written by someone else?

Eduard.

Bug#358512: linux-headers-2.6.16-1-686-smp: kernel-headers seems to contain unconfigured kernel

2006-03-22 Thread Eduard Bloch

#include 
* Mau [Thu, Mar 23 2006, 01:01:22AM]:
> Package: linux-headers-2.6.16-1-686-smp
> Version: 2.6.16-1
> Severity: grave
> Justification: renders package unusable
> 
> 
> probably a bug in this package - module-assistant says 'Warning,
> /usr/src/linux-headers-2.6.16-1 seems to contain unconfigured kernel source!'

Yes, version.h is missing. I told Sebastian already and he assured is it
there. But that is not what "ls /usr/src/linux-headers-2.6.16-1/include"
says.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#358512: linux-headers-2.6.16-1-686-smp: kernel-headers seems to contain unconfigured kernel

2006-03-23 Thread Eduard Bloch

#include 
* Jurij Smakov [Wed, Mar 22 2006, 06:43:28PM]:
> On Thu, 23 Mar 2006, Eduard Bloch wrote:
> 
> >#include 
> >* Mau [Thu, Mar 23 2006, 01:01:22AM]:
> >>Package: linux-headers-2.6.16-1-686-smp
> >>Version: 2.6.16-1
> >>Severity: grave
> >>Justification: renders package unusable
> >>
> >>
> >>probably a bug in this package - module-assistant says 'Warning,
> >>/usr/src/linux-headers-2.6.16-1 seems to contain unconfigured kernel 
> >>source!'
> >
> >Yes, version.h is missing. I told Sebastian already and he assured is it
> >there. But that is not what "ls /usr/src/linux-headers-2.6.16-1/include"
> >says.
> 
> No, it is not missing. As mentioned in the description of 
> linux-headers-2.6.16-1 package, to obtain a complete set of headers you 
> need to do

Oh, sorry, just wrong command line quote.

I have also checked in other dirs. -k7 does not have it, I have a
similar bug report against m-a.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-03-26 Thread Eduard Bloch

#include 
* Joerg Schilling [Wed, Mar 22 2006, 03:16:26PM]:
> Eduard Bloch <[EMAIL PROTECTED]> wrote:
> 
> > #include 
> > * Joerg Schilling [Mon, Mar 20 2006, 11:21:30PM]:
> >
> > > It seems that you never did read and understand the GPL :-(
> > > 
> > > The GPL is as holey as a Swiss cheese when talking about the compile
> > > environment:
> >
> > ...
> >
> > Joerg, could you please stay ontopic and not flame? We try to discuss
> > with you...
> 
> Sorry, I definitely did not flame but I don't have impression
> that you are intrested in a discussion!
> 
> So please reply to my mail instead of adding unrelated new stuff.

Well, why do you not reply to my mail first instead of stripping
everything away including the uncomfortable but pretty relevant
questions?

Why do you think that you are the only one allowed to give the
direction of the discussion? How should we get the answers for the
actual topic if you avoid giving them?

> > And we *do* understand the GPL, and its not only one interpretation of
> > the GPL. You can read our -legal list too see much more of that, please
> > look at [URLS] for more information.
> 
> Sorry, but the way you are arguing shows that you obviously have problems
> to understand the GPL.

As said before, our understanding of the GPL conforms with what most
Debian developers think. Why do you think that your "interpretation" is
the only valid one? 

> > Please tell me why you are trying to use the "majestetis pluralis"?

Of course: because I consulted our internal cdrtools maintainer group
and I am also refering to the comments of debian-legal people. I am not
your lone crazy opponent.

>  Unrelated stuff removed *
> 
> > And finally, in the last mail I have already presented the exact chain
> > of conclusions, including the intent of the OP. I expect you (as
> > programmer knowing how logic works) to be able to find the wrong link
> > there -- so would you consider answering this (uncomfortable) question?
> >
> > URLS:
> > http://lists.debian.org/debian-legal/2006/03/msg00362.html
> 
> The person did not understand the GPL and is writing unrelated stuff.

So your only explanation is that most people out there did not
understand the GPL while you do? Even if we explain to you in detail how
we believe the GPL should be interpreted? Giving the best opportunity to
demonstrate the inconsistencies or wrong conclusions in this explanation?

> See my last mail for more information.

It did not contain anything new, you are repeating your views and
"interpretations" but that does do not make them more true or valid.

> > http://lists.debian.org/debian-legal/2006/03/msg00391.html
> 
> Unrelated to our discussion.

Indeed, it adresses another problem with the cdrecord source, but the
issue is not that different. The presense of GPL-incompatible invariant
sections is well related to our discussion. Since you seem to have read
read our official guidelines, DFSG and the Social Contract I guess you
know that "we do not hide problems" is one of the primary principles
there. We consider incompatible license mixtures to be a such problem.
For the cdrtools package, we can only state:

Either it is GPL or it is not, we do not accept incompatible mixtures.
Like restrictions hidden somewhere in the code like a wulf in sheep's
clothing.

Please stop telling us that all your license modifications can be fully
explained with a valid interpretaton of the GPL. None of the supposed
holes in its wording gives enough room for making such obfuscated
"interpretations", you can hardly convince anyone of the validity of
such claims (and not of an artificially created restrictions). You do
not even care about showing any good precedent case when calling GPL
"holey as a Swiss cheese".

> > http://lists.debian.org/debian-legal/2006/03/msg00376.html
> 
> This is what I did explain in my last mail!
> 
> Why don't you read my last mail?

Why don't you read mine before? I doubt you will answer this honestly so
I repeat the things said there:

|-   It requires scripts to be present, but makefiles are no scripts,
|they are just code in a different language.

The common definition for "script" is a list of connected commands
interpreted by a native application. Even much more sophisticated
languages like Perl/Python/... interpret files called scripts (referring to 
their
documentation). Your "code" is written in plain text, containing mostly
program invocations or closely related instructions, and the whole thing
is interpreted by a native application. Everything required for beeing
declared as "script" in terms of GPL is there.

|-   Sources ba

Bug#358512: linux-headers-2.6.16-1-686-smp: kernel-headers seems to contain unconfigured kernel

2006-03-27 Thread Eduard Bloch

reassign 358512 module-assistant
thanks

#include 
* Jurij Smakov [Thu, Mar 23 2006, 09:42:39AM]:
> On Thu, 23 Mar 2006, Eduard Bloch wrote:
> 
> >#include 
> >* Jurij Smakov [Wed, Mar 22 2006, 06:43:28PM]:
> >>On Thu, 23 Mar 2006, Eduard Bloch wrote:
> >>>
> >>>Yes, version.h is missing. I told Sebastian already and he assured is it
> >>>there. But that is not what "ls /usr/src/linux-headers-2.6.16-1/include"
> >>>says.
> >>
> >>No, it is not missing. As mentioned in the description of
> >>linux-headers-2.6.16-1 package, to obtain a complete set of headers you
> >>need to do
> >
> >Oh, sorry, just wrong command line quote.
> >
> >I have also checked in other dirs. -k7 does not have it, I have a
> >similar bug report against m-a.
> >
> >Eduard.
> 
> I've just checked the linux-headers-2.6.16-1-k7_2.6.16-1_i386.deb package, 
> and version.h *is* included in it:
> 

Hm, okay, sorry for the noise. I guess my version checking is to
paranoid and should consider linux-headers-* as a half-installation and
ignore it.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-04-01 Thread Eduard Bloch

#include 
* Joerg Schilling [Mon, Mar 27 2006, 06:13:06PM]:
> Eduard Bloch <[EMAIL PROTECTED]> wrote:
> 
> Da es offenbar Missverstaendnisse gibt und English fuer das Diskutieren
> von Lizenz/Urherberrechtsproblemen nicht geeignet ist (anderes Rechtssystem)
> nun in einer Sprache die jeder versteht

Okay, in the last mail we have seen a switch to the German language supposedly
in order to express things more compatible to German jurisdiction. After
another round of this "discussion" with the major tone becoming more abrasive
and close to a legal threat, I have to publicaly state that none of my
critics are to be understood as an accusal of breach of contract
(Vertragsverletzung) under the terms of German jurisdiction.

Since any statement not conforming with Joergs interpretation of GPL can be
understood of a such imputation and therefore lead to a legal lawsuit, I
refrain from making public statements to this dicussion (as stored in the
Debians Bug Report page 350739). And I am posting the following disclaimer
(rough translation from German without any claim of beeing correct).

I:

Since GPL is an American license and no complete AND binding (within German
jurisdiction) translation is known to me, I have to admit that (within German
jurisdiction unless proven differently by an official court) the separation of
the cdrtools archive into separate works ("Werke") may be valid consequence of
a possible GPL interpretation. 

II: Separation of Works

Using this interpretation, the contents of "cdrtools" can be understood as a
collection of separate works, with separate parts of intellectual property. The
ownership of the particular works has to be determined from the contents of
each file containing the appropriate notes about autor(s), copyright and
license information.

III:

Therefore, no contract breachment can be assumed (under the terms of the
mentioned interpretation and according to German laws).

The validity of GPL§3 must be considered in the context of each particular work
(as following Joerg's Interpretation) and with respect to the applicability of
the wording of GPL under the terms of the German jurisdiction, as mentioned
above.

IV:

Even under more stronger interpretations of GPL in context of further works
contained inside of the cdrtools archive and having other copyright owners, the
requirements of GPL can be full-filled since the means required to translate
the source code into machine-executable form can either be created in a trivial
way or are already made public by Joerg Schilling, for example in previous
versions of cdrtools, or have been made available by original authors under the
terms of GPL §2.

GERMAN TEXT:

Damit im Laufe der Diskussion kein Eindruck des Vorwurfs einer
Vertragsverletztung seitens Joerg Schilling entsteht, stelle ich hiermit
folgendes fest:

Im Rahmen der Anwendbarkeit des deutschen Rechtssystems und im Kontext dieses
Falls und sofern keiner der Aussagen durch ein ordentliches Gericht
widersprochen wird, kann von folgenden Tatsachen und der folgenden Auslegung
der GNU General Public License ausgegangen werden:

Punkt 1:

Der Vertrieb der Software cdrtools im gleichnamigen Software-Archiv kann als
eine Zusammenstellung von Werken betrachtet werden. Mit dieser Sichtweise
gelten folgende Punkte:

Punkt 2:

Unter der oben genannten Auslegung kann das Archiv cdrtools als ein
Medium (im Sinne der GPL) verstanden werden. Dies beinhaltet mehrere
Werke (Dateien), deren Lizenzierungsart und Angabe des Autors bzw. der
Autoren in den entsprechenden Vermerken im Inhalt der jeweiligen Datei
zu finden ist.  

Punkt 3:

Die Vorgaben der GPL-Lizenz (Version 2) im Paragraph 3 können keine absolut
genaue Auskunft darüber geben, welche Teile des Archives cdrtools als zum
Übersetzen (compilation) notwendige Komponenten zu betrachten sind. Mangels
einer verbindlichen Adoptierung der GPL in der deutschen Rechtssprechung
kann hierüber keine eindeutige Aussage getroffen werden.

Punkt 4:

Es liegt ebenfalls keine Vertragsverletzung beim Vertrieb weiterer sich im
Archiv cdrtools befindlichen Werke vor, deren Rechteinhaber aus mehr als
einer Person (Joerg Schilling) bestehen. Auch unter der strengen
Interpretation des Paragraphen 3 der GPLv2 (siehe Punkt 3) kann nicht von
einer Verletzung der Vorgaben der Paragraphen 2 und 3 ausgegangen werden,
weil die Voraussetzungen zum Übersetzen der Werke entweder auf triviale
Weise hergestellt werden können oder die notwendigen Komponenten von Joerg
Schilling bereits öffentlich zugänglich gemacht wurden, unter anderem in
vorherigen Versionen des Archives cdrtools.

Alle weitergehende Forderungen müssen bezüglich der Anwendbarkeit der GPL im
Rahmen des deutschen Urheberrechts überprüft werden.

MfG,
Eduard.

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-04-01 Thread Eduard Bloch

#include 
* Joerg Schilling [Sat, Apr 01 2006, 04:46:48PM]:
> Eduard Bloch <[EMAIL PROTECTED]> wrote:
> 
> Thank you for this clarification.
> 
> Unfortunately it does not include a translation for an important part found 
> in 
> the German text:

The translation has been sent to you and did not receive any comments
for this part. And I have the impression that we did already agree on
the interpretation of part four in German. Explicitely, I keep repeating
that this part is meant for the _strong interpretation_ (AS WRITTEN
THERE), that is the one of the OP and the one that people on
debian-legal seem to agree on but the interpration that you do not
consider as valid.

Your interpretation may be valid, therefore I cannot blame you for
license violation without hard proof valid in our (German) law system.

> > Punkt 4:
> >
> > Es liegt ebenfalls keine Vertragsverletzung beim Vertrieb weiterer sich im
> > Archiv cdrtools befindlichen Werke vor, deren Rechteinhaber aus mehr als
> > einer Person (Joerg Schilling) bestehen. Auch unter der strengen
> > Interpretation des Paragraphen 3 der GPLv2 (siehe Punkt 3) kann nicht von
> > einer Verletzung der Vorgaben der Paragraphen 2 und 3 ausgegangen werden,
> > weil die Voraussetzungen zum Übersetzen der Werke entweder auf triviale
> > Weise hergestellt werden können oder die notwendigen Komponenten von Joerg
> > Schilling bereits öffentlich zugänglich gemacht wurden, unter anderem in
> > vorherigen Versionen des Archives cdrtools.
> 
> It is important to know that the part of the text from the OP ( from GPL §3) 
> cannot be set in relation to GPL §2. 
> 
> While GPL §3 requires the "scripts" used to control compilation and 
> installation of the executable to be included in the source, GPL §3 does 
> definitely not require them to be made available under GPL. 

Joerg, if you want to see that this way, see it that way. If you see it
that way, that it is your right and it should be seen that way and then
you are right (unless someone can proof any claims in a court).

> GPL §2 does not define these scripts to be part of the "work".
> 
> In fact, the "Schily makefile system" is a different work that is used 
> unmodified by many other works.

Yes, it may be a separated work, as said in II. We have discussed II and
you agreed. What is still needed to please you? 

> In addition, the Makefiles are no "scripts" but a program written in a 
> non-algorithmic prgramming language.

Deciding that is not my beer. And if you prefer hunting the messengers,
critism of your attitude may bring me into legal trouble faster than
achieving any success. You can forbid me saying things, not thinking
them.

Eduard.

Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty

2006-04-16 Thread Eduard Bloch

Package: x11-common
Version: 1:7.0.11
Severity: serious

Hello,

I cannot upgrade the package on my system because it repeatedly fails
with:

rmdir: /usr/X11R6/bin: Directory not empty
x11-common postinst error: Could not remove /usr/X11R6/bin. Is not yet
empty
dpkg: error processing x11-common (--configure):
 subprocess post-installation script returned error exit status 74
 Errors were encountered while processing:
  x11-common
  E: Sub-process /usr/bin/dpkg returned an error code (1)


Well, yes, there is one remaining file added manually by me, however the
postinst should not rely on that and fail otherwise.

Eduard.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages x11-common depends on:
ii  debconf [debconf-2.0] 1.4.72 Debian configuration management sy
ii  debianutils   2.15.5 Miscellaneous utilities specific t
ii  laptop-detect 0.12.1 attempt to detect a laptop
ii  lsb-base  3.1-3  Linux Standard Base 3.1 init scrip

x11-common recommends no packages.

-- debconf information:
  x11-common/xwrapper/allowed_users: Console Users Only
  x11-common/experimental_packages:
  x11-common/xwrapper/actual_allowed_users: console
  x11-common/xwrapper/nice_value/error:
  x11-common/xwrapper/nice_value: 0


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty

2006-04-16 Thread Eduard Bloch

#include 
* Steve Langasek [Sun, Apr 16 2006, 01:19:35AM]:
> On Sun, Apr 16, 2006 at 09:47:29AM +0200, Eduard Bloch wrote:
> 
> > I cannot upgrade the package on my system because it repeatedly fails
> > with:
> 
> > rmdir: /usr/X11R6/bin: Directory not empty
> > x11-common postinst error: Could not remove /usr/X11R6/bin. Is not yet
> > empty
> > dpkg: error processing x11-common (--configure):
> >  subprocess post-installation script returned error exit status 74
> >  Errors were encountered while processing:
> >   x11-common
> >   E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> > Well, yes, there is one remaining file added manually by me, however the
> > postinst should not rely on that and fail otherwise.
> 
> To expand on Daniel's closure message:  X11R6 is dead, and this directory
> needs to be removed so it can be replaced with a compatibility symlink.
> Otherwise, the transition path gets much uglier as we try to track down
> one-by-one all the tools that reference /usr/X11R6/bin as an absolute path
> between now and etch's release.
> 
> So if the file in /usr/X11R6/bin comes from an official package, please tell
> us the package so x11-common can conflict with it.  If it's an unofficial

It was not from an official package. And it was a symlink, so dealing
with it is a bit more complicated. Anyhow, I wonder what exactly do we
win by trying to remove this directory. What is the problem with just
letting where it is and allow it to rot untill the last package having
files there is removed. This is the strategy used by dpkg since ages,
why should we try to nuke that directory, just for cosmetics reasons?

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty

2006-04-17 Thread Eduard Bloch

#include 
* Steve Langasek [Sun, Apr 16 2006, 04:58:25PM]:

> If you ask me, I think it's better to keep the vast majority of irritating
> bugs confined to unstable, and only make users of stable deal with the
> single issue of moving their files out of /usr/X11R6/bin; which is why I
> asked David to implement this transition when it became clear that things
> were breaking because of the move to /usr/bin.

I agree with most of your arguments, especially because our default bash
PATH is still pointing to /usr/X11R6/bin, but there is one thing which I
actually reported...  if there is cruft remaining in the directory, the
whole upgrade should _not_ break.

Implementing an unsafe single "rmdir" and hope that it won't
fail is IMO not a proper solution.  If the directory must be moved out
of the way, then it should be renamed. Or the old contents need to be
moved to the new location, possible correcting symlinks (tell me if you
wish me to write a perl script to implement this reallocation, I wanted
to do that anyway).

And sorry if I repeated something already reaported and you needed to
repeat answers, but the problems are there, and there would be much less
bug reports if we had a d-d-a announcement, etc.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty

2006-04-18 Thread Eduard Bloch

#include 
* Steve Langasek [Mon, Apr 17 2006, 08:58:38PM]:
> On Mon, Apr 17, 2006 at 09:51:58AM +0200, Eduard Bloch wrote:
> > #include 
> > * Steve Langasek [Sun, Apr 16 2006, 04:58:25PM]:
> 
> > > If you ask me, I think it's better to keep the vast majority of irritating
> > > bugs confined to unstable, and only make users of stable deal with the
> > > single issue of moving their files out of /usr/X11R6/bin; which is why I
> > > asked David to implement this transition when it became clear that things
> > > were breaking because of the move to /usr/bin.
> 
> > I agree with most of your arguments, especially because our default bash
> > PATH is still pointing to /usr/X11R6/bin, but there is one thing which I
> > actually reported...  if there is cruft remaining in the directory, the
> > whole upgrade should _not_ break.
> 
> > Implementing an unsafe single "rmdir" and hope that it won't
> > fail is IMO not a proper solution.  If the directory must be moved out
> > of the way, then it should be renamed. Or the old contents need to be
> > moved to the new location, possible correcting symlinks
> 
> Er, any number of these files may belong to other Debian packages that we
> don't conflict with (because we didn't know about them).  Why would it be ok
> for a package to mangle files belonging to other packages in this fashion?

Okay...

> If you move the files, dpkg may be unable to find them at package
> uninstallation, resulting in orphaned files on the filesystem; or there may

Not 100% correct. The problem of deinstallation is covered with the
symlink workaround since dpkg AFAICS follows the symlinks in the path
when removing a file.

It's only the other way round that does create headaches, future
installations of third-party packages which may try to install files
into X11R6/bin and may overwrite files from other packages. I thought
a while about that and could not come up with any sane solution, not
even hacking dpkg's .list files would help because of missing
information. Only blacklisting this directory in dpkg would have been a
"good" solution but it's too late for that.

> Forcing the user to deal with the conflict is the only safe way of handling
> files left in /usr/X11R6/bin.  It should probably be turned into a debconf
> note later on, but for the time being I think the current behavior is as
> good as it's going to get.

"safe" does not mean reliable or usefriendly. I still think that the
current lone "rmdir" hidden in the postinst is not sufficient. What we
need is IMO a list of "dirty" files - files that have existed in Debian
in X11R6/bin directory before and which would certainly be uninstalled
by apt/dpkg during the upgrade. The debconf's config script should be
executed during dpkg-preconfigure (NOTE: not in the middle of upgrade!),
scan the existing /usr/X11R6/bin directory, substract the set of "dirty"
files and if there are still remaining files in the list, then the user
should be given a chance to abort the whole installation before it
starts. And a list of remaining files should be printed. Maybe together
with 3rd-party packages that those files may belong to.

If you wish me to implement a such solution, please say "do it" and I
will try to.

Eduard.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362885: x11-common: unable to upgrade, rmdir: /usr/X11R6/bin: Directory not empty

2006-04-20 Thread Eduard Bloch

#include 
* Steve Langasek [Tue, Apr 18 2006, 01:41:08PM]:
> On Tue, Apr 18, 2006 at 12:14:25PM +0200, Eduard Bloch wrote:
> 
> > > If you move the files, dpkg may be unable to find them at package
> > > uninstallation, resulting in orphaned files on the filesystem; or there 
> > > may
> > 
> > Not 100% correct. The problem of deinstallation is covered with the
> > symlink workaround since dpkg AFAICS follows the symlinks in the path
> > when removing a file.
> 
> Hmm, you're assuming that we don't, at some later date (post-etch), drop the
> /usr/X11R6/bin compat symlink.  If one of these packages is removed *after*
> that point, dpkg has no way to locate the binaries in order to remove them.

I do, because otherwise we would need to make sure that /etc/profile the
user machines has the new directory in $PATH, which is not the case (for
non-root users) yet. But forcing the transition is better than keeping
it forever.

> > > Forcing the user to deal with the conflict is the only safe way of 
> > > handling
> > > files left in /usr/X11R6/bin.  It should probably be turned into a debconf
> > > note later on, but for the time being I think the current behavior is as
> > > good as it's going to get.
> > 
> > "safe" does not mean reliable or usefriendly.
> 
> As I'm using the word "safe", I do mean that it's reliable -- you reliably
> get one of two results, a successful upgrade or a message telling you that
> you need to reconcile by hand.

When it comes to the reliability of the upgrade process, I would
distuingish between the terms. Personally, one of the thing I hate are
failures in the middle of process which can have been avoided.

> > I still think that the current lone "rmdir" hidden in the postinst is not
> > sufficient. What we need is IMO a list of "dirty" files - files that have
> > existed in Debian in X11R6/bin directory before and which would certainly
> > be uninstalled by apt/dpkg during the upgrade. The debconf's config script
> > should be executed during dpkg-preconfigure (NOTE: not in the middle of
> > upgrade!), scan the existing /usr/X11R6/bin directory, substract the set
> > of "dirty" files and if there are still remaining files in the list, then
> > the user should be given a chance to abort the whole installation before
> > it starts. And a list of remaining files should be printed. Maybe together
> > with 3rd-party packages that those files may belong to.
> 
> > If you wish me to implement a such solution, please say "do it" and I
> > will try to.
> 
> If you do compile a list of files that you believe came from packages, what
> do you do with them if you find them still there when it's time to turn
> /usr/X11R6/bin into a symlink?

Then, and only then it should be allowed to stop/break, because the user
must have done nasty things in time between the moments of the
check/warning and the removal should take place (or an upgrade of his
3rd party packages, though unlikely).

I don't disagree with the current solution anymore. I just would like to
add pre-upgrade check&warning.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#319005: import fails to map .deb files to backends

2006-02-16 Thread Eduard Bloch

severity 319005 important
thanks

#include 
* Steve Langasek [Wed, Feb 15 2006, 11:03:13PM]:

> If there's a reason for this bug to be RC, it would seem to have to be
> "makes the package unusable or mostly so", since there's no policy violation
> here and there's no opinion from the maintainer recorded in the bug log. 
> And it doesn't sound like this is an "unusable or mostly so" bug.

Ok. The package looks unmaintained but this part does not affect current
users.

Eduard.

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-03-18 Thread Eduard Bloch

#include 
* Joerg Schilling [Sat, Mar 18 2006, 01:09:03PM]:
> The cdrtools distribution is compiled from several 
> different "works".
> 
> One complete and separate work is the Schily Makefilesystem.
> It is independent of a specific project and published under th CDDL.

You are free to double-license it. Look at the Perl project if you need
a "big reference".

> If you believe that the GPL is violating the Debian Social Contract
> (see http://www.us.debian.org/social_contract section 9), you should
> send an alert to the Debian Legal list.

Honestly, I think we should consider merging cdrtools package with the
one fork from the last real-GPL version (what was it... dvdrtools?) that
uses a free build system, and stop pulling JS' software. I dislike
license related surprises and even more with justification like this. 

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-03-18 Thread Eduard Bloch

#include 
* Joerg Schilling [Sat, Mar 18 2006, 04:05:49PM]:
> Eduard Bloch <[EMAIL PROTECTED]> wrote:
> 
> > #include 
> > * Joerg Schilling [Sat, Mar 18 2006, 01:09:03PM]:
> > > The cdrtools distribution is compiled from several 
> > > different "works".
> > > 
> > > One complete and separate work is the Schily Makefilesystem.
> > > It is independent of a specific project and published under th CDDL.
> >
> > You are free to double-license it. Look at the Perl project if you need
> > a "big reference".
> 
> If the GPL is a free license acording to the Debian Social Contract 
> there is no need to do this..

Joerg, please stop that. You have already proved by your recent actions
that you DO NOT understand the GPL. Don't try to justify your "claims"
with another document that is neither understood by you nor is really
your business.

> Note that the Schily Makefilesystem is a different "work" and just published
> together the rest of the cdrtools. If the GPL _really_ insists in polluting

I reallize that. Guess why I suggested double-licensing.

> _other_ software, the GPL must be considered unfree and should be banned from
> Debian.

We have already decided how far a viral license is allowed to affect
other components. GPL enforces the freedom of "poluted" software, while
your license does the opposite. If you don't think so, read and
understand the DFSG before claiming _anything_ based on its contents.
And I mean reading the whole thing, please don't cite few sentences
prooving only your point (as you like to do, IIRC).

Eduard.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-03-18 Thread Eduard Bloch

#include 
* Joerg Schilling [Sat, Mar 18 2006, 07:16:46PM]:
> Eduard Bloch <[EMAIL PROTECTED]> wrote:
> 
> > > If the GPL is a free license acording to the Debian Social Contract 
> > > there is no need to do this..
> >
> > Joerg, please stop that. You have already proved by your recent actions
> > that you DO NOT understand the GPL. Don't try to justify your "claims"
> > with another document that is neither understood by you nor is really
> > your business.
> 
> Eduard, please stop your FUD.

I see no FUD. Please look in a lexicon for the usual meaning of this
term.

> You did write (easy to proof as) false claims many times in the past.
> Just remember the case where you did call Sun Studio C "rubbish" just because
> it flags bad code that GCC let's pass.

He? I cannot remember writting this, and I would not use the word
"rubbish".

> Take it as a fact that nobody will believe you unless you proove your claims
> with real facts.

Do you have an answer robot? What exactly did I claim that could not
prooved easily or has already been prooved? Or do you refer to some old
(or even incorrect) memory, including the "rubbish Sund Studio C"
mentioned above? WTF?

> > > Note that the Schily Makefilesystem is a different "work" and just 
> > > published
> > > together the rest of the cdrtools. If the GPL _really_ insists in 
> > > polluting
> >
> > I reallize that. Guess why I suggested double-licensing.
> 
> Guess why I did suggest that you should find someone to explain you the
> background.
> 
> Have a look at http://www.us.debian.org/social_contract and try to understand
> what section 9. "License Must Not Contaminate Other Software" means:
> 
> 
> The license must not place restrictions on other software that is 
> distributed along with the licensed software. For example, the license 
> must not insist that all other programs distributed on the same medium 
> must be free software.
> 
> In our case, the "medium" is the tar archive that is used to publish cdrtools.

Hear, hear. And what does the file "COPYING" with the GPL license text
do there, in the main directory of your "medium"? Is it not supposed to
cover the whole thing, as in "placing restrictions on other software"?
YOU placed the license file there and I interpret your statement as a
direct proposal to separate the split the package into the "code" and
"build system" parts. Correct?

> But before you do that, it would make sense to think whether the claims of 
> the 
> OP make sense at all.

If you follow the extreme GPL-interpretation of the OP you are clearly
violating the GPL and any contributor to cdrtools has the right to sue
you. I do not read it that way and I know your role in the cdrtools
development, but you do not make it easy :-(

> Note that the CDDL as used for the Schily Makefilesystem gives more freedom to
> the users of the cdrtools than the other projects that are covered under the 
> GPL.

Sorry, http://www.gnu.org/licenses/license-list.html presents it in a
different light. However, it only refers to linking. I will ask our
legal group for further details.

Eduard.

-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#350739: cdrtools: GPL violation - makefiles distributed under non-GPL-compatible license??

2006-03-19 Thread Eduard Bloch

#include 
* Joerg Schilling [Sat, Mar 18 2006, 10:10:55PM]:

> > > You did write (easy to proof as) false claims many times in the past.
> > > Just remember the case where you did call Sun Studio C "rubbish" just 
> > > because
> > > it flags bad code that GCC let's pass.
> >
> > He? I cannot remember writting this, and I would not use the word
> > "rubbish".
> 
> Let me quote you:
> 
> >
>   Das behauptest du EINFACH SO, weil dein Compiler ein Paar irrevelevante 
>   Meldungen ausgespuckt hast? Amen. 
> <
> 
> Looks similar to what I had in mind.

Jeez, you have ways of finding "similarities". I would hardly translate
that as "rubbish" especially because of the context - it has been on the
same polemic levels as your claims about gcc because of beeing less
pervasive than Sun's compiler. Even then, is that all of my "false
claims" that you can find? Maybe you better your own ways of checking
the correctness of a program? I still wonder how you can declare hidding
of filename truncation "okay", for example.

Or maybe you would like to stop with digging the old graves and return
to the current issue?

> > > Have a look at http://www.us.debian.org/social_contract and try to 
> > > understand
> > > what section 9. "License Must Not Contaminate Other Software" means:
> > > 
> > > 
> > > The license must not place restrictions on other software that is 
> > > distributed along with the licensed software. For example, the 
> > > license 
> > > must not insist that all other programs distributed on the same 
> > > medium 
> > > must be free software.
> > > 
> > > In our case, the "medium" is the tar archive that is used to publish 
> > > cdrtools.
> >
> > Hear, hear. And what does the file "COPYING" with the GPL license text
> > do there, in the main directory of your "medium"? Is it not supposed to
> > cover the whole thing, as in "placing restrictions on other software"?
> > YOU placed the license file there and I interpret your statement as a
> > direct proposal to separate the split the package into the "code" and
> > "build system" parts. Correct?
> 
> ???

What is so hard to understand? If you declare your source package as
"medium" than it is okay to split it into atomic source packages with
different license, following YOUR interpretation. In this case we have a
build system package and a code package. But that code package does not
have a component required to be built, which is required by the GPL!

You may not like the conclusion but it is built from what you said. If
you wish to change that, license the whole tarball under the GPL and we
have the old situation. Or double-license that parts with GPL as
alternative (as done by perl, now we are back to my first mail).

Otherwise, we we have only few options:

 - remove cdrtools from Debian and put it into Debian/non-free
 - replace the RULES/* part with an excerpt of an older cdrtools version
 - replace the build-system with something else, autoconf version
   created in the dvdrtools fork looks quite useable

Which one do you prefer?

> > > But before you do that, it would make sense to think whether the claims 
> > > of the 
> > > OP make sense at all.
> >
> > If you follow the extreme GPL-interpretation of the OP you are clearly
> > violating the GPL and any contributor to cdrtools has the right to sue
> > you. I do not read it that way and I know your role in the cdrtools
> > development, but you do not make it easy :-(
> 
> Nice to see: Now we are back to the content of my first mail.

I don't see how.

> Iff Debian would follow the extreme GPL-interpretation of the OP, Debian would
> need to call the GPL clearly non-free because it then would violate the DFSG
> Section 9.

Now we are back to my second mail. "distribute along" either means two
separate works on the same medium or two different works. GPL does not
affect separate works which are just distributed along on the same
medium, so there is no violation of section 9 if you like the components
to be seen as separated works (if you don't, we have an case of license
inconsistency which needs to be resolved or the package becomes
unsuitable for Debian).
So if the components are to be separated, we have to do this. When we do
this, we have a CDDL component (okay, we may reuse this package for star
later), and we have a unbuildable cdrtools code package, which needs a
GPL-compatible build system (as required by the GPL).

Now please would you show me one faulty link in this chain of
conclusions. And I mean that literally, please answer without another
"because I say so and because FOO violates  and
therefore I am right".

> As Debian calls the GPL "free", the claims of the OP obviously do not
> apply from Debians view.

Sorry, who exactly is representing Debian here?

> So let us close this for now, or do you like to start an endless discussion?

We have to resolve that issue, and the length of this discussion depends
on the time where you begin to defend

Bug#365151: libmail-mbox-messageparser-perl: message splitting breaks

2006-07-09 Thread Eduard Bloch

#include 
* Volker Kuhlmann [Tue, Jun 20 2006, 11:57:29AM]:
> On Monday 22 May 2006 05:05, David Coppit wrote:
> > FYI,
> > 
> > Today I have released Mail::Mbox::MessageParser version 1.4003, which
> > incorporates Eduard Bloch's patch for the "grepmail returning all emails"
> > bug.
> 
> Thanks for letting me know David.
> 
> Although it works better than 1.4001, I have just now had a case where
> it fails as well, returning all emails as match. Version 1.20 in
> comparison works fine on the same mailbox.
> 
> I'll see that I can find the offending emails in the box.

I have another test subject, looks like the bug was not completely
fixed. Uploaded to http://people.debian.org/~blade/linux-kernel.bz2 .

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378934: mldonkey-server: postinst breaks (dpkg failure) when mlnet fails to start

2006-07-19 Thread Eduard Bloch

Package: mldonkey-server
Version: 2.7.3-2
Severity: grave

(Reading database ... 147973 files and directories currently installed.)
Preparing to replace mldonkey-server 2.7.3-2 (using 
.../mldonkey-server_2.7.7-4_amd64.deb) ...
Stopping MLDonkey: mlnetNo process in pidfile `/var/run/mldonkey/mlnet.pid' 
found running; none killed.
invoke-rc.d: initscript mldonkey-server, action "stop" failed.
dpkg: warning - old pre-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
Stopping MLDonkey: mlnetNo process in pidfile `/var/run/mldonkey/mlnet.pid' 
found running; none killed.
invoke-rc.d: initscript mldonkey-server, action "stop" failed.
dpkg: error processing 
/var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb (--unpack):
 subprocess new pre-removal script returned error exit status 1
Starting MLDonkey: mlnet configuration file prevent mlnet to be started (use 
force-start).
Errors were encountered while processing:
 /var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.4
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages mldonkey-server depends on:
pn  adduser(no description available)
ii  debconf [debconf-2.0] 1.5.2  Debian configuration management sy
ii  dpkg  1.13.22package maintenance system for Deb
pn  libbz2-1.0 (no description available)
ii  libc6 2.3.6-15   GNU C Library: Shared libraries
ii  libfreetype6  2.2.1-2FreeType 2 font engine, shared lib
ii  libgcc1   1:4.1.1-9  GCC support library
pn  libgd2-noxpm | libgd2-xpm  (no description available)
ii  libjpeg62 6b-13  The Independent JPEG Group's JPEG 
pn  libpng12-0 (no description available)
ii  libstdc++64.1.1-9The GNU Standard C++ Library v3
pn  mime-support   (no description available)
ii  ucf   2.0012 Update Configuration File: preserv
ii  zlib1g1:1.2.3-13 compression library - runtime

mldonkey-server recommends no packages.

-- debconf information:
  mldonkey-server/max_hard_download_rate: 0
* mldonkey-server/launch_at_startup: false
  mldonkey-server/config_exist_no_options:
  mldonkey-server/plugin: Directconnect, Opennap, Overnet, Soulseek, Bittorent, 
Gnutella
  mldonkey-server/mldonkey_group: mldonkey
  mldonkey-server/false_password:
  mldonkey-server/max_hard_upload_rate: 0
  mldonkey-server/max_alive: 48
  mldonkey-server/run_as_user: mldonkey
  mldonkey-server/reown_file: false
  mldonkey-server/mldonkey_niceness:
  mldonkey-server/config_exist_no_dir:
  mldonkey-server/fasttrack_problem:
  mldonkey-server/shared_directories: share
  mldonkey-server/mldonkey_dir: /var/lib/mldonkey
  mldonkey-server/client_name: zombie
  mldonkey-server/mldonkey_move: false
  mldonkey-server/mldonkey_umask: 0022


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378934: mldonkey-server: postinst breaks (dpkg failure) when mlnet fails to start

2006-07-19 Thread Eduard Bloch

#include 
* Samuel Mimram [Thu, Jul 20 2006, 12:26:40AM]:
> Hi,
> 
> Eduard Bloch wrote:
> > Package: mldonkey-server
> > Version: 2.7.3-2
> > Severity: grave
> > 
> > (Reading database ... 147973 files and directories currently installed.)
> > Preparing to replace mldonkey-server 2.7.3-2 (using 
> > .../mldonkey-server_2.7.7-4_amd64.deb) ...
> > Stopping MLDonkey: mlnetNo process in pidfile `/var/run/mldonkey/mlnet.pid' 
> > found running; none killed.
> > invoke-rc.d: initscript mldonkey-server, action "stop" failed.
> > dpkg: warning - old pre-removal script returned error exit status 1
> > dpkg - trying script from the new package instead ...
> > Stopping MLDonkey: mlnetNo process in pidfile `/var/run/mldonkey/mlnet.pid' 
> > found running; none killed.
> > invoke-rc.d: initscript mldonkey-server, action "stop" failed.
> > dpkg: error processing 
> > /var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb (--unpack):
> >  subprocess new pre-removal script returned error exit status 1
> > Starting MLDonkey: mlnet configuration file prevent mlnet to be started 
> > (use force-start).
> > Errors were encountered while processing:
> >  /var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Unfortunately, this was a bug in the 2.7.3-2 version of the package
> (which was removed from testing), see #338875, #363635 and #368118.

Please. Read. The. Log. Now.

I don't talk about testing. And the log message says the bug exists in
the new version as well ("using .../mldonkey-server_2.7.7-4_amd64.deb"
"dpkg - trying script from the new package instead ...").

> Please change the line 100 (in the stop case) of
> /etc/init.d/mldonkey-server from
> 
> start-stop-daemon --stop --pidfile $PIDFILE
> 
> to
> 
> start-stop-daemon --stop --oknodo --pidfile $PIDFILE
> 
> (add the --oknodo) and the update should work. I'm sorry but I cannot
> figure out an easy way to workaround this bug and make the package
> upgrade properly. This is of course fixed in the current version of the
> package.

Of course not, see above.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378934: mldonkey-server: postinst breaks (dpkg failure) when mlnet fails to start

2006-07-19 Thread Eduard Bloch

#include 
* Samuel Mimram [Thu, Jul 20 2006, 01:04:53AM]:
> Eduard Bloch wrote:
> > #include 
> 
> #include 
> 
> > * Samuel Mimram [Thu, Jul 20 2006, 12:26:40AM]:
> >> Eduard Bloch wrote:
> >>> Package: mldonkey-server
> >>> Version: 2.7.3-2
> >>> Severity: grave
> >>>
> >>> (Reading database ... 147973 files and directories currently installed.)
> >>> Preparing to replace mldonkey-server 2.7.3-2 (using 
> >>> .../mldonkey-server_2.7.7-4_amd64.deb) ...
> >>> Stopping MLDonkey: mlnetNo process in pidfile 
> >>> `/var/run/mldonkey/mlnet.pid' found running; none killed.
> >>> invoke-rc.d: initscript mldonkey-server, action "stop" failed.
> >>> dpkg: warning - old pre-removal script returned error exit status 1
> >>> dpkg - trying script from the new package instead ...
> >>> Stopping MLDonkey: mlnetNo process in pidfile 
> >>> `/var/run/mldonkey/mlnet.pid' found running; none killed.
> >>> invoke-rc.d: initscript mldonkey-server, action "stop" failed.
> >>> dpkg: error processing 
> >>> /var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb (--unpack):
> >>>  subprocess new pre-removal script returned error exit status 1
> >>> Starting MLDonkey: mlnet configuration file prevent mlnet to be started 
> >>> (use force-start).
> >>> Errors were encountered while processing:
> >>>  /var/cache/apt/archives/mldonkey-server_2.7.7-4_amd64.deb
> >>> E: Sub-process /usr/bin/dpkg returned an error code (1)
> >> Unfortunately, this was a bug in the 2.7.3-2 version of the package
> >> (which was removed from testing), see #338875, #363635 and #368118.
> > 
> > I don't talk about testing. And the log message says the bug exists in
> > the new version as well ("using .../mldonkey-server_2.7.7-4_amd64.deb"
> > "dpkg - trying script from the new package instead ...").
> 
> The stop) action of the new script is fairly simple:
> 
>   stop)
> echo -n "Stopping $DESC: $NAME"
> start-stop-daemon --stop --oknodo --pidfile $PIDFILE
> echo "."
>   ;;
> 
> Let's try a little experiment (of course the "toto" file does not exist):

Well, that is not the point! When the new version of prerm is run, it
does still execute the _old_ init script. So, how do you intend to solve
this problem?

Removing a package from testing (btw, packages.d.o still says it is
there) does not automaticaly disable all such time bombs outthere.

If I were you, I would stop using dh_installinit and make the prerm
failure-resistant with custom code.

And I wish dh_installinit would have an option for
not-failing-on-restart-problems.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#378934: mldonkey-server: postinst breaks (dpkg failure) when mlnet fails to start

2006-07-19 Thread Eduard Bloch

#include 
* Eduard Bloch [Thu, Jul 20 2006, 01:19:56AM]:

> > The stop) action of the new script is fairly simple:
> > 
> >   stop)
> > echo -n "Stopping $DESC: $NAME"
> > start-stop-daemon --stop --oknodo --pidfile $PIDFILE
> > echo "."
> >   ;;
> > 
> > Let's try a little experiment (of course the "toto" file does not exist):
> 
> Well, that is not the point! When the new version of prerm is run, it
> does still execute the _old_ init script. So, how do you intend to solve
> this problem?

Oh, and the fun continues:

Setting up mldonkey-server (2.7.7-4) ...
Please set both variables MLDONKEY_USER and MLDONKEY_GROUP in 
/etc/default/mldonkey-server
invoke-rc.d: initscript mldonkey-server, action "start" failed.
dpkg: error processing mldonkey-server (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 mldonkey-server

Sorry, WTF? It was purged, of course there is no such setting.

Eduard.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#337613: sets WRONG dependency on kernel image for no reason

2005-11-05 Thread Eduard Bloch

Package: linux-wlan-ng-source
Version: 0.2.2+dfsg-3
Severity: grave

Hello,

I have just pointed by a user on your "solution" WRT kernel dependency
in debian/control.modules.in and I must admit: IT SUCKS.

 - there is no point in setting a such dependency. People can install
   their custom kernels without make-kpkg. RTF Kernel-Howto please.
 - constructing "linux-" or "kernel-" is pretty stupid, sorry. You
   cannot assume anything, because this applies to debian-kernel
   prebuilt versions ONLY.

Please remove this dependency information or move it to Suggests or so.

Eduard.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages linux-wlan-ng-source depends on:
ii  debhelper 4.9.15 helper programs for debian/rules
ii  module-assistant  0.9.10 tool to make module package creati

linux-wlan-ng-source recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338739: RFC: allow usage of mknod in postinst

2005-11-13 Thread Eduard Bloch

#include 
* Marco d'Itri [Sat, Nov 12 2005, 12:42:07PM]:
> Package: sl-modem-source
> Version: 2.9.9d-7
> Severity: serious
> 
> See policy 10.6: packages must use MAKEDEV instead of calling mknod.

I suggest changing the policy to reflect the reality. Using a wrapper
like MAKEDEV to maintain device nodes which use arbitrary choosen
major/minor numbers is just not very useful.

In this case, there is even more code to fix the major/minor numbers
because of a transition, you cannot seriosly tell me to "do that with
MAKEDEV". I remember having waited _months_ for addition of DVB devices
into makedev.

Eduard.

PS, commenting the other complaint:

> (Please remember that there is no need to check for udev or devfs in the
> script, because MAKEDEV does it internally.)

Fine. However, I have not seen any d-d-a announcement or private mail
describing the change in that behaviour.

Further, I expect from you as a carefull maintainer to write at least a
simple HOWTO for your fellows about how (exactly) to deal with
changes/transition to udev. You simply throw people into cold water.
Feel free to tell me that I am wrong, this is just a subjective
impression.

-- 
* ij hat gestern seine Segelnummer gesehen: G 386
 386!! und das mir! *grummel*
-- ij - Amiga seit 1989


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#338739: RFC: allow usage of mknod in postinst

2005-11-13 Thread Eduard Bloch

#include 
* Eduard Bloch [Sun, Nov 13 2005, 10:17:55AM]:

> Further, I expect from you as a carefull maintainer to write at least a
> simple HOWTO for your fellows about how (exactly) to deal with
> changes/transition to udev. You simply throw people into cold water.
> Feel free to tell me that I am wrong, this is just a subjective
> impression.

Ehm, sorry for that part. It is covered by #338740 which I have read
now.

Eduard.
-- 
Ambassador Londo Mollari: Do you know what the last Xon said just before he
died?  [Clutches heart]
Ambassador Londo Mollari: RGHHH!
 -- Quotes from Babylon 5 --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#339688: causes FTBFS, missing symbol fuse_unmount, fixed in 2.4.1

2005-11-17 Thread Eduard Bloch

Package: libfuse-dev
Version: 2.4.0-1
Severity: grave

Hello,

I got a FTBFS problem while doing transition of rlog and encfs - the
fuser_unmount symbol seems to be not seen by the linker for some reason.
The problem disappears after creating my own fuse packages with upstream
version 2.4.1. The changelog also says about moving fuse_unmount to
other header files in 2.4.0 - I have the feeling that they moved it to
the right header file but the code to a wrong file. Whatever, please
update the package soon.

Eduard.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages libfuse-dev depends on:
ii  libfuse2  2.4.1-1Filesystem in USErspace library

libfuse-dev recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#347355: unable to install tetex-extra, preinst failure

2006-01-10 Thread Eduard Bloch

Package: tetex-extra
Version: 1.0.2+20021025-7
Severity: grave

Hello,

I cannot install tetex-extra because its preinst shows weird md5sum
problems (see below). I have been told that may be caused by obsolete coreutils,
however this is a up-to-date Sid system (installed with Slink or so and
dist-upgraded from then). Tetex-extra may have been installed and then
deinstalled in the past, I don't remember.

$ apt-get -f install
Reading package lists... Done
Building dependency tree... Done
Correcting dependencies... Done
The following extra packages will be installed:
  tetex-extra
The following NEW packages will be installed:
  tetex-extra
0 upgraded, 1 newly installed, 0 to remove and 97 not upgraded.
2 not fully installed or removed.
Need to get 0B/10.8MB of archives.
After unpacking 43.2MB of additional disk space will be used.
Do you want to continue [Y/n]? 
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 205050 files and directories currently installed.)
Unpacking tetex-extra (from .../tetex-extra_3.0-11_all.deb) ...
/etc/texmf/dvips/config.ams: md5sum not known. Exiting
dpkg: error processing /var/cache/apt/archives/tetex-extra_3.0-11_all.deb 
(--unpack):
 subprocess pre-installation script returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/tetex-extra_3.0-11_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

ls -la /etc/texmf/dvips/config.*
-rw-r--r-- 1 root root 167 Sep  1  2002 /etc/texmf/dvips/config.ams
-rw-r--r-- 1 root root  52 Jun 30  1998 /etc/texmf/dvips/config.ams.dpkg-old
-rw-r--r-- 1 root root 258 Sep  1  2002 /etc/texmf/dvips/config.amz
-rw-r--r-- 1 root root  52 Jun 30  1998 /etc/texmf/dvips/config.amz.dpkg-old
-rw-r--r-- 1 root root 185 Sep  1  2002 /etc/texmf/dvips/config.cm
-rw-r--r-- 1 root root  51 Jun 30  1998 /etc/texmf/dvips/config.cm.dpkg-old
-rw-r--r-- 1 root root 262 Sep  1  2002 /etc/texmf/dvips/config.cmz
-rw-r--r-- 1 root root  52 Jun 30  1998 /etc/texmf/dvips/config.cmz.dpkg-old
-rw-r--r-- 1 root root 166 May 23  1998 /etc/texmf/dvips/config.mirrorprint

md5sum /etc/texmf/dvips/config.*
df69e80e8157afde30550f21317bbd6d  /etc/texmf/dvips/config.ams
32c36b063268c5e45819fe8114ce3cf0  /etc/texmf/dvips/config.ams.dpkg-old
0ef9213edceaaba3185a79e5946c8411  /etc/texmf/dvips/config.amz
b9c14f2d2e3923372e9067e2e1ee47b5  /etc/texmf/dvips/config.amz.dpkg-old
363c5ef43576af28b14330ae78ed5de8  /etc/texmf/dvips/config.cm
68d23ead2901dddbc1779c905806b783  /etc/texmf/dvips/config.cm.dpkg-old
949213a1865415e6f5199188ee57419e  /etc/texmf/dvips/config.cmz
830f16e1e39c67b1c665a8b09824a7b4  /etc/texmf/dvips/config.cmz.dpkg-old
d8fe8cd35cf178202ee13f64c66dd2d9  /etc/texmf/dvips/config.mirrorprint


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages tetex-extra depends on:
ii  dpkg  1.13.11.0.1package maintenance system for Deb
ii  gsfonts   8.14+v8.11+urw-0.2 Fonts for the Ghostscript interpre
ii  perl-tk   1:800.025-2Perl module providing the Tk graph
ii  tetex-base3.0-11 Basic library files of teTeX
pn  tetex-bin  (no description available)

tetex-extra recommends no packages.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#346385: [NONFREE-DOC] man pppoeconf under the GFDL

2006-01-11 Thread Eduard Bloch

#include 
* Matej Vela [Wed, Jan 11 2006, 04:14:12PM]:
> Hello Eduard,
> 
> Filipus Klutiero <[EMAIL PROTECTED]> writes:
> 
> > Package: pppoeconf
> > Version: 1.8
> > Severity: serious
> > Justification: Policy 2.2.1
> >
> > The copyright file mentions only the GPL, but the manpage seems to
> > contradict this.
> > Since Eduard wrote this, relicensing shouldn't be too problematic
> > :)
> 
> Would it be a problem to relicense pppoeconf.8 under the GPL or some
> other uncontroversial license?

Oh no, please relicense it under any GPL compatible license of your
choice.

Eduard.
-- 
Captain John Sheridan: No surrender, no retreat.
 -- Quotes from Babylon 5 --


signature.asc
Description: Digital signature

Bug#330812: Xsession snipped runs init script without checking permissions

2005-09-29 Thread Eduard Bloch

Package: xprint-common
Version: 1:0.1.0.alpha1-12
Severity: grave

Hello,

the Xsession.d file tries run the init script but it cannot rely on its
existance since it is a conffile. I know of cases where the file was
_not_ executable which made Xsession fail because Overfiend insists on
using "set -e" there and your script is executed by the shell of
Xsession, not your own shebang interpreter.

Obvious workaround: add a "|| true" statement.

Eduard.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-rc2
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages xprint-common depends on:
ii  debconf [debconf-2.0]  1.4.58Debian configuration management sy
ii  xbase-clients  6.8.2.dfsg.1-7miscellaneous X clients
ii  xprint 1:0.1.0.alpha1-12 Xprint - the X11 print system (bin

Versions of packages xprint-common recommends:
ii  xfonts-base   6.8.2.dfsg.1-7 standard fonts for X

-- debconf information:
* xprint-common/default_printer_resolution: 600


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#330812: Xsession snipped runs init script without checking permissions

2005-09-30 Thread Eduard Bloch

#include 
* Drew Parsons [Fri, Sep 30 2005, 10:48:13AM]:
> On Thu, 2005-09-29 at 22:50 +0200, Eduard Bloch wrote:
> > Package: xprint-common
> > Version: 1:0.1.0.alpha1-12
> > Severity: grave
> > 
> > Hello,
> > 
> > the Xsession.d file tries run the init script but it cannot rely on its
> > existance since it is a conffile. I know of cases where the file was
> > _not_ executable which made Xsession fail because Overfiend insists on
> > using "set -e" there and your script is executed by the shell of
> > Xsession, not your own shebang interpreter.
> > 
> > Obvious workaround: add a "|| true" statement.
> > 
> 
> 
> You mean change
>   XPSERVERLIST="`/etc/init.d/xprint get_xpserverlist`"
> to
>   XPSERVERLIST="`/etc/init.d/xprint get_xpserverlist || true`"
> ?

Of course. Or foo=`bar` || true, or foo=`bar || :` or whatever.

> Easy enough to do of course, but since it would be preferable to
> actually run the script, wouldn't it be better to try
> 
>   XPSERVERLIST="`/bin/bash /etc/init.d/xprint get_xpserverlist`"
> 
> instead?

More robust, but not much more. If some error happens in the script the
Xsession is broken again (see other bug report).

Eduard.
-- 
Marcus Cole: That's a lot of ships!  That's a bloody awful lot of ships!
 -- Quotes from Babylon 5 --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#330812: Xsession snipped runs init script without checking permissions

2005-09-30 Thread Eduard Bloch

#include 
* Drew Parsons [Fri, Sep 30 2005, 10:50:10PM]:

> > More robust, but not much more. If some error happens in the script the
> > Xsession is broken again (see other bug report).
> > 
> 
> OK.  I'll probably use XPSERVERLIST="`/etc/init.d/xprint
> get_xpserverlist || true`" then I think, on the grounds that if the
> local admin has made /etc/init.d/xprint non-executable, then they must
> really not want it executed. So I'll let the Xsession.d script honour
> that policy (not that I understand such a policy myself. Why would
> anyone want to disable execution of init scripts? Or is the idea here to
> disable some daemons, while still having their packages installed?)

Because we (Debian) do not have a consistent and easy useable system for
enabling and disabling daemons. So users come with different "easy" ways
to make them "go away".

Eduard.
-- 
Ambassador Londo Mollari: Everyone around me dies, Mr. Morden, except those who
most deserve it.
 -- Quotes from Babylon 5 --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#321133: encfs: "relocation error"

2005-08-03 Thread Eduard Bloch

severity 321133 important
reassign 321133 libssl0.9.7
thanks

#include 
* Matt Price [Wed, Aug 03 2005, 01:11:29PM]:
> Package: encfs
> Version: 1.2.3.1-2
> Severity: grave
> Justification: renders package unusable
> 
> hi there,
> 
> all attempts to use encfs result in the following error message: 
> 
> encfs: relocation error: /usr/lib/libencfs.so.1: undefined symbol:
> EVP_bf_cfb64

This looks like a symbol from libssl0.9.7, which is installed in a
stone-age version. Please upgrade to Debian Stable.

Though I wonder why libssl0.9.7 has changed the ABI without setting a
versioned dependency in the shlibs file. It is not documented in
changelog.Debian.gz either, I guess the maintainers is unaware of the
issue. And the number of affected users is comparably small.

Regards,
Eduard.

> ii  librlog1c2  1.3.6-2  flexible message logging library
> ii  libssl0.9.7 0.9.7d-3 SSL shared libraries
> ii  libstdc++6  4.0.1-2  The GNU Standard C++ Library v3



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#319005: apt-proxy: workaround for apt-proxy-import failure

2005-08-08 Thread Eduard Bloch

Moin Fabian!
Fabian Pietsch schrieb am Samstag, den 06. August 2005:

> As a workaround, I've tried to download the uncompressed Packages file
> manually through apt-proxy, but first only ended up with exceptions in
> the apt-proxy log and an apt-proxy that was unresponsive to that
> specific backend until a restart(, i.e., client connections hung).
> 
> Further investigation (trial & error.. ) showed that it's the

Well. To be honest, I don't care any more. Every time I tried apt-proxy,
something was broken. Either completely, or in some important functions
(import). And the current versions sometimes choosed to redownload some
packages, sometimes not. And sometimes apt-get detects broken MD5
checksums. Sorry, but that seems not to be a robust piece of software.
Any my pythonish was not good enough to understand the code (or maybe it
was not me?!). I gave it up.

OTOH I am biassed. In the meantime I completed my apt-cacher package
with the features and I that is what I recommend now instead of
apt-proxy. It is simplier by designer, does not provide all the
corner-case features but should be more robust.

Oh, and it runs about 8-10 times faster than apt-proxy on our slower
internet proxy and it is not a RAM issue AFAICS.

Regards,
Eduard.

-- 
Kleini: Dann mußt Du da den Fokus reinschieben.
Oli: Ich habe keine Zeitschrift da.

Bug#319005: apt-proxy: workaround for apt-proxy-import failure

2005-08-08 Thread Eduard Bloch

Moin Helge!
Helge Kreutzmann schrieb am Montag, den 08. August 2005:

> Hello Eduard,
> On Mon, Aug 08, 2005 at 09:26:23PM +0200, Eduard Bloch wrote:
> > OTOH I am biassed. In the meantime I completed my apt-cacher package
> > with the features and I that is what I recommend now instead of
> > apt-proxy. It is simplier by designer, does not provide all the
> > corner-case features but should be more robust.
> 
> is it possible to merge all files in one tree (i.e., get at least the
> all.debs only once, either from alioth for amd64, or form debian.org
> for the other archs (i386, ppc, alpha))?

For apt-proxy: no idea
For apt-cacher: it uses a flat structure, so yes.

Its weakness is also handling of different versions of a package file
having the same name.  This should not happen with official mirrors and
sane off-tree maintainers care about avoiding collisions... but stupid
evil local users could try to poison the cache downloading faked package
files if the mirror access is not limited in apt-cacher's configuration
;-) OTOH they would have only limited success and they should expect
punishment from the server admin...

Regards,
Eduard.

-- 
Aschenhaufen haben es gern, wenn man sie für erloschene Vulkane hält.
-- Wieslaw Brudzinski

Bug#332768: apt-cacher: falls if used in conjunction with apt-listbugs

2005-10-09 Thread Eduard Bloch

severity 332768 normal
reassign 332768 apt-listbugs
thanks

#include 
* michael [Sat, Oct 08 2005, 02:17:06PM]:
> Package: apt-cacher
> Version: 1.1
> Severity: grave
> Justification: renders package unusable

Bullshit.

> with apt-cacher on a 'server' and apt-listbugs on a 'client' then when
> getting packages the listbugs falls over:
> 
> Fetched 46.2MB in 3m56s (195kB/s)
> Reading package fields... Done
> Reading package status... Done
> Retrieving bug reports... 0% [0/111] W: getaddrinfo: Temporary failure
> in name resolution: xml-core

What is the problem? apt-cacher is a PACKAGE cache server, not a proxy
for random HTTP access to bugs.debian.org.

Further, I wonder what apt-listbugs is doing there... accessing packages
as servers? I don't think this is indended behaviour, something is buggy
there.

Eduard.

-- 
Susan Ivanova: Ivanova is always right. I will listen to Ivanova. I will not
ignore Ivanova's recommendations. Ivanova is God.  *And*, if this ever happens
again, Ivanova will personally rip your lungs out!
 -- Quotes from Babylon 5 --


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#334473: vpnc - overwrites /etc/resolv.conf without notice, breaks connectivity

2005-10-18 Thread Eduard Bloch

#include 
* Bastian Blank [Tue, Oct 18 2005, 09:13:59AM]:
> Package: vpnc
> Version: 0.3.3+SVN20050909-4
> Severity: critical
> 
> vpnc overwrites /etc/resolv.conf without notice. This breaks the
> network connectivity as the entries don't match the local needs.

A-Ha. Are you sure you have set the "DNSUpdate no" option as described
in the manpage?

Eduard.
-- 
Frauen inspirieren uns zu großen Dingen - und hinden uns dann, sie
auszuführen.
-- Alexandre Dumas d.J.

Bug#334699: vpnc: Error: an inet prefix is expected rather than "¨".

2005-10-19 Thread Eduard Bloch

severity 334699 normal
tags 334699 + moreinfo
thanks

#include 
* Waqar Malik [Wed, Oct 19 2005, 05:47:30AM]:
> Package: vpnc
> Version: 0.3.3+svn20050909-4
> Severity: critical

Please read the definition of "critical".

> IPSEC SA selected des-md5
> S7.7
> S7.8
> Error: an inet prefix is expected rather than "¨".
> S7.9
> S7.10
> VPNC started in background (pid: 3693)...
> 
> vpnc is started but ping fails

I cannot do much with a such report. Please insert "set -x" into the
second line of /etc/vpnc/vpnc-script, and also show the output of
"ifconfig -a" and "route -n" commands.

Eduard.

Bug#324308: dd counts wrong from stdin

2005-08-21 Thread Eduard Bloch

Package: coreutils
Version: 5.2.1-2
Severity: grave

See output below. It does not make much sense. There seems to be a plan
behind that because the number of transfered bytes is increasing on
multiple retries. I guess there are some IPC problems, because it works
fine with if=file.

$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200  | wc -c
80+120 records in
80+120 records out
88047616 bytes transferred in 0.616934 seconds (142718023 bytes/sec)
88047616
$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200  | wc -c
77+123 records in
77+123 records out
89530368 bytes transferred in 0.509001 seconds (175894305 bytes/sec)
89530368
$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200  | wc -c
82+118 records in
82+118 records out
91660288 bytes transferred in 0.558421 seconds (164141893 bytes/sec)
91660288
$ cat /mnt/c/pagefile.sys | dd
bs=1M count=200  | wc -c
84+116 records in
84+116 records out
94158848 bytes transferred in 0.607092 seconds (155098128 bytes/sec)
94158848
$ cat /mnt/c/pagefile.sys | dd
bs=1048576 count=200  | wc -c
89+111 records in
89+111 records out
95707136 bytes transferred in 0.639301 seconds (149705895 bytes/sec)
95707136
$ dd if=/mnt/c/pagefile.sys
bs=1048576 count=200  | wc -c
209715200
200+0 records in
200+0 records out
209715200 bytes transferred in 7.358449 seconds (28499919 bytes/sec)
$ cat /mnt/c/pagefile.sys | perl -e 'for(0..199) { my $buf; read(STDIN, $buf, 
1048576); print $buf}'  | wc -c
209715200



-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.4
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages coreutils depends on:
ii  libacl1 2.2.29-1.0.1 Access control list shared library
ii  libc6   2.3.5-3  GNU C Library: Shared libraries an

coreutils recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#325484: udev >= 0.060-1 and kernels >= 2.6.12

2005-08-31 Thread Eduard Bloch

#include 
* Roberto C. Sanchez [Tue, Aug 30 2005, 01:06:39AM]:
> > Why?
> > 
> Becuase I roll my own kernel.  If I upgrade the kernel with gcc-3.3
> (currently the Sarge default) and then upgrade to Etch (which will have
> gcc-4.0 for a default) I will run into problems if I decide to add new
> modules to my kernel.  Thus, those with a self-compiled kernel are in a

The compiler <-> kernel has "always" been there and has nothing to do
with udev (or any other kernel-stuff-in-userspace troublemaker of the
day).

For modules, you need to know what you are doing.  Unfortunately the
kernel developers seem to be ignorant WRT such things, "gcc" is
hardcoded in assumption of beeing a never changing compatibility
constant.

For additional modules packages using module-assistant there is a
workaround that will push the right compiler into the path, but that is
a cludge. It will fail with "other" module packages that just rely on
the kernel build system and it will fail if you try to build some
extra kernel modules without rebuilding the whole kernel and without
manually forcing the kernel build system to use the correct gcc.

Regards,
Eduard.
-- 
Wo haben wir denn das Dingens mit dem Dingens?
-- Torsten Spindler

Bug#317558: please change icu-doc to icu28-doc when doing the g++-4 transition upload

2005-09-01 Thread Eduard Bloch

#include 
* Steve Langasek [Thu, Sep 01 2005, 01:06:37AM]:

> It appears that all of icu28's reverse-dependencies have successfully
> transitioned to icu32.  Do you have any objections to requesting removal
> of icu28 from unstable?

The removal is already requested and waiting for FTP master's work (#324343).

Eduard.
-- 
The Great Maker has gifted us with great big eyes, and great big
scanners, and great big ah ... well that is no concern of yours.
(Londo Mollari, Babylon 5)

Bug#326020: icewm: FTBFS (amd64): Missing Build-Depends on 'libxpm-dev, librandr-dev, libxinerama-dev'

2005-09-01 Thread Eduard Bloch

Moin Steve!
Steve Langasek schrieb am Donnerstag, den 01. September 2005:

> > -Build-Depends: debhelper (>> 4.0.0), libxrender-dev, imlib11-dev, 
> > libgnome2-dev, libgnome-desktop-dev, gettext, xutils, libxft-dev (>> 2.1.1) 
> > | libxft2-dev, dpatch, libesd0-dev, libpng12-dev, libxinerama-dev [i386 
> > ia64 powerpc]
> > +Build-Depends: debhelper, libxpm-dev, libxrandr-dev, libxrender-dev, 
> > imlib11-dev, libgnome2-dev, libgnome-desktop-dev, gettext, xutils, 
> > libxft-dev (>> 2.1.1) | libxft2-dev, dpatch, libesd0-dev, libpng12-dev, 
> > libxinerama-dev [amd64 i386 ia64 powerpc ppc64]

Hm, sparc is missing too.

> >  Build-Conflicts: libttf-dev
> >  Standards-Version: 3.6.2.1
> 
> This bug is a duplicate of bug #319311, and this patch is wrong.
> 
> - there is nothing architecture-specific about the libxinerama-dev
>   build-dependency; you should not extend this brokenness with further
>   enumeration of architectures

Ehm, what about not beeing available on any arch but the listed ones? Or
maybe I am missing something in debian/pool/main/x/xorg-x11/.

> - nothing in the quoted error gives any reason why libxpm-dev and
>   libxrandr-dev should be added as build-dependencies.

I think I should go back to the single xlibs-dev dependency again, that
has always guaranteed correct package set before.

Regards,
Eduard.
-- 
 Overfiend: why dont you flame him? you are good at that.
 I have too much else to do.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#301479: fails to start w/o config with bogus Xlib error messages

2005-03-26 Thread Eduard Bloch

Package: mozilla-firefox
Version: 1.0.2-1
Severity: grave

Hello,

when I kill all mozilla-firefox and mozilla instanzes and wipe out the
.mozilla and .firefox directories, mozilla-firefox fails to start with
following message:

Xlib: connection to ":0.0" refused by server
Xlib: XDM authorization key matches an existing client!

(firefox-bin:12546): Gtk-WARNING **: cannot open display:  

This makes no sense. With strace -f, I see multiple openings of the
.Xauthority file and only after a while it simply breaks.

When I run "host +" and start FF once, then it does work after that,
even with "host -".

Regards,
Eduard.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.5
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages mozilla-firefox depends on:
ii  debianutils  2.13.1  Miscellaneous utilities specific t
ii  fontconfig   2.3.1-2 generic font configuration library
ii  libatk1.0-0  1.8.0-4 The ATK accessibility toolkit
ii  libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii  libfontconfig1   2.3.1-2 generic font configuration library
ii  libfreetype6 2.1.7-2.3   FreeType 2 font engine, shared lib
ii  libgcc1  1:3.4.3-12  GCC support library
ii  libglib2.0-0 2.6.3-1 The GLib library of C routines
ii  libgtk2.0-0  2.6.2-4 The GTK+ graphical user interface 
ii  libidl0  0.8.5-1 library for parsing CORBA IDL file
ii  libjpeg626b-10   The Independent JPEG Group's JPEG 
ii  libkrb53 1.3.6-1 MIT Kerberos runtime libraries
ii  libpango1.0-01.8.1-1 Layout and rendering of internatio
ii  libpng12-0   1.2.8rel-1  PNG library - runtime
ii  libstdc++5   1:3.3.5-12  The GNU Standard C++ Library v3
ii  libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li
ii  libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte
ii  libxft2  2.1.2-6 FreeType-based font drawing librar
hi  libxp6   4.3.0.dfsg.1-12.0.1 X Window System printing extension
hi  libxt6   4.3.0.dfsg.1-12.0.1 X Toolkit Intrinsics
ii  psmisc   21.6-1  Utilities that use the proc filesy
ii  xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu
ii  zlib1g   1:1.2.2-4   compression library - runtime

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#301666: fails to build with no dpatch installed

2005-03-27 Thread Eduard Bloch

Package: zaptel-source
Version: 1:1.0.7-1
Severity: serious

Hello,

you use include in debian/rules but this fails if dpatch is not
installed. Make that "-include" please.

If you wait a few minutes, I will send you an improved version of
debian/rules.

Regards,
Eduard.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.5
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages zaptel-source depends on:
ii  debhelper 4.2.31 helper programs for debian/rules
ii  dpatch2.0.11 patch maintenance system for Debia

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#301666: Acknowledgement (fails to build with no dpatch installed)

2005-03-27 Thread Eduard Bloch

#include 
* Debian Bug Tracking System [Sun, Mar 27 2005, 07:48:32AM]:
> Thank you for the problem report you have sent regarding Debian.
> This is an automatically generated reply, to let you know your message has

Sorry, the original description was wrong, and the case was kinda
constructed. However, there is really no point in depending on dpatch if
it is not used at all in the binary-modules target, and not required for
clean (in short: anything that the user would run trough make-kpkg &
Co.).

So I propose the attached change. See changelog diff for the summary, I
basicaly removed the old kernel setup crap from dh-make and switched it
to use module-assistant.

Regards,
Eduard.
-- 
Chemie ist Natur zu stark herabgesetzten Preisen
-- Jürgen von Manger
diff -u zaptel-1.0.7/debian/changelog zaptel-1.0.7/debian/changelog
--- zaptel-1.0.7/debian/changelog
+++ zaptel-1.0.7/debian/changelog
@@ -1,3 +1,14 @@
+zaptel (1:1.0.7-2) unstable; urgency=low
+
+  * fixes
+  * removed the requirement of dpatch in the driver source (reason?!)
+  * removed zaptel-source.files (dh_movefile is obsolete and there is really
+no point in copying stuff MANUALLY to tmp in order to move it few secs
+later with another tool)
+  * using bzip2 for the source now
+
+ -- Eduard Bloch <[EMAIL PROTECTED]>  Sun, 27 Mar 2005 17:43:11 +0200
+
 zaptel (1:1.0.7-1) unstable; urgency=low
 
   * New upstream version.
diff -u zaptel-1.0.7/debian/control zaptel-1.0.7/debian/control
--- zaptel-1.0.7/debian/control
+++ zaptel-1.0.7/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian VoIP Team <[EMAIL PROTECTED]>
 Uploaders: Kilian Krause <[EMAIL PROTECTED]>, Jose Carlos Garcia Sogo <[EMAIL 
PROTECTED]>, Mark Purcell <[EMAIL PROTECTED]>, Santiago Garcia Mantinan <[EMAIL 
PROTECTED]>, Santiago Ruano Rincon <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>> 3.0.0), libnewt-dev, dpatch
+Build-Depends: debhelper (>> 3.0.0), libnewt-dev, dpatch, bzip2
 Standards-Version: 3.6.1.1
 
 Package: zaptel
@@ -31,8 +31,8 @@
 Package: zaptel-source
 Section: devel
 Architecture: all
-Depends: debhelper, dpatch
-Recommends: dpkg-dev, libc6-dev | libc-dev, gcc, make, zaptel
+Depends: debhelper, module-assistant, bzip2
+Recommends: zaptel
 Description: Zapata telephony interface (source code for kernel driver)
  This package contains the source code for zaptel, a kernel module providing
  the Zapata telephony API, and device drivers for various telephony hardware,
diff -u zaptel-1.0.7/debian/rules zaptel-1.0.7/debian/rules
--- zaptel-1.0.7/debian/rules
+++ zaptel-1.0.7/debian/rules
@@ -8,100 +8,13 @@
 # This is the debhelper compatibility version to use.
 export DH_COMPAT=3
 
-include /usr/share/dpatch/dpatch.make
-
-export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
-### KERNEL SETUP
-### Setup the stuff needed for making kernel module packages
-### taken from /usr/share/kernel-package/sample.module.rules
-
-# Name of package
-package = zaptel
-# KSRC is the location of the kernel source. This is the default value,
-# when make-kpkg is used it will supply to real value
-KSRC= /usr/src/linux
-# KDREV is the package-revision, as given to make-kpkg by the user.
-# Just put a simply default value in here which we use when we test
-# the packagebuilding without make-kpkg
-ifeq ($(strip $(KDREV)),)
-KDREV   = "test1.0"
-endif
-
-## Now to determine the kernel version, normally supplied by make-kpkg
-ifeq ($(strip $(KVERS)),)
-# Now we need to get the kernel-version somehow (we are not running
-# under make-kpkg?)
-ifeq ($(strip $(KSRC)),)
-$(error Error. I do not know how to determine the kernel version)
-else
-kversion :=$(shell egrep '^VERSION +=' $(KSRC)/Makefile 2>/dev/null | \
- sed -e 's/[^0-9]*\([0-9]*\)/\1/')
-kplevel  :=$(shell egrep '^PATCHLEVEL +=' $(KSRC)/Makefile 2>/dev/null | \
-sed -e 's/[^0-9]*\([0-9]*\)/\1/')
-ksublevel:=$(shell egrep '^SUBLEVEL +=' $(KSRC)/Makefile 2>/dev/null | \
-  sed -e 's/[^0-9]*\([0-9]*\)/\1/')
-EXTRA_VERSION:=$(shell egrep '^EXTRAVERSION +=' $(KSRC)/Makefile 2>/dev/null | 
\
- sed -e 's/EXTRAVERSION[\t ]*=[\t ]*\(.*\)/\1/')
-kextra:=$(strip $(EXTRA_VERSION))
-HAVE_NEW_MODLIB:=$(shell egrep '\(INSTALL_MOD_PATH\)' \
-$(KSRC)/Makefile 2>/dev/null )
-
-ifneq ($(strip $(APPEND_TO_VERSION)),)
-iatv := $(strip $(APPEND_TO_VERSION))
-EXTRAV_ARG := EXTRAVERSION=${EXTRA_VERSION}${iatv}
-else
-iatv :=
-EXTRAV_ARG :=
-endif
-
-KVERS = $(kversion).$(kplevel).$(ksublevel)$(kextra)$(iatv)$(INT_FLAV)
-
-endif
-endif
-
-non_epoch_version=$(shell echo $(KVERS) | perl -pe 's/^\d+://')

Bug#267799: Is this really RC?

2005-04-02 Thread Eduard Bloch

severity 267799 normal
thanks

#include 
* Reinhard Tartler [Sat, Apr 02 2005, 01:44:20PM]:

> I don't think this applies to this bug. Considering this bug is
> holding nvidia drivers out of sarge, I think this bug should really be
> downgraded!
> 
> Please reconsider this bug severity soon.

Okay. I will send more data if I come to test it again.

Regards,
Eduard.
-- 
Immerhin meint die Filmförderungsanstalt, im Jahr 2002 seien 59
Millionen CD-Rohlinge von 5,9 Millionen Nutzern mit Filmen bespielt
worden, im Durchschnitt also zwölf Rohlinge pro Anwender.
--

Bug#295315: pppoeconf: sed command fails when user contains a / character

2005-02-16 Thread Eduard Bloch

#include 
* Leopold BAILLY [Tue, Feb 15 2005, 12:38:28AM]:

> The use of "grep -v" should be more appropriate.

Could you test the attached version?

Regards,
Eduard.
-- 
 Ich find die Domain auch scheisse, aber nem geschenkten Gaul schaut man
nicht ins Maul oder wie war das?
#!/bin/sh
# (c) Eduard Bloch <[EMAIL PROTECTED]>
# LICENSE: GPL
# Purpose: initial PPPoE configuration on Debian
# Depends: bash, pppd, pppoe, whiptail, my usepeerdns script

export TEXTDOMAINDIR="/usr/share/locale"
export TEXTDOMAIN=pppoeconf
export OPTSFILE="/etc/ppp/peers/dsl-provider"

# IMPORTANT: Do not use gdialog unless it has been fixed!
DIALOG=whiptail

# Set up (X)dialog - added by Fabian Franz <[EMAIL PROTECTED]>
XDIALOG_HIGH_DIALOG_COMPAT=1
export XDIALOG_HIGH_DIALOG_COMPAT
if [ -n "$DISPLAY" ] && [ -x /usr/bin/Xdialog ] ; then
   DIALOG="Xdialog"
   X11="-X"
fi

# SUID wrapper for KNOPPIX added by Klaus Knopper <[EMAIL PROTECTED]>
# mod. by EB
PATH="/bin:/sbin:/usr/bin:/usr/sbin"
export PATH

. /usr/bin/gettext.sh

# for non-root, try to reexec with sudo, warn otherwise
if [ "`id -u`" != "0" ]; then
   # sudo only 
  if which sudo >/dev/null && ( sudo -l -S /dev/null 2>&1 ) ; then
exec sudo "$0" "$@"  || exit 1
  elif which su-to-root >/dev/null; then
exec su-to-root $X11 -c "$0" "$@"  || exit 1
  else
gettext "Please become root before running pppoeconf!"
echo
gettext "Press return to continue..."
echo
read
exit 1
  fi
fi

# EOF SUID wrapper

modprobe -q pppoe
# recent ppp packages have a PPPoE discovery helper program
if test -x /usr/sbin/pppoe-discovery && test -e /proc/net/pppoe ; then
  kernel_pppoe=1
  DISCOVERY_PROGRAM=pppoe-discovery
else
  DISCOVERY_PROGRAM=pppoe
fi
export DISCOVERY_PROGRAM

# create a default peers file if there is none
if ! test -r $OPTSFILE ; then
   fresh_optsfile=1
   cat < $OPTSFILE
# Minimalistic default options file for DSL/PPPoE connections

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
#mtu 1492
usepeerdns
EOM
fi
chmod 0640 $OPTSFILE
chown root:dip $OPTSFILE

umask 177
# make a secure directory
TMP="`mktemp -d -p /etc/ppp`"
export TMP
sectempfile="`mktemp -p $TMP`"
export sectempfile
trap "rm -rf '$TMP'" 0 HUP INT TRAP TERM

gettext '
Most providers send the needed login information per mail. Some providers 
describe it in odd ways, assuming the user to input the data in their 
"user-friendly" setup programs. But in fact, these applications generate usuall 
PPP user names and passwords from the entered data. You can find the real names 
too and input the correct data in the dialog box.

For example, this are methods used some german providers:

Sample username (alias "login" or "login name"): 111

T-Online T-DSL:
  additional data:
sample T-Onlinenummer: 
sample Mitbenutzer: 0001

  complete username: [EMAIL PROTECTED]

Telekom Business Online (DSL):

  complete username: t-online-com/[EMAIL PROTECTED]

1und1 uses another scheme (using above example):

  complete username: 1und1/111

Cyberfun:

  complete username: sdt/111

Komtel:
  additional data:
downstream speed class: 768

  complete username: [EMAIL PROTECTED]

Net Cologne:

  complete username: [EMAIL PROTECTED]

Q-DSL:

  complete username: [EMAIL PROTECTED]

Versatel:

  complete username: [EMAIL PROTECTED]

Webnetix:

  complete username: sdt/111
' > $TMP/namehelp.txt

if test "$*" ; then 
   list="$*"
else
   list=$( LANG=C /sbin/ifconfig -a | grep "Ethernet" | grep -v irlan | cut -f1 
-d" " )
fi

if test "$list" ; then
   test "$DIALOG" = "whiptail" && escmsg=$(gettext 'Or press ESC to abort 
here.')
  number=`echo $list | wc -w| tr -d " "`
  text=$(eval_ngettext \
  'I found $number ethernet device:
$list

Are all your ethernet interfaces listed above?
(If No, modconf will be started so you can load the card drivers manually).

$escmsg' \
  'I found $number ethernet devices:
$list

Are all your ethernet interfaces listed above?
(If No, modconf will be started so you can load the card drivers manually).

$escmsg' \
  "$number" )
  title=$(gettext 'ALL DEVICES FOUND?')
  $DIALOG --title "$title" --clear --yesno "$text" 15 60
  case $? in
1)
# configure and restart
  modconf
  $0
  exit $?
  ;;
255)
  rm -rf "$TMP"
  exit 1
  ;;
   esac
   # now, execute an AC lookup on each interface
   for mmm in '' ' -U ' ; do
  for ifac

Bug#297139: TERM environment variable needs set.

2005-02-27 Thread Eduard Bloch

Package: mc
Version: 1:4.6.0-4.6.1-pre3-1
Severity: grave

Hello,

the last version of mc refuses to start the GUI! with the message in
subject.

ltrace shows a lot of interesting data, the last sensible thing is:

free(0x810f548)
= 
getenv("RXVT_EXT")
= NULL
close(-1)
= -1
close(-1)
= -1
close(-1)
= -1
pipe(0x80d1ab0)
= 0
pipe(0x80d1ab8)
= 0
fork( 
--- SIGCHLD (Child exited) ---
<... fork resumed> )
= 8219
close(4)
= 0
close(7)
= 0
read(6, "", 1)
= 1
close(5)
= 0
close(6)
= 0
waitpid(8219, 0xb980, 0)
= 8219
tcgetattr(1, 0x80d7d20)
= 0
sigemptyset(0xb8f4)
= 0
sigaction(17, 0xb8f0, NULL)
= 0

The TERM variable is set (tried rxvt, xterm, same thing everywhere).

Regards,
Eduard.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-rc5
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages mc depends on:
ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libglib2.0-02.6.2-1  The GLib library of C routines
ii  libgpmg11.19.6-19General Purpose Mouse - shared lib

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

1 2 >

1 - 100 of 191 matches

Mail list logo