Bug#479172: Patch for git-buildpackage #479172
Hi, I've created a patch for this a while back, but apparently I forgot to actually submit it. Anyway, here it is. Gr. Matthijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#479172: [PATCH] Ask the user for the package name and version if needed.
If there is no debian/changelog to find the source package name, and/or
the upstream version was not given on the commandline, ask the user for
them. The values guessed from the original tarball name are offered as
defaults to the user. Previously, this guessed version was used without
confirmation.
The source package name is now always taken from debian/changelog or
prompted for, even when it might not be used (when importing a directory
instead of a tarball, for example). This makes the code more
straightforward and less errorprone in the future.
Closes: #479172
Thanks: Matthijs Kooijman
---
gbp/deb.py | 34 ++
git-import-orig | 100 +++
2 files changed, 105 insertions(+), 29 deletions(-)
diff --git a/gbp/deb.py b/gbp/deb.py
index ba9dd0b..cd9f79d 100644
--- a/gbp/deb.py
+++ b/gbp/deb.py
@@ -234,43 +234,47 @@ def get_arch():
return arch
-def guess_upstream_version(archive, version_regex=r''):
+def guess_upstream_version(archive, extra_regex=r''):
-guess the version from the filename of an upstgream archive
+guess the package name and version from the filename of an upstgream
+archive. Returns a tuple with package name and version, or None.
@archive: filename to guess to version for
-@version_regex: additional version regex to apply, needs a 'version' group
+@extra_regex: additional regex to apply, needs a 'package' and a
+'version' group
guess_upstream_version('foo-bar_0.2.orig.tar.gz')
-'0.2'
+('foo-bar', '0.2')
guess_upstream_version('foo-Bar_0.2.orig.tar.gz')
guess_upstream_version('git-bar-0.2.tar.gz')
-'0.2'
+('git-bar', '0.2')
guess_upstream_version('git-bar-0.2-rc1.tar.gz')
-'0.2-rc1'
+('git-bar', '0.2-rc1')
guess_upstream_version('git-bar-0.2:~-rc1.tar.gz')
-'0.2:~-rc1'
+('git-bar', '0.2:~-rc1')
guess_upstream_version('git-Bar-0A2d:rc1.tar.bz2')
-'0A2d:rc1'
+('git-Bar', '0A2d:rc1')
guess_upstream_version('git-1.tar.bz2')
-'1'
+('git', '1')
guess_upstream_version('kvm_87+dfsg.orig.tar.gz')
-'87+dfsg'
+('kvm', '87+dfsg')
guess_upstream_version('foo-Bar_0.2.orig.tar.gz')
guess_upstream_version('foo-Bar-a.b.tar.gz')
+
version_chars = r'[a-zA-Z\d\.\~\-\:\+]'
extensions = r'\.tar\.(gz|bz2)'
version_filters = map ( lambda x: x % (version_chars, extensions),
( # Debian package_version.orig.tar.gz:
- r'^[a-z\d\.\+\-]+_(?Pversion%s+)\.orig%s',
+
r'^(?Ppackage[a-z\d\.\+\-]+)_(?Pversion%s+)\.orig%s',
# Upstream package-version.tar.gz:
- r'^[a-zA-Z\d\.\+\-]+-(?Pversion[0-9]%s*)%s'))
-if version_regex:
-version_filters = version_regex + version_filters
+
r'^(?Ppackage[a-zA-Z\d\.\+\-]+)-(?Pversion[0-9]%s*)%s'))
+if extra_regex:
+version_filters = extra_regex + version_filters
+
for filter in version_filters:
m = re.match(filter, os.path.basename(archive))
if m:
-return m.group('version')
+return (m.group('package'), m.group('version'))
# vim:et:ts=4:sw=4:et:sts=4:ai:set list listchars=tab\:»·,trail\:·:
diff --git a/git-import-orig b/git-import-orig
index 6f7f896..b4f229d 100755
--- a/git-import-orig
+++ b/git-import-orig
@@ -35,6 +35,29 @@ from gbp.git import (FastImport, GitRepositoryError,
GitRepository, build_tag)
from gbp.config import GbpOptionParser, GbpOptionGroup
from gbp.errors import (GbpError, GbpNothingImported)
+# Try to import readline, since that will cause raw_input to get fancy
+# line editing and history capabilities. However, if readline is not
+# available, raw_input will still work.
+try:
+import readline
+except ImportError:
+pass
+
+# Valid package names according to Debian Policy Manual 5.6.1:
+# Package names (both source and binary, see Package, Section 5.6.7)
+# must consist only of lower case letters (a-z), digits (0-9), plus (+)
+# and minus (-) signs, and periods (.). They must be at least two
+# characters long and must start with an alphanumeric character.
+packagename_re = re.compile(^[a-z0-9][a-z0-9\.\+\-]+$)
+# Valid upstream versions according to Debian Policy Manual 5.6.12:
+# The upstream_version may contain only alphanumerics[32] and the
+# characters . + - : ~ (full stop, plus, hyphen, colon, tilde) and
+# should start with a digit. If there is no debian_revision then hyphens
+# are not allowed; if there is no epoch then colons are not allowed.
+# Since we don't know about any epochs and debian revisions yet, the
+# last two conditions are not checked.
+upstreamversion_re = re.compile(^[0-9][a-z0-9\.\+\-\:\~]+$)
+
def cleanup_tmp_tree(tree):
remove a tree of temporary files
try:
@@ -141,6 +164,52 @@ def turn_off_fastimport(options, msg):
options.fast_import
Bug#567104: mpg321: Does not work without a controlling terminal
package mpg321 severity 567104 normal merge 566544 567104 thanks Hi Chris, i think that mpg321-0.2.11-2 version resolves this problem by adding the -x option which enables xterm title setting. This is a better approach. You can download and test it from mentors.d.n. A mentor has to upload it to sid. Yup, your fix works as well (just tested it). You might want to consider taking the cleanup/renaming part of my patch still, though. Stupid that I missed the other bug report :-) Gr. Matthijs signature.asc Description: Digital signature
Bug#180539: How about a configurable display?
Hi, I've been wanting a feature like this for a while as well. I guess it would be useful to make the display configurable, just like the aptitude::UI::Package-Display-Format setting. For this setting, there are already some useful variables available, like (pin) priority and archive. I guess things like origin and label might need to be added if they are not present yet. Making this configurable allows everyone to customize aptitude to his needs. We will then only have to agree on a sensible default :-p Gr. Matthijs signature.asc Description: Digital signature
Bug#567189: initramfs-tools: MODULES=DEP not working for atiixp
Package: initramfs-tools Version: 0.93.4 Severity: normal I thought I'd experiment a bit with MODULES=DEP, but it seems this will not work. The atiixp module is properly installed into the initrd (I'm not sure how), but it doesn't end up in /conf/modules. Instead, the /conf/modules ends up as: radeonfb fbcon vesafb pci:v1002d4376sv1462sd0131bc01sc01i8a ide-gd ATIIXP_IDE pci:v1002d4376sv1462sd0131bc01sc01i8a unix Of these, the ide-gd and ATIIXP_IDE modules come from walking /sys/devices/pci\:00/\:00\:14.1/ide0/0.0/. However, the module is called atiixp, not ATIIXP_IDE. The ATIIXP_IDE comes directly from sysfs, though: $ readlink -f /sys/devices/pci\:00/\:00\:14.1/driver /sys/bus/pci/drivers/ATIIXP_IDE Perhaps using driver/module instead of just driver is more robust? $ readlink -f /sys/devices/pci\:00/\:00\:14.1/driver/module /sys/module/atiixp This would also fix the ide-gd module, which really seems to be called ide-gd_mod: $ readlink -f /sys/devices/pci\:00/\:00\:14.1/ide0/0.0/driver /sys/bus/ide/drivers/ide-gd $ readlink -f /sys/devices/pci\:00/\:00\:14.1/ide0/0.0/driver/module /sys/module/ide_gd_mod $ sudo modprobe ide-gd FATAL: Module ide_gd not found. $ sudo modprobe ide-gd_mod Gr. Matthijs -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-2.6.31.1 root=/dev/mapper/Xanthe-root ro video=radeonfb -- /proc/filesystems ext3 ext2 vfat msdos fuseblk -- lsmod Module Size Used by snd_usb_audio 96480 2 snd_usb_lib18296 1 snd_usb_audio snd_hwdep 8736 1 snd_usb_audio cpufreq_ondemand7816 1 radeon373792 1 drm 186816 2 radeon sco20520 2 bnep 19352 2 rfcomm 75136 5 l2cap 44640 16 bnep,rfcomm vboxnetflt105804 0 vboxnetadp 98476 0 vboxdrv 1708012 1 vboxnetflt af_packet 23384 2 fuse 67488 1 btusb 17644 2 bluetooth 103876 9 sco,bnep,rfcomm,l2cap,btusb dm_mod 71144 60 ide_gd_mod 15584 7 ide_cd_mod 30144 0 cdrom 38824 1 ide_cd_mod wacom 24096 0 usbhid 23824 0 hid43836 1 usbhid pcmcia 39084 0 snd_atiixp 18444 4 snd_atiixp_modem 13732 0 snd_ac97_codec122712 2 snd_atiixp,snd_atiixp_modem ac97_bus1976 1 snd_ac97_codec snd_pcm_oss26432 0 snd_mixer_oss 17048 1 snd_pcm_oss snd_pcm81636 9 snd_usb_audio,snd_atiixp,snd_atiixp_modem,snd_ac97_codec,snd_pcm_oss snd_seq_midi7200 0 snd_rawmidi25504 2 snd_usb_lib,snd_seq_midi ohci_hcd 36148 0 snd_seq_midi_event 8472 1 snd_seq_midi snd_seq55488 2 snd_seq_midi,snd_seq_midi_event snd_timer 24192 2 snd_pcm,snd_seq snd_seq_device 7820 3 snd_seq_midi,snd_rawmidi,snd_seq rt2500pci 17880 0 rt2x00pci 8984 1 rt2500pci rt2x00lib 39672 2 rt2500pci,rt2x00pci input_polldev 4424 1 rt2x00lib sdhci_pci 9144 0 sdhci 21788 1 sdhci_pci mac80211 207180 2 rt2x00pci,rt2x00lib snd69512 20 snd_usb_audio,snd_hwdep,snd_atiixp,snd_atiixp_modem,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device atiixp 4408 6 msi_laptop 5776 0 pcspkr 2968 0 cfg80211 101000 2 rt2x00lib,mac80211 rfkill 21856 2 bluetooth,cfg80211 eeprom_93cx62360 1 rt2500pci yenta_socket 43396 1 rsrc_nonstatic 11064 1 yenta_socket pcmcia_core40476 3 pcmcia,yenta_socket,rsrc_nonstatic mmc_core 64392 1 sdhci psmouse45556 0 serio_raw 6236 0 8139too33820 0 mii 6040 1 8139too ide_core 104080 3 ide_gd_mod,ide_cd_mod,atiixp soundcore 8864 1 snd snd_page_alloc 10312 3 snd_atiixp,snd_atiixp_modem,snd_pcm ehci_hcd 54152 0 usbcore 211732 8 snd_usb_audio,snd_usb_lib,btusb,wacom,usbhid,ohci_hcd,ehci_hcd rtc_cmos 14492 0 rtc_core 20940 1 rtc_cmos rtc_lib 3320 1 rtc_core evdev 11520 17 unix 29872 275 -- /etc/kernel-img.conf # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = no do_bootloader = no
Bug#561346: [git-buildpackage/bpo-lenny] Add support for a Git-Dch: Ignore metaheader.
tag 561346 pending thanks Date: Thu Dec 17 12:54:23 2009 +0100 Author: Matthijs Kooijman matth...@stdin.nl Commit ID: 725b9d34b81a1a415ac710458487a78d4f4f4e09 Commit URL: http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=725b9d34b81a1a415ac710458487a78d4f4f4e09 Patch URL: http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=725b9d34b81a1a415ac710458487a78d4f4f4e09 Add support for a Git-Dch: Ignore metaheader. Closes: #561346 Thanks: Matthijs Kooijman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565729: Logrotate postrotate script fails when vuurmuur is disabled or not running
Package: vuurmuur Version: 0.8~beta1-1 Severity: normal When vuurmuur_log is not running (because vuurmuur is installed but not used or not currently running), the postrotate script fails: postrotate /bin/kill -HUP `pidof vuurmuur_log` pidof outputs nothing, so kill outputs a usage error. This can probably be solved by putting a pidof vuurmuur_log before the current script (though this would still cause a non-zero return value, so something more fanycy might be required). Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-rc8 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vuurmuur depends on: ii libvuurmuur 0.8~beta1-1 Iptables frontend. Common library Versions of packages vuurmuur recommends: ii iproute 20090324-1 networking and traffic control too ii iptables 1.4.6-2 administration tools for packet fi ii vuurmuur-conf0.8~beta1-1 Iptables frontend. Ncurses GUI, fo vuurmuur suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565392: ITP: grfcodec -- A suite of programs to modify Transport Tycoon Deluxe's GRF files
Package: wnpp Severity: wishlist Owner: Matthijs Kooijman matth...@stdin.nl * Package name: grfcodec Version : 0.9.10+svn2247 Upstream Author : Josef Drexler jdrex...@uwo.ca * URL : http://www.ttdpatch.net/grfcodec/ http://www.openttd.org/en/download-grfcodec * License : GPL2 Programming Lang: C Description : A suite of programs to modify Transport Tycoon Deluxe's GRF files This package provides the grfcodec, grfdiff and grfmerge commands which can be used to work with the GRF used by the Transport Tycoon Deluxe, TTDPatch and OpenTTD games. This package is needed to compile the opengfx package (http://dev.openttdcoop.org/projects/opengfx), which I intend to package as well soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565284: rygel: Need gstreamer plugins to work
Package: rygel Version: 0.4.8-1 Severity: normal Hi, I've been experimenting with rygel for streaming audio to my Sony TV. It seems that Rygel needs certain gstreamer plugins to be able to read the metadata and share media files. On my system, I had only the good, bad and base plugin sets installed. This caused .ogg files to work, but .mp3 files were (silently) not processed and not listed. Installing the gstreamer0.10-plugins-ugly packages made at least mp3 streaming work for me. I guess the rygel package should recommend some of the plugin packages, or at least get a README.Debian that points to these packages? Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-rc8 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages rygel depends on: ii libatk1.0-0 1.28.0-1 The ATK accessibility toolkit ii libc6 2.10.2-2 GNU C Library: Shared libraries ii libcairo2 1.8.8-2 The Cairo 2D vector graphics libra ii libdbus-1-3 1.2.16-2 simple interprocess messaging syst ii libdbus-glib-1-20.82-2 simple interprocess messaging syst ii libfontconfig1 2.8.0-1.1generic font configuration library ii libfreetype62.3.11-1 FreeType 2 font engine, shared lib ii libgee2 0.5.0-2 GObject based collection library ii libglib2.0-02.22.3-2 The GLib library of C routines ii libgssdp-1.0-2 0.7.0-1 GObject-based library for SSDP ii libgstreamer0.10-0 0.10.25-4Core GStreamer libraries and eleme ii libgtk2.0-0 2.18.5-1 The GTK+ graphical user interface ii libgupnp-1.0-3 0.13.1-1 GObject-based library for UPnP ii libgupnp-av-1.0-2 0.5.2-1 Audio/Visual utility library for G ii libpango1.0-0 1.26.2-1 Layout and rendering of internatio ii libsoup2.4-12.28.2-1 an HTTP library implementation in ii libsqlite3-03.6.21-2 SQLite 3 shared library ii libuuid12.16.2-0 Universally Unique ID library ii libxml2 2.7.6.dfsg-1 GNOME XML library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime rygel recommends no packages. Versions of packages rygel suggests: pn rygel-mediathek none (no description available) pn rygel-tracker none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562096: pu: package openttd/0.6.2-1+lenny1
Hi Adam,
The fix itself is fine. However, introducing new dependencies or patch
systems is not an appropriate change to make in a stable update.
If you were to upload an update which included the bugfix without the
packaging changes then I'd be happy to accept that.
Ah right. I totally forgot that you can put changes to upstream sources
directly in the .diff.gz. I've just uploaded a version with just the upstream
patch, debdiff is below.
Gr.
Matthijs
diff -u openttd-0.6.2/debian/changelog openttd-0.6.2/debian/changelog
--- openttd-0.6.2/debian/changelog
+++ openttd-0.6.2/debian/changelog
@@ -1,3 +1,10 @@
+openttd (0.6.2-1+lenny1) stable; urgency=low
+
+ * Backport upstream r18462 to fix remote crash vulnerability
+CVE-2009-4007.
+
+ -- Matthijs Kooijman matth...@stdin.nl Wed, 23 Dec 2009 23:08:48 +0100
+
openttd (0.6.2-1) unstable; urgency=low
* New upstream release.
only in patch2:
unchanged:
--- openttd-0.6.2.orig/src/train_cmd.cpp
+++ openttd-0.6.2/src/train_cmd.cpp
@@ -996,10 +996,6 @@
*/
static void NormaliseTrainConsist(Vehicle *v)
{
- if (IsFreeWagon(v)) return;
-
- assert(IsFrontEngine(v));
-
for (; v != NULL; v = GetNextVehicle(v)) {
if (!IsMultiheaded(v) || !IsTrainEngine(v)) continue;
signature.asc
Description: Digital signature
Bug#562096: pu: package openttd/0.6.2-1+lenny1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Hi,
The openttd package contains a remote crash vulnerability that is easily
exploited. Upstream will fix the bug in its upcoming release. Since that
will be released in a few days, I will not provide complete details on
the exploit, just the patch.
Since openttd is in contrib, this fix is not going through the
stable-security repository.
The debdiff is below, most of the diff is putting the dpatch stuff
(back) into place. Only the last chunk is the actual bugfix.
Okay to upload this fixed package?
Gr.
Matthijs
diff -u openttd-0.6.2/debian/control openttd-0.6.2/debian/control
--- openttd-0.6.2/debian/control
+++ openttd-0.6.2/debian/control
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Matthijs Kooijman matth...@stdin.nl
Uploaders: Jordi Mallach jo...@debian.org
-Build-Depends: debhelper (= 4.0.0), libsdl-dev, zlib1g-dev, libpng-dev,
libfreetype6-dev, libfontconfig-dev
+Build-Depends: debhelper (= 4.0.0), dpatch, libsdl-dev, zlib1g-dev,
libpng-dev, libfreetype6-dev, libfontconfig-dev
Standards-Version: 3.7.3
Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/deb-maint/openttd/trunk/
Vcs-Svn: svn://svn.debian.org/svn/collab-maint/deb-maint/openttd/trunk
diff -u openttd-0.6.2/debian/rules openttd-0.6.2/debian/rules
--- openttd-0.6.2/debian/rules
+++ openttd-0.6.2/debian/rules
@@ -6,7 +6,9 @@
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
-configure: configure-stamp
+include /usr/share/dpatch/dpatch.make
+
+configure: patch configure-stamp
configure-stamp:
dh_testdir
# Add here commands to configure the package.
@@ -27,7 +29,7 @@
touch build-stamp
-clean:
+clean: unpatch
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
@@ -89 +91 @@
-.PHONY: build clean binary-indep binary-arch binary install configure
+.PHONY: build clean binary-indep binary-arch binary install configure patch
diff -u openttd-0.6.2/debian/changelog openttd-0.6.2/debian/changelog
--- openttd-0.6.2/debian/changelog
+++ openttd-0.6.2/debian/changelog
@@ -1,3 +1,11 @@
+openttd (0.6.2-1+lenny1) stable-security; urgency=high
+
+ * [2e78e5e] Add dpatch machinery again.
+ * [32e6e00] Backport upstream r18462 to fix remote crash vulnerability
+CVE-2009-4007.
+
+ -- Matthijs Kooijman matth...@stdin.nl Tue, 22 Dec 2009 14:50:56 +0100
+
openttd (0.6.2-1) unstable; urgency=low
* New upstream release.
only in patch2:
unchanged:
--- openttd-0.6.2.orig/debian/patches/00list
+++ openttd-0.6.2/debian/patches/00list
@@ -0,0 +1 @@
+01-fix-remote-crash
only in patch2:
unchanged:
--- openttd-0.6.2.orig/debian/patches/01-fix-remote-crash.dpatch
+++ openttd-0.6.2/debian/patches/01-fix-remote-crash.dpatch
@@ -0,0 +1,21 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## fix-remote-crash.dpatch by matth...@stdin.nl
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Fix remote crash vulnerability. Upstream r18462.
+
+...@dpatch@
+diff -urNad openttd-git~/src/train_cmd.cpp openttd-git/src/train_cmd.cpp
+--- openttd-git~/src/train_cmd.cpp 2009-12-16 12:36:00.0 +0100
openttd-git/src/train_cmd.cpp 2009-12-16 13:49:58.0 +0100
+@@ -996,10 +996,6 @@
+ */
+ static void NormaliseTrainConsist(Vehicle *v)
+ {
+- if (IsFreeWagon(v)) return;
+-
+- assert(IsFrontEngine(v));
+-
+ for (; v != NULL; v = GetNextVehicle(v)) {
+ if (!IsMultiheaded(v) || !IsTrainEngine(v)) continue;
+
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561583: ITP: nforenum -- A format correcter and linter for the NFO programming language.
Package: wnpp Severity: wishlist Owner: Matthijs Kooijman matth...@stdin.nl * Package name: nforenum Version : 3.4.6+svn2274 Upstream Author : Dale McCoy dales...@gmail.com * URL : http://users.tt-forums.net/dalestan/nforenum/ http://www.openttd.org/en/download-nforenum * License : GPL-2+ Programming Lang: C / C++ Description : A format correcter and linter for the NFO programming language. The NFO programming language is used in the graphic file format from the Transport Tycoon Deluxe, TTDPatch and OpenTTD games. . It takes as input any number of files that contain something that vaguely resembles valid NFO, and produces, to the best of its ability, encodable NFO files, one for each input file. . It also detects and warns about some common mistakes made in NFO coding. A pretty-printer is also included. This package is needed to compile the opengfx package (http://dev.openttdcoop.org/projects/opengfx), which I intend to package as well. (http://dev.openttdcoop.org/projects/opengfx), which I intend to package as well soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561346: [PATCH] Add support for a Git-Dch: Ignore metaheader.
Fixed version of this patch, I missed that parse_commit was used twice
on my first try. Sorry for that.
Closes: #561346
Thanks: Matthijs Kooijman
---
docs/chapters/releases.sgml | 18 +
docs/manpages/git-dch.sgml |4 +-
git-dch | 58 +-
3 files changed, 60 insertions(+), 20 deletions(-)
diff --git a/docs/chapters/releases.sgml b/docs/chapters/releases.sgml
index 95c2335..00fb76f 100644
--- a/docs/chapters/releases.sgml
+++ b/docs/chapters/releases.sgml
@@ -115,5 +115,23 @@ via git-dch;'s option--id-length/option option. Using
/screen
This makes it much easier to see which commit actually fixed bug #1000.
/para
+para
+Finally, there is the optionGit-Dch:/option header that can
+currently only be set to optionIgnore/option (or omitted). When this
+header is set to optionIgnore/option, the commit message is
+completely ignored and will not be included in the changelog at all.
+This is useful for janitorial commits or other commits that really don't
+need to end up in the changelog.
+
+/parapara
+For example, the following git commit message
+screen
+Set correct branchnames in debian/gbp.conf
+
+Git-Dch: Ignore
+/screen
+will not show up in the generated changelog in any way.
+/para
+
/sect1
/chapter
diff --git a/docs/manpages/git-dch.sgml b/docs/manpages/git-dch.sgml
index 890df67..4c4a6f7 100644
--- a/docs/manpages/git-dch.sgml
+++ b/docs/manpages/git-dch.sgml
@@ -107,8 +107,8 @@
varlistentry
termoption--[no-]meta/option/term
listitem
- paraParse meta tags like optionCloses:/option and
- optionThanks:/option. /para
+ paraParse meta tags like optionCloses:/option,
+ optionThanks:/option and optionGit-Dch:/option. /para
/listitem
/varlistentry
varlistentry
diff --git a/git-dch b/git-dch
index 1051f82..b68ea72 100755
--- a/git-dch
+++ b/git-dch
@@ -198,6 +198,7 @@ def parse_commit(repo, commitid, options):
msg = ''
thanks = ''
closes = ''
+git_dch = ''
bugs = {}
bts_closes = re.compile(r'(?Pbts%s):\s+%s' % (options.meta_closes,
bug_r), re.I)
@@ -217,6 +218,8 @@ def parse_commit(repo, commitid, options):
bugs[m.group('bts')] = bug_nums
elif line.startswith('Thanks: '):
thanks = line.split(' ', 1)[1].strip()
+elif line.startswith('Git-Dch: '):
+git_dch = line.split(' ', 1)[1].strip()
else: # normal commit message
if msg and not options.full:
continue
@@ -226,6 +229,8 @@ def parse_commit(repo, commitid, options):
elif line.startswith('diff '):
break
if options.meta:
+if git_dch == 'Ignore':
+return None
for bts in bugs:
closes += '(%s: %s) ' % (bts, ', '.join(bugs[bts]))
if thanks:
@@ -241,8 +246,11 @@ def shortlog_to_dch(repo, commits, options):
author = 'Unknown'
for commit in commits:
-msg, (author, email) = parse_commit(repo, commit, options)
-add_changelog_entry(msg, author, email)
+parsed = parse_commit(repo, commit, options)
+# Allow commits to be ignored.
+if parsed:
+msg, (author, email) = parsed
+add_changelog_entry(msg, author, email)
def guess_snapshot_commit(cp, repo, options):
@@ -371,25 +379,39 @@ def main(argv):
else:
add_section = False
-if add_section:
-if commits:
-first_commit = commits[0]
-commits = commits[1:]
-commit_msg, (commit_author, commit_email) = parse_commit(repo,
first_commit, options)
+for c in commits:
+parsed = parse_commit(repo, c, options)
+if not parsed:
+# Some commits can be ignored
+continue
+
+commit_msg, (commit_author, commit_email) = parsed
+if add_section:
+# Add a section containing just this message (we can't
+# add an empty section with dch).
+add_changelog_section(distribution=UNRELEASED,
msg=commit_msg,
+ version=options.new_version,
author=commit_author,
+ email=commit_email)
+# Adding a section only needs to happen once.
+add_section = False
else:
-commit_msg = UNRELEASED
-commit_author = None
-commit_email = None
-add_changelog_section(distribution=UNRELEASED, msg=commit_msg,
- version=options.new_version,
author=commit_author,
- email=commit_email)
-
-if commits:
-shortlog_to_dch(repo, commits, options)
-fixup_trailer(repo, git_author=options.git_author)
-elif
Bug#561346: [PATCH] Fix previous commit, there was a second use of parse_commit.
Both uses of parse_commit now support the None return value. The shortlog_to_dch function was deprecated. --- git-dch | 58 ++ 1 files changed, 30 insertions(+), 28 deletions(-) diff --git a/git-dch b/git-dch index b3ceb59..57b508a 100755 --- a/git-dch +++ b/git-dch @@ -241,18 +241,6 @@ def parse_commit(repo, commitid, options): return msg, (author, email) -def shortlog_to_dch(repo, commits, options): -convert the changes in git shortlog format to debian changelog format -author = 'Unknown' - -for commit in commits: -parsed = parse_commit(repo, commit, options) -# Allow commits to be ignored. -if parsed: -msg, (author, email) = parsed -add_changelog_entry(msg, author, email) - - def guess_snapshot_commit(cp, repo, options): guess the last commit documented in the changelog from the snapshot banner @@ -379,25 +367,39 @@ def main(argv): else: add_section = False -if add_section: -if commits: -first_commit = commits[0] -commits = commits[1:] -commit_msg, (commit_author, commit_email) = parse_commit(repo, first_commit, options) +for c in commits: +parsed = parse_commit(repo, c, options) +if not parsed: +# Some commits can be ignored +continue + +commit_msg, (commit_author, commit_email) = parsed +if add_section: +# Add a section containing just this message (we can't +# add an empty section with dch). +add_changelog_section(distribution=UNRELEASED, msg=commit_msg, + version=options.new_version, author=commit_author, + email=commit_email) +# Adding a section only needs to happen once. +add_section = False else: -commit_msg = UNRELEASED -commit_author = None -commit_email = None -add_changelog_section(distribution=UNRELEASED, msg=commit_msg, - version=options.new_version, author=commit_author, - email=commit_email) - -if commits: -shortlog_to_dch(repo, commits, options) -fixup_trailer(repo, git_author=options.git_author) -elif not first_commit: +add_changelog_entry(commit_msg, commit_author, commit_email) + + +# Show a message if there were no commits (not even ignored +# commits). +if not commits: print No changes detected from %s to %s. % (since, until) +if add_section: +# If we end up here, then there were no commits to include, +# so we put a dummy message in the new section. +commit_msg = UNRELEASED +add_changelog_section(distribution=UNRELEASED, msg=UNRELEASED, + version=options.new_version) + +fixup_trailer(repo, git_author=options.git_author) + if options.release: do_release(changelog, cp) elif options.snapshot: -- 1.6.5.4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561454: git-buildpackage: .git/gbp_index file is incorrectly reused with --git-export=WC
Package: git-buildpackage Version: 0.4.62 Severity: normal Hi, I've been bit by a nasty and subtle bug yesterday when using --git-export=WC in the same checkout for multiple versions of my packaged software. I'll get straight down to the cause of the bug. When --git-export=WC is given, the function write_wc in git-buildpackage creates a tree object by adding all files in the working copy to the index. To prevent messing up the current index, it sets GIT_INDEX_FILE to .git/gbp_index. However, no effort is made to clean up this index file, either before or afterwards. This means that if I have files in my working copy, I run git-buildpackage with --git-export=WC, remove the files and run it again, these files will still be in the exported build dir. I'm not sure if the index file is still needed after write_wc is done, but perhaps the file can simply be removed afterwards? Alternatively, a git rm -r --cached . before the git add -f . could be more robust. Even more pretty would probably be to remove the file afterwards, but also check that it doesn't exist yet beforehand (and error out if it does). Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-rc8 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-buildpackage depends on: ii devscripts 2.10.59 scripts to make the life of a Debi ii git-core 1:1.6.5.4-1 fast, scalable, distributed revisi ii python 2.5.4-4 An interactive high-level object-o ii python-dateutil 1.4.1-3 powerful extensions to the standar ii python-support 1.0.6 automated rebuilding support for P Versions of packages git-buildpackage recommends: ii pristine-tar 1.00 regenerate pristine tarballs Versions of packages git-buildpackage suggests: pn git-load-dirs none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561457: git-buildpackage: Runs debian/rules without checking build dependencies
Package: git-buildpackage Version: 0.4.62 Severity: normal Hi, One of the first things git-buildpackage does is running debian/rules (for some purpose I haven't yet figured out, nor really tried to). Anyway, it does so without checking the build dependencies first, which might break things without a pretty error message. For example, when I run git-buildpackage on itself, I get: matth...@xanthe:~/docs/src/upstream/git-buildpackage$ git-buildpackage debian/rules:6: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory debian/rules:7: /usr/share/cdbs/1/class/python-distutils.mk: No such file or directory make: *** No rule to make target `/usr/share/cdbs/1/class/python-distutils.mk'. Stop. debuild: fatal error at line 1312: couldn't exec fakeroot debian/rules: debuild -d clean returned 2 Couldn't run 'debuild -d clean' Whereas running dpkg-buildpackage aborts with a nice error: dpkg-checkbuilddeps: Unmet build dependencies: cdbs gtk-doc-tools sgml2x jade Perhaps git-buildpackage should run dpkg-checkbuilddeps as well? Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-rc8 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-buildpackage depends on: ii devscripts 2.10.59 scripts to make the life of a Debi ii git-core 1:1.6.5.4-1 fast, scalable, distributed revisi ii python 2.5.4-4 An interactive high-level object-o ii python-dateutil 1.4.1-3 powerful extensions to the standar ii python-support 1.0.6 automated rebuilding support for P Versions of packages git-buildpackage recommends: ii pristine-tar 1.00 regenerate pristine tarballs Versions of packages git-buildpackage suggests: pn git-load-dirs none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561346: [PATCH] Add support for a Git-Dch: Ignore metaheader.
Closes: #561346
Thanks: Matthijs Kooijman
---
docs/chapters/releases.sgml | 18 ++
docs/manpages/git-dch.sgml |4 ++--
git-dch | 12 ++--
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/docs/chapters/releases.sgml b/docs/chapters/releases.sgml
index 95c2335..00fb76f 100644
--- a/docs/chapters/releases.sgml
+++ b/docs/chapters/releases.sgml
@@ -115,5 +115,23 @@ via git-dch;'s option--id-length/option option. Using
/screen
This makes it much easier to see which commit actually fixed bug #1000.
/para
+para
+Finally, there is the optionGit-Dch:/option header that can
+currently only be set to optionIgnore/option (or omitted). When this
+header is set to optionIgnore/option, the commit message is
+completely ignored and will not be included in the changelog at all.
+This is useful for janitorial commits or other commits that really don't
+need to end up in the changelog.
+
+/parapara
+For example, the following git commit message
+screen
+Set correct branchnames in debian/gbp.conf
+
+Git-Dch: Ignore
+/screen
+will not show up in the generated changelog in any way.
+/para
+
/sect1
/chapter
diff --git a/docs/manpages/git-dch.sgml b/docs/manpages/git-dch.sgml
index 890df67..4c4a6f7 100644
--- a/docs/manpages/git-dch.sgml
+++ b/docs/manpages/git-dch.sgml
@@ -107,8 +107,8 @@
varlistentry
termoption--[no-]meta/option/term
listitem
- paraParse meta tags like optionCloses:/option and
- optionThanks:/option. /para
+ paraParse meta tags like optionCloses:/option,
+ optionThanks:/option and optionGit-Dch:/option. /para
/listitem
/varlistentry
varlistentry
diff --git a/git-dch b/git-dch
index 1051f82..b3ceb59 100755
--- a/git-dch
+++ b/git-dch
@@ -198,6 +198,7 @@ def parse_commit(repo, commitid, options):
msg = ''
thanks = ''
closes = ''
+git_dch = ''
bugs = {}
bts_closes = re.compile(r'(?Pbts%s):\s+%s' % (options.meta_closes,
bug_r), re.I)
@@ -217,6 +218,8 @@ def parse_commit(repo, commitid, options):
bugs[m.group('bts')] = bug_nums
elif line.startswith('Thanks: '):
thanks = line.split(' ', 1)[1].strip()
+elif line.startswith('Git-Dch: '):
+git_dch = line.split(' ', 1)[1].strip()
else: # normal commit message
if msg and not options.full:
continue
@@ -226,6 +229,8 @@ def parse_commit(repo, commitid, options):
elif line.startswith('diff '):
break
if options.meta:
+if git_dch == 'Ignore':
+return None
for bts in bugs:
closes += '(%s: %s) ' % (bts, ', '.join(bugs[bts]))
if thanks:
@@ -241,8 +246,11 @@ def shortlog_to_dch(repo, commits, options):
author = 'Unknown'
for commit in commits:
-msg, (author, email) = parse_commit(repo, commit, options)
-add_changelog_entry(msg, author, email)
+parsed = parse_commit(repo, commit, options)
+# Allow commits to be ignored.
+if parsed:
+msg, (author, email) = parsed
+add_changelog_entry(msg, author, email)
def guess_snapshot_commit(cp, repo, options):
--
1.6.5.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561346: [git-buildpackage/master] Add support for a Git-Dch: Ignore metaheader.
tag 561346 pending thanks Date: Thu Dec 17 12:54:23 2009 +0100 Author: Matthijs Kooijman matth...@stdin.nl Commit ID: 725b9d34b81a1a415ac710458487a78d4f4f4e09 Commit URL: http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff;h=725b9d34b81a1a415ac710458487a78d4f4f4e09 Patch URL: http://git.debian.org/?p=users/agx/git-buildpackage.git;a=commitdiff_plain;h=725b9d34b81a1a415ac710458487a78d4f4f4e09 Add support for a Git-Dch: Ignore metaheader. Closes: #561346 Thanks: Matthijs Kooijman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561346: git-buildpackage: Allow explicitly marking git changelog entries to be ignored by git-dch
Package: git-buildpackage Version: 0.4.62 Severity: wishlist Hi, I've started using git-buildpackage recentely and have encountered the need for explicitly marking git commits to be ignored by git-dch. While working with the package, there are some commits which are really trivial or so specific to the buildsystem, that I don't think they should end up in the Debian changelog. For example, I just committed a .gbp.conf file to a branch, which is really not interesting to end users of the package. I could of course remove the entry after generating the final changelog, but marking it as uninteresting up-front makes more sense to me. This request seems similar to #523751, but that wishlist bug really addresses a different issue. I would propose adding an extra meta header Git-Dch: Ignore (or Exclude?). Alternatively, a header like Git-Dch-Exclude or Git-Dch-Ignore without a value could be used, though that's less consistent with Closes: and Thanks. My preference would be a Git-Dch: Ignore header. I think a (commandline) option like --meta-closes is not needed for this header? Implementation of this feature should be simple, if there is interest I could whip up a patch. Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-rc8 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-buildpackage depends on: ii devscripts 2.10.59 scripts to make the life of a Debi ii git-core 1:1.6.5.4-1 fast, scalable, distributed revisi ii python 2.5.4-4 An interactive high-level object-o ii python-dateutil 1.4.1-3 powerful extensions to the standar ii python-support 1.0.6 automated rebuilding support for P Versions of packages git-buildpackage recommends: ii pristine-tar 1.00 regenerate pristine tarballs Versions of packages git-buildpackage suggests: pn git-load-dirs none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560810: Please, package the free data and move openttd to main
Hi Jan, Please, consider packaging these data for OpenTTD. I've considered this before, and already decided that I'd give it a shot. I just haven't found the time so far. This matter is slightly complicated by the fact that OpenGFX needs some extra tools grfcodec and something else IIRC that would need to be packaged first, but that's only some extra work, not a problem. Another open issue is how to handle the existing run with original files capbility. There are some datafiles (from the openttd source package) needed together with the original TTD files (e.g., some extra graphics). OpenGFX doesn't require these files, so putting them in a separate openttd-original-graphics-compatibility package (but with a shorter name :-p) might make sense (but how to handle upgrades, then?). This needs some further thought as well. Summarizing: Good idea, I hope to get around to it Real Soon now. Gr. Matthijs signature.asc Description: Digital signature
Bug#550951: openttd: Should support cross-compilation
Package: openttd Version: 0.7.3-1 Severity: wishlist In line with the emdebian goals, openttd should support being cross compiled. See http://lists.debian.org/debian-devel/2007/11/msg00116.html The changes needed should be fairly trivial, for an example patch see #465292 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465292). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks, no it is not the opposite. the hook should *not* be run for linux-images out of linux-2.6 they take care to run update-initramfs in their postinst. those are the official and supported linux images in Debian. Hmm, apparently I've quite misunderstood then. I've always thought that this hook was needed for the official images, but apparently that's not the case. If so, do I understand the following correctly: 1) Official images run update-initramfs themselves. 2) Official images also pass the second argument to the kernel hooks. Probably because of the original comment (# kernel-package passes an extra arg; hack to not run under kernel-package) I thought that 2 was untrue (and thus, 1 as well). But this comment was probably not complete, then. But if the above is true, are there any kernel images that don't pass the second argument? no aboves sentence is wrong (see above) and much too long. I don't quite think that a four line comment can be too long, especially for complicated stuff like this... # Kernel-package passes the path to the vmlinuz file as a second argument, # which might not be in /boot. well that is a strange feature anyway that i don't want to feature too much. I'm not sure how many people will be reading the kernel install hooks, and people who do will probably not start using this just because they can... Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks, fixed in latest git, also added 2 small comment lines, which should make code intent clearer, please review happy to add/change them. Hmm, I'm not so sure if this comment helps. The file now says # official linux-images take care themself which would suggest this hook should _not_ run for official images, while it is quite the opposite. I'd write something like: # Don't run for kernels generated by older versions of kernel-package, since # those took care of generating initramfs themselves (but didn't set # KERNEL_PACKAGE_VERSION yet). See #523735. Always run for newer version of # kernel-package and the official Debian kernels. And perhaps a few lines up (where you set bootdir): # Kernel-package passes the path to the vmlinuz file as a second argument, # which might not be in /boot. Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks, Done in my local git repo. The next upload of kernel-package, 12.018, will export KERNEL_PACKAGE_VERSION (and also STEM, usually linux) into the environment. Nice. support added, please verify in latest initramfs git, see http://git.debian.org/?p=kernel/initramfs-tools.git I'm not completely sure how the patch works. From how I read it, there are three changes: 1) When ran by kernel-package, and a second argument is passed, use that as the boot dir passed with -b to update-initramfs. This seems like a good idea, but seems unrelated to the main change. 2) When $DEB_MAINT_PARAMS is set, only run if it starts with configure. I'm completely unaware of where this variable comes from and who sets it, but this also seems unrelated (unless the official kernel images and newer kernel-package versions set this, while older versions do not?). 3) The If I'm called by kernel-package, don't run check has been completely removed. This is the main change in the commit, but I think it is a bit stronger than we had discussed (See below). As for the third point, my original proposal was as follows: I propose the following: Let kernel-package expose a KERNEL_PACKAGE_VERSION variable to /etc/kernel/postinst.d scripts. This allows the initramfs-tools script to generate an initrd if a) KERNEL_PACKAGE_VERSION = 12.001 b) KERNEL_PACKAGE_VERSION is not set and there is only a single argument is passed (e.g., for official kernels). The first part (expose KERNEL_PACKAGE_VERSION) was implemented in kernel-package 12.018, but it seems the checks proposed have been removed alltogether. This might be intentional (which means dropping support for kernels generated with kernel-package 12.001)? Actually, we're not even dropping support alltogether, since the only effect would be that update-initramfs is called twice for kernels generated with 12.001. It might even be a good idea, since the alternative (as proposed by me above) would mean still supporting kernel-package 12.001, but breaking kernel-package = 12.001 12.018. On a second reading of the diff, it seems by point 3) above is invalid. The first if clause also contains an exit 0, which causes the update-initramfs to be not run if a second argument is passed but KERNEL_PACKAGE_VERSION is not set (e.g., for kernel-package 12.018). This is pretty much my proposal (just without the = 12.001 version check, but since KERNEL_PACKAGE_VERSION will never be below 12.018, this is the same). However, I've nearly convinced myself that removing the check and always running update-initramfs-tools might be the better approach, since it makes all kernels work out of the box (generating the initramfs twice for 12.001, but that's more acceptable than not generating any for = 12.001 12.018 I think?). So, perhaps we should remove one more check? Manoj? Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
[Snip DEB_MAINT_PARAMS stuff] This is from a proposal initially by Frans Pop, and allows passing through of the maintainer script parameters to the scripts being run. This way, we only build he initramfs when initially configured. This is a good thing. Ah, right. I think I've seen multiple initramfs runs for the same kernel, yes. Nice to have that fixed. I think I would agree with maks here, and let the current code go forward as is. Thiswoud certainly give us consistency for Squeeze, and continue to work as it always did for Lenny backports, and the ongoing support for = 12.001 12.018 generated images is not important enough to spend more time on this. Okay, perfect! The only final comment I'd have is that one or two comments wouldn't look bad in the script, if only to tell any reader why this checking happens (perhaps link to this bug as well). Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi maks,
support added, please verify in latest initramfs git, see
http://git.debian.org/?p=kernel/initramfs-tools.git
There's a typo in there, I get:
/etc/kernel/postrm.d/initramfs-tools: line 12: =: command not found
It says:
${bootdir}= $(dirname $2)
which should be:
bootdir=$(dirname $2)
With this change, everything works as expected for me. (I did get a bit
confused,
since something hides the output from the script, including my debug output.
Not sure where or why that happens though)
Gr.
Matthijs
signature.asc
Description: Digital signature
Bug#547705: grub-pc: Screws up default entry in menu.lst when updatedefaultentry is false
Package: grub-pc
Version: 1.97~beta3-1
Severity: normal
Hi,
I've upgraded grub to grub-pc, which does some magic chainloading (on my
request). However, this screwed up my default entry in menu.lst, which
used to read default saved and now reads default 0saved.
From following the logic in /usr/lib/grub-legacy/update-grub, it seems
this is caused by updatedefaultentry not being set.
The following code parses the current default entry, including the setting of
use_grub_set_default. Note that this does not happen when updatedefaultentry is
false.
#Finding the value the default line
use_grub_set_default=false
if test $updatedefaultentry = true ; then
defaultEntryNumber=$(sed -ne
's/^[[:blank:]]*default[[:blank:]]*\(.*\).*/\1/p' $menu)
if [ $defaultEntryNumber = saved ] ; then
defaultEntryNumber=$(sed 'q' $grub_dir/default)
use_grub_set_default=true
fi
if test -n $defaultEntryNumber; then
defaultEntryNumberPlusOne=$(expr $defaultEntryNumber \+
1);
defaultEntry=$(grep ^[[:blank:]]*title $menu | sed
-ne ${defaultEntryNumberPlusOne}p | sed -ne
;s/^[[:blank:]]*title[[:blank:]]*//p)
defaultEntry=$(echo $defaultEntry | sed -e
s/[[:blank:]]*$//) # don't trust trailing blanks
else
notChangeDefault=yes
fi
else
notChangeDefault=yes
fi
Further down, the default number is updated in the generated menu.lst file. The
actual code for the non-grub2 case is removed. Note that if grub 2 is not being
installed, the default is not changed when notChangeDefault is set, which is
the case if updatedefaultentry is false (see the final else clause above).
#Updating the default number
if [ $LET_US_TRY_GRUB_2 = true ] test -f /boot/grub/core.img ;
then
set_default_value 0
elif test -z $notChangeDefault; then
[ Code removed ]
fi
This code uses the set_default_value function, which looks like:
# Function to update the default value
set_default_value() {
if [ $use_grub_set_default = true ] ; then
if [ -f /usr/lib/grub-legacy/grub-set-default ] ; then
/usr/lib/grub-legacy/grub-set-default $1
else
grub-set-default $1
fi
else
value=$1
newmenu=$(tempfile)
sed -e
s/^[[:blank:]]*default[[:blank:]]*[[:digit:]]*\(.*\)/default
${value}\1/;b $menu $newmenu
cat $newmenu $menu
rm -f $newmenu
unset newmenu
fi
}
Here, the second half of the if contains a sed that matches numbers only (which
seems to make sense, since it only runs if use_grub_set_default is false,
right?). However, this breaks when the default config is saved and not a
number, which can occur as shown above.
To fix this, I'd probably change the first snippet above, to not check for
updatedefaultentry if LET_US_TRY_GRUB_2 is set. This might get complicated,
though, so perhaps something more elegant can be done?
Gr.
Matthijs
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31-rc8 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages grub-pc depends on:
ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii grub-common 1.97~beta3-1 GRand Unified Bootloader, version
ii libc6 2.9-26 GNU C Library: Shared libraries
ii ucf 3.0022 Update Configuration File: preserv
grub-pc recommends no packages.
Versions of packages grub-pc suggests:
ii desktop-base 5.0.5 common files for the Debian Deskto
ii genisoimage 9:1.1.9-1 Creates ISO-9660 CD-ROM filesystem
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547710: grub-pc: Sets wrong default when entries are present before the kernel list
Package: grub-pc Version: 1.97~beta3-1 Severity: normal Hi, when upgrading from grub-legacy to grub-pc, my default entry changed wrongly. From reading the post-install script and /usr/lib/grub-legacy/update-grub I understand that the idea is to, when chainloading is selected, set grub2 as the default option. It does this by forcing the default to 0 in update-grub. However, the chainloaded GRUB2 is not generally the first entry. It will be the first entry inside the automagically generated kernels list, but (as in my case) there might be entries above that (resulting in my grub booting windows by default). I guess the hard setting of default to 0 should be changed to something that counts the title.* lines before the begin of the kernel list? Gr. Matthijs -- Package-specific info: *** BEGIN /proc/mounts /dev/mapper/Xanthe-root / ext3 rw,relatime,errors=remount-ro,commit=360,data=writeback 0 0 /dev/hda2 /boot ext3 rw,relatime,errors=continue,commit=360,data=writeback 0 0 /dev/mapper/Xanthe-home /home ext3 rw,relatime,errors=continue,commit=360,data=writeback 0 0 *** END /proc/mounts *** BEGIN /boot/grub/device.map (hd0) /dev/hda *** END /boot/grub/device.map *** BEGIN /boot/grub/grub.cfg -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc8 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages grub-pc depends on: ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy ii grub-common 1.97~beta3-1 GRand Unified Bootloader, version ii libc6 2.9-26 GNU C Library: Shared libraries ii ucf 3.0022 Update Configuration File: preserv grub-pc recommends no packages. Versions of packages grub-pc suggests: ii desktop-base 5.0.5 common files for the Debian Deskto ii genisoimage 9:1.1.9-1 Creates ISO-9660 CD-ROM filesystem -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547705: grub-pc: Screws up default entry in menu.lst when updatedefaultentry is false
Hi, reassign 547705 grub-legacy reassign 465144 grub-legacy forcemerge 465144 547705 Sorry about that duplicate. I had checked grub-legacy as well as grub-pc, but apparently that other report was reassigned to grub (which I didn't check, since it's a dummy package...). Even though this bug affects grub2, it still needs to be fixed in grub-legacy. Why is this? The broken script is shipped with the grub-pc package? When things break, grub-legacy is no longer around. $ dpkg -L grub-pc| grep grub-legacy/update-grub /usr/lib/grub-legacy/update-grub Gr. Matthijs signature.asc Description: Digital signature
Bug#547714: Upgrade process from grub-legacy to grub-pc is unclear
Package: grub-pc Version: 1.97~beta3-1 Severity: normal Hi, I've been upgrading from grub-legacy to grub-pc recently, and it's quite unclear to me how this should work. I think it might be useful to have a README.Debian (In grub-pc, I'd say) that explains how this process is supposed to work. Some points of confusion: * aptitude tells me that grub-legacy will be replaced with grub-pc. E.g, grub-legacy will be removed. Then, during configuration, I get a prompt asking me to chainload grub-pc into grub-legacy, since grub-pc doesn't always work. But... I just removed grub-legacy? What if it doesn't work? How can I even chainload grub-pc into grub-legacy when the latter was removed? Scary... * In hindsight, I suspect all this works because grub-legacy is still installed into my mbr, and there is crap left behind in my /boot/grub (stage1, stage2). Seems a bit brittle to keep relying on a package that's only lingering around in the mbr, but this has probably been discussed already. * Grub-pc ships all kinds of legacy stuff (in particular update-grub) which do not seem to make sense there. * Grub-pc asks me if I want to chainload it, so I can test it comfortably. However, I did not expect grub2 to become the default. If I'm running on a server with limited physical access, this might cause problems to an unaware administrator. Perhaps not selecting grub-pc by default, or adding a note about this to the chainloading prompt is in order? * Grub-pc replaces grub-legacy, meaning it will uninstall grub-legacy and replace it with grub-pc when doing a full upgrade. But, what if grub-pc doesn't work for me? Reinstalling grub-legacy will probably not work, since that will be replaced by grub-pc again on the next upgrade right? Should I put grub-legacy in the hold state then? That will prevent upgrades. Should I hold grub-pc? I'm quite aware that this might appear as a nagging point, but I'm quite convinced that there is a real problem here. I consider myself quite an advanced user, and even I don't quite understand how it works. Adding a README.Debian might not even be sufficient, perhaps some debconf prompting with a pointer would be even better. Gr. Matthijs (This was my last report, really! :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547714: Upgrade process from grub-legacy to grub-pc is unclear
Hi Felix,
What all kind of legacy stuff?
It's actually only legacy/update-grub and legacy/grub-set-default for
the chainload to GRUB 2 option.
Yeah, that's what I've seen. Also, the stuff lying around in /boot, but
I've learned now that that's stuff from grub-installing.
So if we would drop the stub then every Debian user + grub-installer
need to be changed to use /etc/kernel/{postinst,postrm}.d
And we got a bug report against grub2 from someone who still
had /sbin/update-grub in his kernel-img.conf even though grub-legacy
warns still the etch release that this has been deprecated.
And Debian/Ubuntu users are just used to `update-grub' instead of
`grub-mkconfig -o /boot/grub/grub.cfg'
Having update-grub around is probably fine, it's not really any legacy instead
of the name.
OTOH, chaning things to use /etc/kernel/ hooks might not be bad. I think that
at least initramfs is using this over custom hooks in kerel-img.conf (but this
is probably another issue, so don't bother to respond :-p).
* Grub-pc replaces grub-legacy, meaning it will uninstall
grub-legacy and replace it with grub-pc when doing a full upgrade.
But, what if grub-pc doesn't work for me? Reinstalling grub-legacy
will probably not work, since that will be replaced by grub-pc
again on the next upgrade right? Should I put grub-legacy in the
hold state then? That will prevent upgrades. Should I hold
grub-pc?
No, It's just the `grub' package which was first a dummy one depending
on `grub-legacy' with the debconf note that warned about that and then
it changed to depend on `grub-pc'.
Ah, just a Replaces: dependency is not enough for apt to replace grub-legacy
with grub-pc on its own, but it only allows it to know to remove grub-legacy
when installing grub-pc for another reason (e.g., the dependency of the grub
package). So, removing grub and grub-pc and reinstalling grub-legacy should
get grub-legacy back. Probably also something to note in README.Debian.
(This was my last report, really! :-)
I assume at least for grub2 and today. But if you find other bugs
especially important ones then I hope you still tell us :)
I mostly meant, the last report on the upgrade process, since I don't intend
to do that again :-)
Gr.
Matthijs
signature.asc
Description: Digital signature
Bug#546884: Default Bcc handling (still) broken in some cases
Package: mutt Severity: important Version: 1.5.18-6+b1 Hi, Glad that the docs are updated [1] to reflect that exim4 does not strip Bcc headers (which I just confirmed with a field test of just under 200 people who are now pissed to have their email addresses published...), but I would still appreciate it if the default configuration would work. The arguments that were posted after #304718 was closed [2] actually still apply. Considering that people really expect their Bcc to work, and making it not work is quite a critical failure with all sorts of privacy issues, I would really like to see a solution for this. The obvious solution would be to unset write_bcc again, also considering that it is not at all clear whose task removing Bcc headers really is. Saying exim or the MTA should do this is fine from a theoretical point of view, but as long as they're not doing it (and not doing it intentionally, see [3] and [4]) In cases like these, I'd rather have a default setting that does double work in some cases, than a setting that might not remove the Bcc headers in some cases... I understand that it makes sense to stick to the upstream default configuration in this case, but perhaps this should be taken up with upstream as well? Gr. Matthijs [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474194 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304718#66 [3]: http://www.exim.org/lurker/message/20040818.103822.955b3e9f.en.html [4]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=485751 signature.asc Description: Digital signature
Bug#546630: jaaa: Does not start due to wrong (old?) libpulse0 library linked
Package: jaaa Version: 0.4.2-1 Severity: important Justification: renders package unusable Hi, When starting jaaa, I see: matth...@xanthe:~$ jaaa jaaa: error while loading shared libraries: libjack-0.100.0.so.0: cannot open shared object file: No such file or directory I indeed have no libjack-0.100.0.so.0, just a libjack.so.0.0.28, libjack0.so.0 and libjack.so. Packages.debian.org suggests that this file was present in libjack0 0.116.1-4 (I only found this because m68k ships an older version, see http://packages.debian.org/sid/libjack0 and http://packages.debian.org/sid/m68k/libjack0/filelist ). Assuming that jaaa worked when it was uploaded, I expect that a libjack0 upgrade did indeed break this. It seems this change was discussed on debian-release: http://osdir.com/ml/debian-release/2009-03/msg00313.html It seems this package just needs a rebuild, perhaps a trivial control file update. It still works with the newer libjack packages, adding a manual symlink makes jaaa work just fine: /usr/lib$ sudo ln -s libjack.so.0.0.28 libjack-0.100.0.so.0 I'm marking this important, since I expect this breaks for everybody. On the other hand, it seems unlikely that this has gone unnoticed if this was the case, so I'm not marking this grave. Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc8 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages jaaa depends on: ii libasound2 1.0.20-3 shared library for ALSA applicatio ii libc6 2.9-25GNU C Library: Shared libraries ii libclalsadrv1 1.2.2-1 ALSA driver C++ access library ii libclthreads2 2.4.0-1 POSIX threads C++ access library ii libclxclient3 3.6.1-1 X Window System C++ access library ii libfftw3-3 3.2.1-2.1 library for computing Fast Fourier ii libgcc11:4.4.1-3 GCC support library ii libjack0 0.116.2+svn3592-3 JACK Audio Connection Kit (librari ii libstdc++6 4.4.1-3 The GNU Standard C++ Library v3 ii libx11-6 2:1.2.2-1 X11 client-side library ii libxft22.1.13-3 FreeType-based font drawing librar jaaa recommends no packages. jaaa suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515599: fail2ban: Use custom hook chains
Package: fail2ban Version: 0.8.3-2sid1 Followup-For: Bug #515599 Hi, it seems your idea of providing hooks for fail2ban is sensible, though the extra magic grep involved in finding the hook is fragile. I would propose using a custom chain instead of a dummy rule, which is the approach taken by the Vuurmuur firewall. It creates a new chain called PRE-VRMR-INPUT, which is called unconditionally from the INPUT chain, before Vuurmuur's own rules. The contents of this chain are never touched by Vuurmuur, so if fail2ban would add its rules to that chain instead of INPUT, everything would be fine for Vuurmuur. In fact, it does not seem unreasonable for other firewalls to provide similar hook chains, perhaps they even do so already. If you need even more control (say, for calling a whitelist before fail2ban), you could arrange this in vuurmuur by inserting a CHAIN rule (which just calls another chain, say the chain FAIL2BAN) and point fail2ban to the called chain. This does require some configuration of fail2ban to find the right chain, but I don't think there can be any other general solution to this problem (without making all firewalls aware of fail2ban, which isn't very pretty). To make this work, fail2ban should add a chain configuration variable, which simply defaults to INPUT. This has the advantage of still working out-of-the-box when there is no other firewall involved, and if there is, there is only a small configuration change needed. I've submitted a feature request for this upstream [1], though halfway through writing it I found out that this configuration wouldn't be terribly convenient with upstream's default configuration. It would work just fine with Debian's, since that adds some indirection using action_ to configure the action for all jails at the same time. Note that this still requires the firewall to start before fail2ban (to create the hook chains). Alternatively, we could make the iptables actions create the chain if it does not exist yet (and if the firewall scripts show the same tolerance, nothing will break). I think this will even solve both problems and not require fail2ban to start after the firewall anymore (though fail2ban will not do anything until the firewall is also loaded). I've implemented this partly (only for iptables-multiport.conf) at [2], but it should be trivial to extend. Does this make sense? Matthijs [1]: https://sourceforge.net/tracker/?func=detailaid=2855908group_id=121032atid=689047 [2]: http://git.stderr.nl/gitweb?p=servers.git;a=commitdiff;h=2f8315532658e5ad1acea72b357a5dc4878a4a93;hp=a31720f9f2b8f7e92d5e265bbe728e2756a7b7f6 -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22.19-vs2.2.0.7-grsec2.1.11-vs2.2.0.7 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages fail2ban depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii python2.5.2-3An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt Versions of packages fail2ban recommends: ii iptables 1.4.2-6administration tools for packet fi ii whois 4.7.30 an intelligent whois client Versions of packages fail2ban suggests: ii bsd-mailx [mailx] 8.1.2-0.20071201cvs-3 A simple mail user agent pn python-gamin none(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545971: fail2ban: iptables-multiport is default action, but README.Debian says otherwise
Package: fail2ban Version: 0.8.3-2sid1 Severity: minor Hi, in README.Debian, I read: iptables-multiport action is not default banaction since multiport module might not be compiled for some hand compiled kernels. However, the default jail.conf says: banaction = iptables-multiport I guess README.Debian is out of date? Gr. Matthijs -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22.19-vs2.2.0.7-grsec2.1.11-vs2.2.0.7 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages fail2ban depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii python2.5.2-3An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt Versions of packages fail2ban recommends: ii iptables 1.4.2-6administration tools for packet fi ii whois 4.7.30 an intelligent whois client Versions of packages fail2ban suggests: ii bsd-mailx [mailx] 8.1.2-0.20071201cvs-3 A simple mail user agent pn python-gamin none(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544089: tftpd-hpa: Does not start when Ipv6 is not available
Package: tftpd-hpa
Version: 5.0-5
Severity: normal
Hi,
I've recently upgraded tftpd-hpa, which stopped working. In my
daemon.log, I see:
cannot open IPv6 socket, disable IPv6: Address family not supported
by protocol
Cannot set nonblock flag on socket: Bad file descriptor
suspecting that these are related, I had a look at the source. It turns
out that the code has support of continuing without ipv6 if the ipv6
fails but ipv4 is opened succesfully, but it even does some stuff with
the ipv6 socket, even when it failed to open, resulting in this error
and the daemon quitting.
In tftpd.c, around line 536, I see:
if (ai_fam != AF_INET) {
fd6 = socket(AF_INET6, SOCK_DGRAM, 0);
if (fd6 0) {
if (fd4 0) {
syslog(LOG_ERR, cannot open IPv6 socket: %m);
exit(EX_OSERR);
} else {
syslog(LOG_ERR,
cannot open IPv6 socket, disable IPv6: %m);
}
}
#ifndef __CYGWIN__
set_socket_nonblock(fd6, 1);
#endif
memset(bindaddr6, 0, sizeof bindaddr6);
bindaddr6.sin6_family = AF_INET6;
bindaddr6.sin6_port = htons(IPPORT_TFTP);
}
It would make sense to move the last four lines into an else of the second if
(fd6 0). Perhaps other changes are required as well, I did not test this.
The reason that the ipv6 socket fails to open is that I'm running a custom
kernel with ipv6 disabled, I expect this issue will not bite users that
run a stock Debian kernel, so I'm not giving this bug increased
severity.
Gr.
Matthijs
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.31-rc4 (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages tftpd-hpa depends on:
ii adduser 3.110 add and remove users and groups
ii debconf [debconf-2.0] 1.5.27 Debian configuration management sy
ii libc6 2.9-25 GNU C Library: Shared libraries
ii libwrap0 7.6.q-18 Wietse Venema's TCP wrappers libra
tftpd-hpa recommends no packages.
Versions of packages tftpd-hpa suggests:
pn syslinux-common none (no description available)
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi Manoj, I propose the following: Let kernel-package expose a KERNEL_PACKAGE_VERSION variable to /etc/kernel/postinst.d scripts. This allows the initramfs-tools script to generate an initrd if a) KERNEL_PACKAGE_VERSION = 12.001 Or if STEM is set. postinst scripts run by kernel-package image packages have for a long time exported STEM=linux in the environment. I'm not sure what STEM exactly means, but it sounds like the wrong way to detect kernel-package generated kernels to me. You might use it for backwards compatibility perhaps, but using KERNEL_PACKAGE_VERSION seems to me the only proper way (since it explicitly refers to kernel-package, while STEM=linux is just something that happens to be set by kernel-package, but could just as well be set for the official kernels in the future). Done in my local git repo. The next upload of kernel-package, 12.018, will export KERNEL_PACKAGE_VERSION (and also STEM, usually linux) into the environment. Nice. I hope so. In any case, kernel-package is getting behind this proposal. Good. Next up is fixing the initramfs-tools to apply the checks i proposed in my earlier post. Gr. Matthijs signature.asc Description: Digital signature
Bug#542467: [PATCH] Fix the parsing of gpg output.
Previously, the final entry (packet) in a key would be wrongly
attributed to the next key in the output, except for the final entry in
the keyring, which would be attributed correctly.
Since this happened consistently, the diff would not be influenced much
as long as the keys remained in the same order. However, when adding a
key, the final entry in the keyring changes, causing one bogus change to
appear in the diff output.
This commit slightly restructures the parsing function to push out a
previous packet before changing the current key id. It also adds a few
comments.
---
jetring-diff | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/jetring-diff b/jetring-diff
index 6a75e72..6f5b2f4 100755
--- a/jetring-diff
+++ b/jetring-diff
@@ -95,16 +95,24 @@ sub parse_keyring {
my @fields=split(:, $_);
$fields[5]=-; # ignore creation date, varies
next if $fields[0] eq 'tru';
- if ($fields[0] eq 'pub') {
- $id=$fields[4];
- }
if ($fields[0] ne 'sig' $fields[0] ne 'rev') {
+ # sig and rev fields tag along with the preceding
packet,
+ # any other fields need their own packet. If there is a
+ # previous packet, push it and create a new one.
if (defined($packet)) {
push @{$keys{$id}}, $packet;
undef $packet;
}
$packet-{'details'} = \...@fields;
+
+ # If this is the start of a new public key, save the id
for
+ # all the subsequent packets
+ if ($fields[0] eq 'pub') {
+ $id=$fields[4];
+ }
} else {
+ # This is a signature or revocation, it needs a key and
+ # packet to go with
if (! defined $id or !defined($packet)) {
die parse error: $_;
next;
@@ -112,6 +120,7 @@ sub parse_keyring {
push @{$packet-{'sigs'}}, \...@fields;
}
}
+ # Push any last packet still hanging around
push @{$keys{$id}}, $packet;
close DUMP;
--
1.6.3.3
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#533557: openttd: dies silently when data files are not installed
Hi Javier, I've finalized a plan for this bug. I intend to close it in the next upload, but with a minimal solution. I've created a very simple script that captures openttd's standard error stream and displays it using xmessage if openttd returns an error code. This is not as flexible, elegant and cool as your script, but is a bit more forward compatible. Also, this does not add the extra ssft dependency, but just a dependency on xutils, which everybody running X should already have AFAICT. Lastly, ssft might not be sufficient for what we want, since it might fall back to text or dialog outputs, which are really useless for this purpose. I will discuss improvement of standard error output with upstream, so that the error output of this script can be made a bit more friendly as well. After this, I intend to start splitting the openttd package. This will probably be for the second upload (e.g., 0.7.2-2 or perhaps 0.7.3), since it requires quite a bit of testing. When splitting, I intend to create an openttd-original-graphics-installer package or something like that, which is a placeholder package for the original TTD graphics. I intend to use (parts of) your script in this installer package to actually install the graphics. So, for now I will close this report with the next upload, but expect more improvements soon. Gr. Matthijs signature.asc Description: Digital signature
Bug#542467: jetring-diff incorrectly shows changes to the last key in a keyring
Package: jetring Version: 0.16 Severity: normal Tags: patch Hi, I noticed jetring-gen creating an superfluous modify-XXX file after I added my key to the debian-maintainers keyring, which contained an import for a key that was already in the keyring. Some investigation turned up that jetring-diff incorrectly shows a difference in the (previously) last key of a keyring, as you can see in the following example: matth...@xanthe:/tmp$ cp /usr/share/keyrings/debian-maintainers.gpg . matth...@xanthe:/tmp$ gpg --export matthijs key matth...@xanthe:/tmp$ gpg --no-default-keyring --keyring ./debian-maintainers.gpg --import key gpg: key 8A2FAFBC: public key Matthijs Kooijman matth...@stdin.nl imported gpg: Total number processed: 1 gpg: imported: 1 gpg: public key of ultimately trusted key E210F51B not found gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u matth...@xanthe:/tmp$ jetring-diff /usr/share/keyrings/debian-m debian-maintainers.gpg debian-multimedia-keyring.gpg debian-multimedia-removed-keys.gpg matth...@xanthe:/tmp$ jetring-diff /usr/share/keyrings/debian-maintainers.gpg ./debian-maintainers.gpg gpg: /tmp/jetring.FbLxEPmyx0/trustdb.gpg: trustdb created warning: cannot write cache /usr/share/keyrings/debian-maintainers.gpg.cache sub:-:1024:16:3B1AFDCBEA7C615D:-::e pub:-:4096:1:792152527B75921E:-:1275157534::-:::scESC uid:--::FBFCBA76BCE2FC950DA3FD7EF15A2A6E5B06DACF::Antoine Beaupré (work) anar...@koumbit.org uid:--::96A6CB81581D15D8C3A95CDD2275406F3B9725F4::Antoine Beaupré (home address) anar...@anarcat.ath.cx -sub:-:4096:1:A51D5B109C5A5581:-:1275158183:e +pub:-:1024:17:CF49D0E68A2FAFBC:-:::-:::scESC +uid:--::0A19F9509B3C127CA6E79A40F6BD5C2A92824463::Matthijs Kooijman matth...@stdin.nl +uid:--::688A23968448890ABCCB6D3ACC5814EC9A299F90::Matthijs Kooijman m.kooij...@student.utwente.nl +uid:--::E8D57A74FA062C14EE2CA43CD2719D2E86D7A2E6::Matthijs Kooijman - Brevidius matth...@brevidius.nl +uid:--::36AF6323DCDF9663986050F99A34674156F5A81F::Matthijs Kooijman - Inter-/Actief/ matthijs.kooij...@inter-actief.net +uid:--::E17DBBB8FC61EDAC78A54BC5AB86A6034209EFFF::Matthijs Kooijman - Inter-/Actief/ matthijs.kooij...@inter-actief.utwente.nl The -sub... line halfway the diff is incorrect, it would mean a part of Antoine's key would be removed (which really isn't the case). It turns out this is caused by a subtle bug in jetring-diff's parsing function. I've prepared a patch, which I will send as a reply to this message. Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc4 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages jetring depends on: ii gnupg 1.4.9-4GNU privacy guard - a free PGP rep jetring recommends no packages. jetring suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542473: debian-maintainers: Please add Matthijs Kooijman
Package: debian-maintainers Version: 1.64 Severity: normal Hi, I'd like to get added to the debian-maintainers keyring. Please find my jetring changeset attached. Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-rc4 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash debian-maintainers depends on no packages. Versions of packages debian-maintainers recommends: ii gnupg 1.4.9-4GNU privacy guard - a free PGP rep debian-maintainers suggests no packages. -- no debconf information Comment: Add Matthijs Kooijman matth...@stdin.nl as a Debian Maintainer Date: Wed, 19 Aug 2009 21:36:35 +0200 Recommended-By: Victor Julien vic...@inliniac.net Jordi Mallach jo...@debian.org Agreement: http://lists.debian.org/debian-newmaint/2009/07/msg00026.html Advocates: http://lists.debian.org/debian-newmaint/2009/07/msg00027.html http://lists.debian.org/debian-newmaint/2009/07/msg00028.html Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.9 (GNU/Linux) mQGiBEKWd+kRBACNgt1YOwPtI6i/vwfYXQBQbY/+/NL54KTedxbTVkicsTRQUHHt S809ekMUdMJQRDOvE5e+CrMfdsOtvEz92ZwDt04rC8Nm5L0rIaGzlVQSrehMY/mt B3F+A3rkWHcTXIYnynY48RcjylG9sZWrXnKPHbnyCh6G9HHNcCLqXSqJLwCg5fDr d856cnstuIO6L8oy7cjM5EcD/2dhF45Br7yYpwP4xG7OAfLt/hdjo0UAGtPEe9Iv 2pXQcyQEmzkZK4x7OpXMGeVDfIWje7n0PlXdN1Hv4F0aT/FgF3jna6+U6wd5Smqp Rwk1CW3yO8kZC8FO0eNeL/giieByZQRtk9HgE8NNZJ05EravPifY1lp+lu9S3uLN BF6zA/9N/nfgLP3QLQ4mfTik6h+QakzUqs3lhNKMbsYJzWoHtiUM3qZj1VlrZ5DA Nze/wq88k9nOvWcLK28dRUpX2hx/6tM2sccWM3wJttUUQuL56LV4IgI/UxqxeYN+ wXwumVvz4QzXiq9YN6FtyN7to38pE/YkFrkzQJ798O5AxY7d9LQlTWF0dGhpanMg S29vaWptYW4gPG1hdHRoaWpzQHN0ZGluLm5sPoh5BBMRAgA5AhsDBgsJCAcDAgQV AggDBBYCAwECHgECF4ACGQEFAkkANKwVGGhrcDovL3BncC5zdXJmbmV0Lm5sAAoJ EM9J0OaKL6+81/oAn0RE2OUxFjov3Rnz7mU6E+wQjnvsAJwN1P+q2LRgiIqsZMvs U7km05kv2YhGBBARAgAGBQJI29fvAAoJEGI+SeCHayUvulcAniHCFj7qe3J1zuJO gA+LI/iq6yHaAJ0Tw7t0bOqaHoA0d/2pykIEeRaY6ohGBBARAgAGBQJJWr2LAAoJ EDdLt0rxfXH9o+wAn0tx2sNZ82VZDtdgW/MPzni8dCpyAJ9Hev3OdkKdmmgKe0aI eoWn2MSOE4hGBBARAgAGBQJJfyjEAAoJEEfu1ZBB7sh88F4AnA3IhlEYGOxwe7ec FcvFu7Z+RYAlAJ44rvfednzCGMrePZCDuPdkig1FqIh9BBMRAgA9AhsDBgsJCAcD AgQVAggDBBYCAwECHgECF4ACGQEFAkjb4swZGGhrcDovL2tleXJpbmcuZGViaWFu Lm9yZwAKCRDPSdDmii+vvMStAKCgxbsjNokuuP44pXC+/FfGnOEd0QCgvqnNcD14 VdCjQvge+9zymRrnPre0MU1hdHRoaWpzIEtvb2lqbWFuIDxtLmtvb2lqbWFuQHN0 dWRlbnQudXR3ZW50ZS5ubD6IdAQTEQIANAIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX gAUCSQA0shUYaGtwOi8vcGdwLnN1cmZuZXQubmwACgkQz0nQ5oovr7yg9wCfblcn b65Wp/nXyHUvbjYP2I97RF0An29jjmJ7SIX+I05m9qXAr3WmlPG5iEYEExECAAYF AkUuKEMACgkQrv+jJWuJUzT8EQCfeSPZO6HNcw/PtsxnBYFTCv1K9/4An3QP1QBA i7z2zrv5rGXbshaqnJ2QiEYEEBECAAYFAkjb1/QACgkQYj5J4IdrJS/kvwCeIKUx 6ck9dOaUB5iDOIJR2As2qdIAn0KneJnbw2nQ6LpmpALJXuF1HW5HiEYEEBECAAYF Akl/KOgACgkQR+7VkEHuyHxWfgCfVVBbGkY2MKw20mfmS5bxlWXFOwEAn3oEi6uW 1qeu7u3/3lE8PjT2rJVliHgEExECADgCGwMGCwkIBwMCAxUCAwMWAgECHgECF4AF Akjb4tEZGGhrcDovL2tleXJpbmcuZGViaWFuLm9yZwAKCRDPSdDmii+vvOksAJ9u GhNsjYVsEYDlnMs2Q1EiMvz7DACfRKW7ptz/sFGVpSCPkHKmHXE7WYG0NU1hdHRo aWpzIEtvb2lqbWFuIC0gQnJldmlkaXVzIDxtYXR0aGlqc0BicmV2aWRpdXMubmw+ iHYEExECADYCGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAUCSQA0sxUYaGtwOi8v cGdwLnN1cmZuZXQubmwACgkQz0nQ5oovr7zMSQCfVXVB3s2n9N/tJkpQmtGbhq9u Or0AoM2Fzu9NY3x/4w2KvQ3GHuLc61U4iEYEEBECAAYFAkjb1/QACgkQYj5J4Idr JS8+wQCfWm60v1jZZIWZY+oNq9Sm+5H5j8AAn0t/j//TxgXzRit6Qya8FmPTboZ4 iEYEEBECAAYFAkl/KPIACgkQR+7VkEHuyHwIkQCfXLjqKxLbEpNVbEDECQmkEcCT V4gAnRKhrfeNrauLYAPR3fRkpvx0hYsoiHoEExECADoCGwMGCwkIBwMCBBUCCAME FgIDAQIeAQIXgAUCSNvi0RkYaGtwOi8va2V5cmluZy5kZWJpYW4ub3JnAAoJEM9J 0OaKL6+8g8oAnjt1erbYnGPqwVvYmoQsKLSImkpuAJ9UVfmi4e+mO7uQ4ctal+pe qGr2urRHTWF0dGhpanMgS29vaWptYW4gLSBJbnRlci0vQWN0aWVmLyA8bWF0dGhp anMua29vaWptYW5AaW50ZXItYWN0aWVmLm5ldD6IdgQTEQIANgIbAwYLCQgHAwIE FQIIAwQWAgMBAh4BAheABQJJADS0FRhoa3A6Ly9wZ3Auc3VyZm5ldC5ubAAKCRDP SdDmii+vvNXTAKCgJbHMGc1WVhqbrljRoefo/o+ssACg4HDLyFUfebte5n1xVmNi bKcxMNKIRgQQEQIABgUCSNvX9AAKCRBiPkngh2slL71EAJ9onbnoWUZJRkW6C1K+ M8rp5vECegCdHr+2ufJqicpzseUzsEeIauqN3AiIRgQQEQIABgUCSVq9qgAKCRA3 S7dK8X1x/ZamAKCEoioK0DTX9XiPX2Vrrrk9a+ReWwCgiI94zfsW0+REy3YI5Z4Z hcFtAUiIRgQQEQIABgUCSX8o9QAKCRBH7tWQQe7IfKLZAJ954ev7z2VIqdxzn9+g 1LzjgPn6oQCgiFFRsbV84m+uDf9MTo5rq+yAvnyIegQTEQIAOgIbAwYLCQgHAwIE FQIIAwQWAgMBAh4BAheABQJI2+LSGRhoa3A6Ly9rZXlyaW5nLmRlYmlhbi5vcmcA CgkQz0nQ5oovr7yaIACguBt59K674CBuj9r+PhsBFOWnvDIAmwTyx64CwWFyd6wO q/C1VWDiO/TjtE5NYXR0aGlqcyBLb29pam1hbiAtIEludGVyLS9BY3RpZWYvIDxt YXR0aGlqcy5rb29pam1hbkBpbnRlci1hY3RpZWYudXR3ZW50ZS5ubD6IdgQTEQIA NgIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheABQJJADS1FRhoa3A6Ly9wZ3Auc3Vy Zm5ldC5ubAAKCRDPSdDmii+vvGuhAKDdQ0FzeNeN3Xu93L+qSzWgCgGJGACeP5p4 YYefG7XIb0u3eYMq2wzuV+6IRgQQEQIABgUCSNvX9AAKCRBiPkngh2slL+CGAJ0d ndGVuokkO6o/r8+0NOU+4RckaQCfb8DE5UgBmoFOXmCY0IPrP72u4c6IRgQQEQIA
Bug#539381: openttd: Does not specify why it is in contrib
Package: openttd Version: 0.7.1-1 Severity: minor Hi, the openttd package is in the contrib section, and according to the Policy this should be motivated in the copyright file: ‘Packages in the contrib or non-free archive areas should state in the copyright file that the package is not part of the Debian GNU/Linux distribution and briefly explain why.’ Openttd does not yet do this. Gr. Matthijs -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openttd depends on: ii debconf [debconf-2.0] 1.5.26Debian configuration management sy ii libc6 2.9-10GNU C Library: Shared libraries ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-4.1 FreeType 2 font engine, shared lib ii libgcc11:4.4.0-3 GCC support library ii libpng12-0 1.2.35-1 PNG library - runtime ii libsdl1.2debian1.2.13-4+b1 Simple DirectMedia Layer ii libstdc++6 4.4.0-3 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime openttd recommends no packages. Versions of packages openttd suggests: pn freepats none (no description available) pn timidity none (no description available) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi Manoj, The second argument, which is the location of the kernel image (which need not be in /boot, you know) is used by the scripts shipped with kernel-package to create features that would not be otherwise possible -- unless we also remove from kernel-package the ability to install the image in locations other than /boot. Ah, that makes sense. I guess that the official kernels don't need this parameter because they always install into /boot? One solution is to have the user deploy scripts into /etc/kernel that meets their needs, but this seems to be somewhat tedious for end users. Yup, that's not really a long-term solution IMHO. A solution might be to create packages that just contain conffiles in /etc/kernel/, and who provide the virtual package kpkg-image-conf, and have all kernel-package image packages Recommend the virtual package. This way, the user will not be impacted by the inability of the initramfs-tools package's conffile to cater to the other flavours of kernel image packages. This sounds rather like a lot of infrastructure for something simple. Also, how would this work with official kernel images? Would this new configfile apply the same second-argument test to only work with kernel-package generated kernels? In that case, we will be stuck forever with two complementary scripts (that essentially do the same) using some ugly hack based om parameter counts to not conflict with each other. Also, in this situation it would be impossible to remove the hack from either script later on. It seems to make more sense to remove the hack from the initramfs-tools script eventually, when the new version of kernel-package has been around for a while. However, until then, we need some other way of making things work, that will transition smoothly into a initramfs-tools script that works for all kernels. I propose the following: Let kernel-package expose a KERNEL_PACKAGE_VERSION variable to /etc/kernel/postinst.d scripts. This allows the initramfs-tools script to generate an initrd if a) KERNEL_PACKAGE_VERSION = 12.001 b) KERNEL_PACKAGE_VERSION is not set and there is only a single argument is passed (e.g., for official kernels). This will make initramfs-tools, kernel-package and official kernels play together for both new and old versions. The only gap here is kernel-package 12.001 until the current version, which won't work out of the box (but we won't be able to fix those anyway). This approach also allows the initramfs-tools to remove the above checks eventually, when older versions of kernel-package can be considered to be no longer in use. Also, letting kernel-package pass its version to scripts might have other uses as well. It will allow scripts to change their behaviour based on kernel-package version in an elegant way. Even if we were to add kpkg-image-conf like packages later on, these could use the version number as well (because just using Depends: to get the right version won't work, since we might install kernel images built with different versions of kernel-package). Would this work? Gr. Matthijs signature.asc Description: Digital signature
Bug#523735: /etc/kernel/postinst.d/initramfs-tools: please consider supporting the experimental kernel-package out of the box
Hi all, I've CC'd Manoj on this, since I am proposing a change in kernel-package to solve this bug. [Summary: Kernel package stopped running update-initramfs, but the initramfs-tools postinst hook specifically doesn't run for kernel-package built kernels] 7c7,10 [ -z $2 ] || exit 0 --- [ -z $2 ] || echo warning: not running update-initramfs, see make-kpkg(1) and /usr/share/doc/kernel-package/README.gz for details exit 0 please use unifiedd diffs, aboves is unreadable. Actually, I think the above is quit readable, if you look at the /etc/kernel/postinst.d/initramfs-tools script. Some extra context would have been useful, though. also aboves is wrong as it would also be called by *official* linux-2.6 produced images. I don't think this is true, since the comment in the script says: # kernel-package passes an extra arg; hack to not run under kernel-package [ -z $2 ] || exit 0 So it seems that this line should really only apply to kernel-package generated kernels (official kernels are no longer generated by kernel-package, according to /usr/share/doc/kernel-package/NEWS.Debian.gz). However, just adding a warning line really won't solve anything. It seems the problem is that the initramfs hook script ignores kernel-package (which it should for older versions), which it shouldn't do for the latest version of kernel-package. However, the script really has no way to tell that the kernel currently installing was built by kernel-package = 12.001. Apparently it can only tell that it was called by kernel-package due to a second argument, which official kernels presumably don't pass? If this is so, what use is the argument anyway, if it's not always passed in? From a kernel-package kernel's postinst script: run-parts --verbose --exit-on-error --arg=$version --arg=$realimageloc$kimage-$version /etc/kernel/postinst.d so it seems it passes some location and version as a second argument, but I can't really tell what. I don't know if the interface for scripts in /etc/kernel/postinst.d is documented anywhere? One obvious solution here, would be to let kernel-package no longer pass in the second argument. This makes it compliant with official kernels, the initramfs-tools can no longer distinguish them, and all should be well. Perhaps Manoj can comment on this? Gr. Matthijs signature.asc Description: Digital signature
Bug#533557: openttd: dies silently when data files are not installed
Hi Javier, I propose the attached patch, a shell script that would replace openttd as the command to be executed by the OpenTTD menu item. Cool, thanks. I already saw the Ubuntu bug report [1], but didn't have time to reply yet. I like the idea. I don't use the Debian menus myself, I start my programs from a console mostly, where you do get a decent error message. I hadn't before realized that this doesn't happen when you start from the menu. So, I agree that this is something we must fix in some way. However, I'm not 100% sure if this approach is the best one to take. An alternative approach would be to introduce an extra package openttd-original-graphics, which would do something like your script at install time, and make openttd depend on that. This is probably not very differen right now, but makes the transition to the use of free graphics a lot easier later on. Currently there is ongoing work on the OpenGFX package, which is aimed to be a replacement for the original OpenTTD graphics. With the separate package approach, we could make openttd then depend on openttd-opengfx | openttd-original-graphics or something like that. Any thoughts on this? As for the patch you created, it looks good. It has some decently named functions, decent comments and is translatable. Gr. Matthijs [1]: https://bugs.launchpad.net/ubuntu/+source/openttd/+bug/388402 signature.asc Description: Digital signature
Bug#524651: openttd: don't inform about data files on every upgrade
Hi Bernd, I've installed openttd for a longer time now, and I always found it pretty annoying that debconf told me every time that I need ttd data files to play openttd. Please save that the message was shown using debconf and don't show it again on upgrades. I'll try to incorporate this check, but since I'm not completely convinced of the neccessity of this change, it's not high on my todo list. If you have openttd installed, you'll want to have the data files as well, since openttd won't work without any and you might as well just uninstall it. Or is there a usecase for having openttd installed without datafiles that I am not aware of? Gr. Matthijs signature.asc Description: Digital signature
Bug#529570: context: Context MkIV does not work with current luatex version
Package: context Version: 2008.05.21-1 Severity: normal Hi, even though MkIV is strictly not supported and this might not be a context bug per se, I would like to at least document this behaviour here. Since I've upgraded luatex from 0.35 to 0.40, Context MkIV no longer works for me. When I run luatools --ini --compile cont-en to recompile the context files (since just running context complains about out-of-date cache), I get the following messages, in between some other output: LuaTools | running command: luatex --ini --lua=cont-en.luc /usr/share/texmf/tex/context/base/cont-en.tex \\dump (/usr/share/texmf/tex/context/base/cont-en.tex (/usr/share/texmf/tex/context/base/context.tex SORRY CONTEXT NOW NEEDS ETEX) ) Since the complaint about out-of-date doesn't disappear, I assume the above messages is actually a fatal error of sorts. This issue is also discussed at [1], where it is suggested to upgrade context to the latest beta. Perhaps for now, context should conflict with luatex = 0.38, so people won't accidentally upgrade it until this issue is resolved? I also tried upgrading to 2008.10.31-1 from experimental, but that didn't help. Gr. Matthijs [1]: http://www.ntg.nl/pipermail/ntg-context/2009/040339.html -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages context depends on: ii lmodern1.010x-5 scalable PostScript and OpenType f ii ruby 4.2 An interpreter of object-oriented ii tex-common 1.18 common infrastructure for building ii texlive-base 2007.dfsg.2-4 TeX Live: Essential programs and f ii texlive-base-bin 2007.dfsg.2-6 TeX Live: Essential binaries ii texlive-metapost 2007.dfsg.2-6 TeX Live: MetaPost (and Metafont) Versions of packages context recommends: ii luatex0.40.0-1 next generation TeX engine Versions of packages context suggests: pn context-doc-nonfree none (no description available) pn context-nonfree none (no description available) pn fontforgenone (no description available) ii libxml-parser-perl 2.36-1.1+b1 Perl module for parsing XML files pn perl-tk none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529570: context: Context MkIV does not work with current luatex version
Hi Norbert, Since I've upgraded luatex from 0.35 to 0.40, Context MkIV no longer works for me. When I run I've just also upgraded context to the latest beta, which fixes things. I wanted to find just the change needed to fix things, but I couldn't find any form of version control at upstream context, so I just settled for trying the latest beta. For anyone else wanting to try this, the following series of commands will give you a working .deb with the latest context beta. No guarantees, the deb is probably still broken in some subtle ways (just downgrading the lmodern dependency is bound to have some side effects...). # Get the debian packaging files svn co svn://svn.debian.org/svn/debian-tex/context/trunk context-debian cd context-debian # Get the context files rsync -rvzctlp rsync://contextgarden.net/minimals/current/context/beta/ . # Add a changelog entry dch -v 2009.05.20.beta-1 Local beta build # Downgrade the lmodern dependency, since lmodern 1.106 is not yet in Debian sed -i s/1.106/1.01/ debian/control # Allow convert-fonts-to-link to fail for some fonts that no longer exist sed -i s/rm/rm -f/ debian/convert-fonts-to-link # Remove some non-free fonts (debian/rules complains about them) rm `cat debian/MANIFEST.nonfree ` # Build the package dpkg-buildpackage -uc -us -b Ah yes, thanks for reminding me. I will try to fix that. The problem is that the new luatex binaries do not export the etex/pdftex extensions by default. That sounds like you just need some command line option? Or perhaps some change from newer context can be backported? Gr. Matthijs signature.asc Description: Digital signature
Bug#527060: logrotate: Automatically create olddir
Package: logrotate Version: 3.7.1-5 Severity: wishlist Hi, I guess this is more of a wish for upstream, but since I haven't been able to locate any bug tracker or even website for upstream, I'll report here. Currently, logrotate supports the olddir options, for moving rotated logfiles to a separate directory. Logrotate insists that this directory to rotate to exists when checking the configuration file. If the dir does not exist, it errors out with an error like: error: rsyslog-central:23 error verifying olddir path /data/log/rsyslog/log/apps/archive: No such file or directory I would suggest for logrotate to automatically create this directory if it does not exist yet (probably configurable with a createolddir option or something similar). This automatic creation is needed to support my dynamic logging environment: I have syslog files for different hosts, each of which have their own olddirs. Since directories for new hosts can be created at any time, I can't statically create the olddirs, so autocreation of these dirs would be needed (though I just realized that a script like for i in /foo/*; do mkdir -p $i/archive; done would also do the trick, though it is slightly less elegant...) Gr. Matthijs -- Package-specific info: Contents of /etc/logrotate.d total 20 -rw-r--r-- 1 root root 84 2008-06-08 14:28 apt -rw-r--r-- 1 root root 79 2008-07-04 18:56 aptitude -rw-r--r-- 1 root root 111 2008-06-18 10:11 dpkg -rw-r--r-- 1 root root 330 2009-05-05 10:17 rsyslog -rw-r--r-- 1 root root 836 2009-05-05 13:27 rsyslog-central -- System Information: Debian Release: 5.0.1 APT prefers stable APT policy: (990, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22.19-vs2.2.0.7-grsec2.1.11-vs2.2.0.7 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages logrotate depends on: ii base-passwd 3.5.20 Debian base system master password ii cron 3.0pl1-105 management of regular background p ii libc6 2.7-18 GNU C Library: Shared libraries ii libpopt0 1.14-4 lib for parsing cmdline parameters ii libselinux1 2.0.65-5 SELinux shared libraries Versions of packages logrotate recommends: ii bsd-mailx [mailx] 8.1.2-0.20071201cvs-3 A simple mail user agent logrotate suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527060: logrotate: Automatically create olddir
though I just realized that a script like for i in /foo/*; do mkdir -p $i/archive; done would also do the trick, though it is slightly less elegant... Scratch that... logrotate verifies the olddir directly after reading a config entry, so long before any scripts are run... Gr. Matthijs signature.asc Description: Digital signature
Bug#527060: logrotate: Automatically create olddir
Hi Paul,
Surely when you're creating the conffile fragment for logrotate to use, you
can also make the corresponding olddir directory?
Nope, since I use wildcards:
/data/log/rsyslog/*/*/*.log
{
...
olddir archive
}
Here, the dir structure is like:
/data/log/rsyslog/mail/facilities/auth.log
/data/log/rsyslog/mail/facilities/cron.log
/data/log/rsyslog/dns/facilities/auth.log
etc, where mail and dns are hostnames.
I can't use a single olddir here (ie, an absolute path) either, since then I
expect the identical filenames to create problems...
I hope this clarifies my situation a bit!
Gr.
Matthijs
signature.asc
Description: Digital signature
Bug#527060: logrotate: Automatically create olddir
Hi Paul, My suggestion would be that the directory is automatically created only when the olddir is specified as a directory within the log file's directory (ie. no slashes), and that it should inherit the ownership and permissions of its parent directory. That sounds pretty reasonable. Gr. Matthijs signature.asc Description: Digital signature
Bug#499076: Any progress?
Hi Nathan, any progress on this issue? Any news from upstream, or should the patch perhaps be backported to Debian? Gr. Matthijs signature.asc Description: Digital signature
Bug#524349: kernel-package: Fails to clean for kernel = 2.6.22, due to missing lguest
Package: kernel-package Version: 12.009 Severity: normal Hi, the current kernel-package version fails to clean for kernel 2.6.22 and before. kernel-package breaks on the absence of the Documentation/lguest directory. The file /usr/share/kernel-package/ruleset/targets/common.mk contains: $(MAKE) $(FLAV_ARG) $(EXTRAV_ARG) $(CROSS_ARG) ARCH=$(KERNEL_ARCH) -C Documentation/lguest clean which unconditionally tries to clean the Documentation/lguest directory. Removing this line fixes the problem for me. I would suggest adding a simple check (like image.mk has): test ! -d Documentation/lguest || $(MAKE) ... (On a related note, who actually thought it was a good idea to put up C source files in the Documentation directory in the first place? :-S) Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kernel-package depends on: ii binutils 2.18-1 The GNU assembler, linker and bina ii build-essential 11.3informational list of build-essent ii debianutils 3.0.1 Miscellaneous utilities specific t ii file 4.21-3 Determines file type using magic ii gettext 0.16.1-2GNU Internationalization utilities ii make 3.81-3 The GNU version of the make util ii module-init-tools3.3-pre11-4 tools for managing Linux kernel mo ii po-debconf 1.0.9 manage translated Debconf template ii util-linux 2.13-8 Miscellaneous system utilities kernel-package recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512441: [INTL: gl] openttd debconf template translation
Hi Marce, Please, find enclosed a file containing an _update_ to the translation to Galician language of debconf template. I was about to include your patch, but it seems you forgot to attach it. Do you still have it lying around? Gr. Matthijs signature.asc Description: Digital signature
Bug#511560: hobbit: New version 4.2.2 available upstream
Package: hobbit Severity: wishlist Hi, upstream, version 4.2.2 has been released on 2008.12.16. Upstream also renamed the project to xymon, for legal reasons. What's the prospect of seeing this new version in Debian? Gr. Matthijs -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505270: [Splashy-devel] Bug#505270: my patch (a fast way to deal with this bug)
Hi Time,
As indicated already, please consider this patch for the next version of
splashy. It replaces the sleep in the script, and only holds up init for
the time necessary (certainly less than 0.5 s and perhaps only 0.1 s)
(attached)
Turns out the patch was easier than I expected :-)
+/* register signal handlers if we are doing splashy boot */
+ if (g_ascii_strncasecmp (argv[1], boot, 4) == 0) {
+ (void) signal (SIGCHLD, sig_exit_boot); /* this signal is
sent when a child process exits */
+ (void) signal (SIGUSR2, sig_exit_boot); /* this is the
signal sent by _splashy_child indicating directfb is fully initialised */
+
/* so the parent process can exit, letting init continue. We lock
initramfs from */
+
/* being unmounted while the child process is still setting up
directfb. */
+
/* some machines had a race condition causing splashy failure */
+
/* This fixes bug 505270 */
+}
+
You're messing up the indentation here, presumably because your not mixing
tabs and spaces properly (though I don't see any real tabs in the patch..)
@@ -141,6 +177,8 @@
{
DEBUG_PRINT (Calling splashy_child_start());
splashy_child_start ();
+
+
}
else if (g_ascii_strncasecmp (argv[1], shutdown, 8) == 0)
{
This is a pretty useless hunk :-)
+/* Wait 1s for signal. There are two possible signals. */
+/* The child may die (splashy failed), or the child process
signals that directfb is setup. */
+ /* If the exit signal does not come in this time, then exit
anyway */
+/* the signal should come very quickly, so this approach
saves most of a second */
+
+g_usleep(100); /* 1s */
+g_printerr (%s, Error occured : splashy boot
terminated; timed out waiting for splashy to initialise\n);
+ }
Perhaps it would be good to increase this sleep interval? On normal operation,
the time isn't reached anyway, and on slow computers / boot media it could
perhaps take long time. It would be annoying if this bug would be reintroduced
just because a particular machine or boot takes a bit longer. How about making
it 10s?
Also, I would write this as:
g_usleep(10*1000*1000)
It's a bit clearer IMHO.
Gr.
Matthijs
signature.asc
Description: Digital signature
Bug#505270: [Splashy-devel] Bug#505270: Delay
Hi Tim, I think a delay of 1 second is probably five times too long even in worst cases, but if I didn't make mistakes in the code, it won't matter because a signal will arrive quickly. Exactly, so it wouldn't hurt to increase it. Slower machines don't necessarily make the race condition more likely to occur. Well, if the directFB initialization takes longer, the race condition is more likely to occur AFAICS. It would be a lot longer, though. The window of error is only the execution of a few lines of code. This bug was triggered simply by moving from inittop to premount. Milliseconds of difference. But even with the previous code, the race condition could have occured. The point I'm making is why take the (probably very small) chance that this bug shows up again on systems that might be different from what we are testing on now. But let's just leave this to Luis :-) Gr. Matthijs signature.asc Description: Digital signature
Bug#505530: Fixed in upstream
Hi, it seems this bug is fixed in upstream. From the GnuCash 2.2.8 changelog: # Fix account defaulting for posting vendor bill Gr. Matthijs signature.asc Description: Digital signature
Bug#509025: splashy: Fixed upstream
Package: splashy Version: 0.3.12-1 Followup-For: Bug #509025 I also ran into this problem (also when upgrading mysql) and took a peek at upstream sources. From the git log, this was fixed upstream in rev dccdf4532edc4edd135bb89d16cd24904dbc8af9 already (which means the recently released 0.3.13 version has this fixed). Gr. Matthijs -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages splashy depends on: ii initramfs-tools0.92n tools for generating an initramfs ii libc6 2.7-16GNU C Library: Shared libraries ii libdirectfb-1.0-0 1.0.1-11 direct frame buffer graphics - sha ii libgcc11:4.3.2-1 GCC support library ii libglib2.0-0 2.16.6-1 The GLib library of C routines ii libmagic1 4.26-2File type determination library us ii libsplashy10.3.12-1 Library to draw splash screen on b ii lsb-base 3.2-20Linux Standard Base 3.2 init scrip ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime splashy recommends no packages. Versions of packages splashy suggests: ii console-common0.7.80 basic infrastructure for text cons ii splashy-themes0.4.1 A complete user-space boot splash pn upstart none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503757: vim-runtime: 7.2.049-2 is still failing
Package: vim-runtime Version: 1:7.2.049-2 Followup-For: Bug #503757 Hi, I'm still seeing this problem when upgrading to 7.2.049-2, from 1:7.1.314-3 (I'll call these new and old respectively further on). I'm not so sure how these diversions really work, though I'll try to provide some more info. The exact error I'm seeing is: Preparing to replace vim-runtime 1:7.1.314-3 (using .../vim-runtime_2%3a7.2.049-2_all.deb) ... Leaving `diversion of /usr/share/vim/vim72/doc/help.txt to /usr/share/vim/vim72/doc/help.txt.vim-tiny by vim-runtime' Leaving `diversion of /usr/share/vim/vim72/doc/tags to /usr/share/vim/vim72/doc/tags.vim-tiny by vim-runtime' Removing `diversion of /usr/share/vim/vim71/doc/help.txt to /usr/share/vim/vim71/doc/help.txt.vim-tiny by vim-runtime' dpkg-divert: rename involves overwriting `/usr/share/vim/vim71/doc/help.txt' with different file `/usr/share/vim/vim71/doc/help.txt.vim-tiny', not allowed It's interesting to note that (probably due to the conflicts: vim-tiny that was added) vim-tiny was already (and succesfully) upgraded, but vim-runtime fails after that. It seems that diversions are in place for both vim71 and vim72: matth...@xanthe:~$ sudo dpkg-divert --list *vim* diversion of /usr/share/vim/vim71/doc/help.txt to /usr/share/vim/vim71/doc/help.txt.vim-tiny by vim-runtime diversion of /usr/share/vim/vim71/doc/tags to /usr/share/vim/vim71/doc/tags.vim-tiny by vim-runtime diversion of /usr/share/vim/vim72/doc/help.txt to /usr/share/vim/vim72/doc/help.txt.vim-tiny by vim-runtime diversion of /usr/share/vim/vim72/doc/tags to /usr/share/vim/vim72/doc/tags.vim-tiny by vim-runtime I suspect that the vim72 diversions are added by the previous failed upgrade attempt, from looking at the new preinst script. I also suspect that the two Leaving diversion... messages in the output above are the attempts to add those diversions again, so it seems these don't pose any problem. The new preinst script also tries to remove any old diversions that are still in place, and this is where things are failing. Manually executing the remove command confirms that this is indeed the problem: matth...@xanthe:~$ sudo dpkg-divert --package vim-runtime --rename --remove /usr/share/vim/vim71/doc/help.txt Removing `diversion of /usr/share/vim/vim71/doc/help.txt to /usr/share/vim/vim71/doc/help.txt.vim-tiny by vim-runtime' dpkg-divert: rename involves overwriting `/usr/share/vim/vim71/doc/help.txt' with different file `/usr/share/vim/vim71/doc/help.txt.vim-tiny', not allowed This does make sense, since the old vim-runtime is still installed (so /usr/share/vim/vim71/doc/help.txt is present), while there is also still a /usr/share/vim/vim71/doc/help.txt.vim-tiny. AFAICS, the latter should have been removed when vim-tiny was upgraded (I assume that diversions work for removal of files as well as for installs?). I'm not so sure why that didn't happen, though I'm not so sure if removing that file is the proper way to handle this. AFAICU, the diversion should not be removed until after the file is removed by vim-runtime (ie, in the postinst upgrade and postrm scripts, I think?). This would also allow vim-runtime to be upgraded when vim-tiny is still installed, and properly restore /usr/share/vim/vim71/doc/help.txt to the vim-tiny version. I did a quick implementation of this scheme (removing the old diversions in postinst configure, see attachment), which solved my upgrading problems. This still leaves the vim-tiny versions of help.txt and tags littering /usr/share/vim/vim71/, but that makes sense, since the cause of the problem seems to be that the vim-tiny files didn't get removed properly. In other words, removing the diversions later makes the vim-runtime package a lot more robust. Removing any .vim-tiny versions that make dpkg-divert --remove fail doesn't seem to be the right approach here. Note that I don't remove the check_diversion function from preinst in my patch (I don't fully know what it does or why it exists either), but following the above reasoning I think it might be a bad approach as well. I haven't tried reproducing this on a clean environment yet (due to lack of time), but I'm happy to provide more information if needed. Gr. Matthijs -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27-rc2-wl-35635-gf8895ad (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash vim-runtime depends on no packages. Versions of packages vim-runtime recommends: ii vim-tiny 2:7.2.049-2 Vi IMproved - enhanced vi editor - vim-runtime suggests no packages. -- no debconf information diff -ur DEBIAN.orig/postinst DEBIAN/postinst --- DEBIAN.orig/postinst 2008-11-30 19:28:30.0
Bug#333156: acl: X permission in recursive mode makes files executable
Hi Laurent, it seems this problem was fixed upstream? I can't reproduce it using acl 2.2.47-2 (from testing). Could you check if this problem still exists for you? Gr. Matthijs signature.asc Description: Digital signature
Bug#499076: Fixed in CVS
Hi, it seems this problem was introduced in 2.2.46, during the tree_walk rewrite in the acl tools. Upstream has a report for this as well [1]. According to CVS logs [2], this bugs was fixed in upstream CVS two months ago. However, I do not think another release has happened since then. I'm not sure about upstream's release plans in this area, but if no release happens soon, perhaps Debian should include the patch [3] separately? Since the bug also applies to setfacl, not just getfacl, I would also consider this bug to be more severe than normal, probably even a release-critical regression (due to the security implications of unexpected acl changes). Gr. Matthijs [1]: http://oss.sgi.com/bugzilla/show_bug.cgi?id=790 [2]: http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/walk_tree.c [3]: http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/walk_tree.c.diff?r1=1.2;r2=1.3 signature.asc Description: Digital signature
Bug#500707: Does not run as the maradns user/group
Package: maradns Version: 1.3.07.08-1 Severity: important Tags: security Hi, I noticed that maradns does not properly update it's configuration to run as the user maradns. This results in the default configuration remaining active, which is running as uid 65534 and gid 99. The former should be the user nobody on all Debian systems AFAIK, but I think the latter is usually not a valid user. Running maradns with these credentials consitutes a security problem, however, I do not think this is directly exploitable. Hence, I'm marking this as important. There is code in the postinst script to take care of this. The code is supposed to change the uid/gid config directives to the uid and gid of the maradns user and group, also created by the postinst script. However, this only happens when postinst is called with the install argument, which never happens according to the Policy Manual [1]. The install argument is only passed to the preinst script, AFAICS. I can reproduce this problem on two seperate systems, one running sid and one running lenny. I hope a fixed version can still be included in lenny. Gr. Matthijs [1]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.27-rc2-wl-35635-gf8895ad (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages maradns depends on: ii adduser 3.110 add and remove users and groups ii libc6 2.7-13 GNU C Library: Shared libraries maradns recommends no packages. maradns suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497313: [Splashy-devel] Bug#497313: splashy: deb hooks don't rebuild initramfs for all installed kernels
When I purged and removed the splashy package because it crashes during resume from hibernation, I was running the stock kernel. However, the post-rm script only rebuilt initramfs for my custom kernel. So now I have to rebuild initramfs for the stock kernel myself. I was going to write that this was an update-initramfs problem, but I just found in the manpage that one can call update-initramfs -u -k all to update initramfs for all kernel versions. I guess splashy should do this? Gr. Matthijs signature.asc Description: Digital signature
Bug#497313: [Splashy-devel] Bug#497313: splashy: deb hooks don't rebuild initramfs for all installed kernels
Hrmm, but what if some of the kernels cannot support splashy or do not have the vesa f.b. compiled? What are the kernel conditions or versions that splashy requires, and if those conditions are not satisfied by a particular kernel, will it cause boot failure under that one? Nope, AFAIK the splashy scripts will check to see if framebuffer is setup properly and bail out otherwise. In the worst case, splashy will fail to start with an error, so it should be pretty failsafe AFAICS. Gr. Matthijs signature.asc Description: Digital signature
Bug#496621: [Splashy-devel] Bug#496621: The screenshot
Hi Marek, I attached the screenshot where one can see the black stripes that are at the top of my display. The image seems to be only 36 pixels high? Gr. Matthijs signature.asc Description: Digital signature
Bug#496621: [Splashy-devel] Bug#496621: The screenshot
Hi Marek, In case you overlooked them: At the far left there are 3 stripes, then another three between the Iceweasel and the Claws-Mail icons, then three in the middle, another three to the right and finally four at the far right. Ah, I had indeed overlooked those, I was expecting screen-wide stripes. What do you do exactly to get this effect? Is it after a normal boot, after dehibernate, etc. Does it happen if you switch to a console, run 'splashy test' and then switch back to X11 (with or without quitting splashy first)? Also, could you provide some more details about your graphics hardware and framebuffer setup? Output of lspci -v, cat /proc/fb and cat /proc/cmdline would be a start, I think. If you have any other machines running the same or different hardware, can you reproduce the issue there? Gr. Matthijs signature.asc Description: Digital signature
Bug#423721: kernel-package: -dirty is not always set correctly
I've been looking a bit more into this stuff and found that -dirty is not always correcty set. This issue is fixed in upstream kernels, scripts/setlocalversion now ignores the scripts/package/Makefile and scripts/package/builddeb files when determining -dirty. This is a nice way to fix this, since now unmodified kernels won't always get -dirty. This was fixed in commit b052ce4c840e2da3c72ab7dadb97d1094f6e3a89, which seems to be first included in 2.6.25. Note that this does not fix the actual topic of this bugreport, just this small sidetrack (which seemed related when I reported it, but should really have been a seperate bug in hindsight). Gr. Matthijs signature.asc Description: Digital signature
Bug#423721: GIT_VERSION contains (duplicate) localversion?
Obviously I forget to attach the patch... diff -ur ruleset.orig/misc/version_vars.mk ruleset/misc/version_vars.mk --- ruleset.orig/misc/version_vars.mk 2008-08-18 10:04:38.0 +0200 +++ ruleset/misc/version_vars.mk 2008-08-18 10:05:10.0 +0200 @@ -95,12 +95,6 @@ ifneq (,$(strip $(HAVE_BAD_VERSION))) $(error Error: $(VERSION)) endif - ifneq ($(strip $(CONFIG_LOCALVERSION_AUTO)),) -GIT_VERSION=$(shell /bin/sh scripts/setlocalversion) -ifneq ($(strip $(GIT_VERSION)),) - GIT_VERSION:=$(GIT_VERSION)-dirty -endif - endif else ifeq ($(DEB_HOST_ARCH_OS), kfreebsd) VERSION=$(call doit,grep '^REVISION=' conf/newvers.sh | \ @@ -152,7 +146,7 @@ else echo ; \ fi) -version = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(iatv)$(LOCALVERSION)$(GIT_VERSION) +version = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(iatv)$(LOCALVERSION) # Bug out if the version number id not all lowercase lc_version = $(call doit,echo $(version) | tr A-Z a-z) @@ -163,7 +157,6 @@ VERSION=[$(VERSION)], PATCHLEVEL=[$(PATCHLEVEL)], \ SUBLEVEL=[$(SUBLEVEL)], EXTRAVERSION=[$(EXTRAVERSION)],\ iatv=[$(iatv)], LOCALVERSION=[$(LOCALVERSION)],\ - GIT_VERSION=[$(GIT_VERSION)] \ UTS_RELEASE_VERSION=[$(UTS_RELEASE_VERSION)], \ KERNELRELEASE=[$(KERNELRELEASE)]. \ is not all lowercase. Since the version ends up in the package \
Bug#423721: GIT_VERSION contains (duplicate) localversion?
I'm not really sure what these variables actually mean and are supposed to hold, but I find the initalization of GIT_VERSION a bit weird at debian/ruleset/misc/version_vars.mk:98 ifneq ($(strip $(CONFIG_LOCALVERSION_AUTO)),) GIT_VERSION=$(shell /bin/sh scripts/setlocalversion) ifneq ($(strip $(GIT_VERSION)),) GIT_VERSION:=$(GIT_VERSION)-dirty endif endif It would appear to me that 'setlocaversion' is supposed to set LOCALVERSION, not GIT_VERSION ? Seemingly it does, since GIT_VERSION contains LOCALVERSION with -dirty appended, as you would expect from this code. The main problem here is that the kernel itself (in utsrelease.h IIRC) thinks it's just 2.6.22-rc4-g4d33a504-dirty, without that GIT_VERSION crap. Halfway into the build process, this generates a version mismatch error. I have tried reenabling CONFIG_LOCALVERSION_AUTO once more, and found that it still fails. I highly suspect that the above GIT_VERSION code was needed for older kernel versions, though I can't exactly pinpoint why and when this was changed. However, since I don't think backwards compatibility is much of an issue here, since user compiling git kernels will usually be compiling recent kernels anyway. Also, I'd rather have this possibly break on older (git) kernels, than knowing it breaks all newer git kernels. I've attached a patch that completely removes all GIT_VERSION stuff, this makes make-kpkg work properly again on my system, with LOCALVERSION_AUTO enabled. Gr. Matthijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493714: openttd: Network exploitable buffer overrun
Hi, I got a private mail by the maintainer stating: New version should be uploaded this weekend, I'll mail the release team with details when that happens. I'm having a bit of a problem with this upload, since my regular sponsor seems to be away. I had asked a DD to upload it last weekend, but hasn't had time for it yet. I've put the new version up at mentors.debian.net and asked for a sponsor on debian-mentors@ as well. Release team has also been mailed about possibly including this version in testing. Gr. Matthijs signature.asc Description: Digital signature
Bug#492643: [Splashy-devel] Bug#492643: Can reproduce!
Isn't this bug 462626? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462626 Not sure if that is exactly the same bug, but I'm pretty sure it is related. Complicated stuff, this :-) Needed a change to libdirectfb to get it to work. Was that change done? No clue, people are still talking about having a patched directfb or not, and the post to the directfb mailing list with that patch didn't have any replies, so I'd guess not. Perhaps someone should apt-get source directfb (no time now, though). Gr. Matthijs signature.asc Description: Digital signature
Bug#492643: Can reproduce!
Package: splashy
Version: 0.3.11-1
Hi,
after some more fiddling, I can reproduce this after all!
It turns out that the don't start splashy in initramfs when resume is set
was preventing me from reproducing the problem.
When splashy is indeed started in initramfs, splashy freezes for me as well.
It turns out that it is not the getpass that freezes, but it's the keyboard
input that gets broken (even before the getpass call).
Some investigation turns out that this freezing happens very close to the
moment where init switches to runlevel 2 and is probably triggered by
something init does. When inserting a sleep at the start and end of my
/etc/init.d/rc script, it turns out that keyboard input is working fine at the
end of the sysinit runlevel (after running all scripts in /etc/rcS.d), but
stops working at the beginning of runlevel 2 (before running any scripts in
/etc/rc2.d).
It turns out that removing the splashy_chvt 8 call near the end of
/usr/share/initramfs-tools/scripts/init-top/splashy solves my problems:
keyboard input remains functional during the entire boot process. This made me
suspect that init somehow forces the current vt back to 1 when switching to
runlevel 2, (which is then not visible on the screen since directfb writes
directly on the framebuffer, but is enforced on the keyboard input side of
things).
This is also confirmed by the fact that, when the chvt 8 is present in
initramfs, after the full boot, I end up with an empty screen. Pressing alt-F1
changes nothing, but pressing enter gives me tty1. This might also be splashy
(or the splashy initscript) that switches back to vt1 after it exits (does
it?).
However, when I quit splashy before init switches to runlevel 2 (either during
initramfs or during sysinit runlevel), I end up on vt8, even after init enters
runlevel 2. This seems to be contradictory to my above theory.
I've also spent some timing digging around in init's sources, but I can't seem
to find anything it does between the sysinit runlevel and runlevel 2 that
could cause something like this.
There is the following code in the spawn() function, which is responsible for
setting up the environment and forking just before running any command (in
particular, this is executed before running /etc/init.d/rcS):
/*
* In sysinit, boot, bootwait or single user mode:
* for any wait-type subprocess we _force_ the console
* to be its controlling tty.
*/
if (strchr(*#sS, runlevel) ch-flags WAITING) {
/*
* We fork once extra. This is so that we can
* wait and change the process group and session
* of the console after exit of the leader.
*/
setsid();
if ((f = console_open(O_RDWR|O_NOCTTY)) = 0) {
/* Take over controlling tty by force */
(void)ioctl(f, TIOCSCTTY, 1);
dup(f);
dup(f);
}
I'm not sure what it does, but it would be weird that something that happens
at the beginning of the sysinit level would break things (one would expect
that something at the beginning of runlevel 2 would break it). On the other
hand, it could be that this code actually makes things work, or that some code
in the else branch of the above if breaks it (though it looks innocent
enough).
So, a solution seems to be to not change to vt8 in initramfs, but unless we
found out what happens exactly, it might not be a good idea to just remove
that and see what happens. Also, since splashy tells libdirectfb to use vt8
(according to Luis), this might need changing as well (though it does seem to
work with just removing the chvt 8, at least on my system).
I'm out of time for now, Jonas, could you see if removing the splashy_chvt 8
works for you as well?
Gr.
Matthijs
signature.asc
Description: Digital signature
Bug#492643: Can't reproduce
Hi Jonas, I just tried to reproduce this issue, but couldn't. I added an initscript, containing just the splashy_update getpass call you described. This results in a proper prompt, in which I can enter a password, after which booting continues as normal. This can mean a few things: 1) You have very particular setup that triggers this bug. Since you tried on two different systems IIRC, this might not be so likely. 2) Having a crypt setup triggers this bug. Perhaps some kernel option? Or the cryptsetup init script (or did you disable that while testing the splashy_update-only init script?) 3) The order in the boot sequence triggers this bug. I tried using a new initscript and added it using update-rc.d testplashy defaults, which places it rather late in the boot sequence. Did you do this as well? In any case, it would be useful if you could do some more debugging to find out what exactly triggers this bug, since I don't really know where to begin to reproduce this. If you get any closer, I would be glad to test any hypothesis you have on the cause of it (just ask me on IRC). Gr. Matthijs signature.asc Description: Digital signature
Bug#451709: grub: Here's a patch
Package: grub Version: 0.97-29 Tags: Patch Followup-For: Bug #451709 Hi, I was about to report this same bug, but I wasn't the first :-) Anyway, I already whipped up a patch, which is attached. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-rc4-wl-01808-g58b22b3-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information --- grub-set-default.1.orig 2008-05-12 21:47:01.0 +0200 +++ grub-set-default.1 2008-05-12 21:49:02.0 +0200 @@ -23,7 +23,7 @@ \fB\-\-root-directory=DIR\fR Use the directory DIR instead of the root directory .TP -ENTRY is a number or the special keyword `default\'. +ENTRY is a number or the special keyword `default\'. The first entry has the number 0. .SH REPORTING BUGS Report bugs to [EMAIL PROTECTED] .SH SEE ALSO
Bug#334505: Similar problem
Hi, I'm experiencing a problem that results in the same error message, which might be related. My xterm crashes when trying to display some UTF characters, with the following error: xterm: warning, error event received: X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 77 (X_ImageText16) Serial number of failed request: 338 Current serial number in output stream: 339 This is easy to reproduce, try running this in xterm: echo -e \0304\211 which immediately crashes xterm. If this also crashes your xterm, these issues might be related (or they might still be something entirely different, of course). Does your xterm / .profile / .bashrc or something else print stuff on startup? Might it be that there is a weird character in such a message that throws off xterm? Perhaps the message changes after the X server was started for some time? Gr. Matthijs signature.asc Description: Digital signature
Bug#334505: Similar problem
Hi, it seems to be font-related. I use a non-standard font (see below), removing the first xterm resource (so using the default font) makes the echo display the correct character. So it seems xterm (or Xorg?) doesn't handle missing characters that well? Or would there be something wrong with the font. On second thought, I found it peculiar that I didn't have these problems a while back, and quite often now. This might be related to my recent switching to xfs / xfstt. I'll try switching back to Xorg serving fonts and see what happens. Btw, the font I am using for xterm is in the xfonts-terminus package. Gr. Matthijs That works fine here. What's the output of 'appres XTerm' and 'locale'? [EMAIL PROTECTED]:~$ appres xterm xterm.vt100.font: -xos4-terminus-medium-r-normal--14-*-*-*-c-*-iso10646-1 xterm.vt100.background: black xterm.vt100.foreground: grey [EMAIL PROTECTED]:~$ locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=en_US.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL= signature.asc Description: Digital signature
Bug#470609: sa-learn: Should document homedir used for bayes database
Package: sa-learn Severity: wishlist Hi, I've been trying to get sa-exim working for a while. The first try worked rather well, but I didn't get bayes filtering working. It turns out that, although spamd runs as root, it gets the --helper-home-dir option passed. This means that when sa-exim uses spamd for scanning, it looks in /var/spool/exim4 for the bayes database, not in /root. This is rather confusing. I would propose adding the following paragrah to README.Debian: Bayesian filtering and sa-learn --- To get Bayesian filtering working in spamassassin, it needs to learn from a number of sample spam and non-spam messages. To do this, spamassassin provides the sa-learn command. Using the sa-learn command, you can build up a database that is used in bayesian filtering. This database is, by default, stored in ~/.spamassassin. Running sa-learn as root will build this database in root's homedirectory. Now, even though spamd runs as root by default, it will not use the database from root's homedir. By default, spamd runs with the --helper-home-dir option, meaning that it will use the homedir of however is calling spamc (which in this case is exim through sa-exim, so it will use the database in /var/spool/exim4/.spamassassin). To get sa-learn to update the right database, call it as sa-learn --dbpath /var/spool/exim4/.spamassassin Gr. Matthijs -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.9-023stab044.11-enterprise Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462604: Czech translation not displayed correctly
Hey, I just started OpenTTD from Debian package and Czech translation is not working there properly - instead of some characters just question mark is displayed. I'm not sure if it is package compilation or upstream problem This is actually caused by the default font that misses a lot of characters. There is a not in the readme, stating: With the added support for font-based text selecting a non-latin language will result in garbage (lots of '?') shown on screen. Please open your configuration file and add a desired font for small/medium/-and large_font. This can be a font name like Tahoma or a path to a font. Could you check if setting another font in your configuration file (~/.openttd/openttd.cfg) fixes the problem for you? The upcoming 0.6.0 version checks for this problem and points you to the readme file if any characters are missing. Gr. Matthijs signature.asc Description: Digital signature
Bug#461594: frotz: Mentions package int-fiction-installer which is no longer available
Package: frotz Version: 2.43-1 Severity: minor Both the control file (in the Suggests field) and README.Debian mention the int-fiction installer, which is no longer available. Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc5-g940ca25e-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages frotz depends on: ii libc6 2.7-4 GNU C Library: Shared libraries ii libncurses5 5.6+20071215-1 Shared libraries for terminal hand frotz recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460073: Closing bug, patch no longer available
package openttd reopen 460073 retitle 460073 Add .desktop file tags 460073 + patch thanks I'm closing #452447, since the patch it links to is no longer available. Additionally, I remember the patch not being fully correct. I'm reopening #460073, since it includes a proper patch. I'll add the patch with the next upload. Gr. Matthijs signature.asc Description: Digital signature
Bug#458556: pulseaudio: module-native ignores protocol version, making module-tunnel not work
Package: pulseaudio Version: 0.9.8-1 Severity: normal Tags: patch Hey, the Debian pulseaudio package includes a patch to 'fix' module-tunnel by reporting protocol version 11 instead of the most current. This makes module-tunnel behave correctly, but it still does not work on 0.9.8 servers. This is caused by module-native-tcp ignoring the protocol version in some cases. This issue is reported at http://www.pulseaudio.org/ticket/183, where a trivial patch is also provided. Perhaps this patch could be included in the debian package of 0.9.8, enabling it to work with protocol 11 clients (such as the module-tunnel in 0.9.8). Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-rc5-g1002f7ae-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages pulseaudio depends on: ii adduser 3.104 add and remove users and groups ii libasound21.0.15-2 ALSA library ii libasyncns0 0.3-1 Asyncronous name service query lib ii libc6 2.7-4 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libdbus-1-3 1.1.1-3simple interprocess messaging syst ii libltdl3 1.5.24-2 A system independent dlopen wrappe ii liboil0.3 0.3.12-1 Library of Optimized Inner Loops ii libpulsecore5 0.9.8-1PulseAudio sound server core ii libsamplerate00.1.2-5audio rate conversion library ii libsndfile1 1.0.17-4 Library for reading/writing audio ii libwrap0 7.6.dbs-14 Wietse Venema's TCP wrappers libra ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip Versions of packages pulseaudio recommends: pn gstreamer0.10-pulseaudio none (no description available) ii libasound2-plugins1.0.15-1 ALSA library additional plugins pn padevchooser none (no description available) ii paprefs 0.9.6-1PulseAudio Preferences pn pulseaudio-esound-compat none (no description available) pn pulseaudio-module-hal none (no description available) pn pulseaudio-module-x11 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437466: module-assistant: Fourth option: Listen to the manpage
Package: module-assistant
Version: 0.10.11
Tags: patch
Followup-For: Bug #437466
Hey,
I didn't really get your second option, so excuse me if my proposal is
similary.
I see a fourth option to fix this: Do what the manpage says.
--kernel-dir
The kernel source directories to be used for builds. You can
specify multiple directories with multiple options or separated by commas or
line separators (e.g using -k `echo /usr/src/kernel-headers-*`
). The kernel versions detected in this directories are automatically added
to the list of target kernel versions (see --kvers-list for
details).
The manpage promises to add the kernel versions found in the source dirs
to the --kvers-list option, but module-assistant doesn't.
The attached patch does exactly this.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-rc3-gd928769a-dirty (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages module-assistant depends on:
ii libtext-wrapi18n-perl 0.06-5 internationalized substitute of Te
ii perl 5.8.8-7Larry Wall's Practical Extraction
Versions of packages module-assistant recommends:
ii liblocale-gettext-perl1.05-1 Using libc functions for internati
-- no debconf information
--- /usr/bin/module-assistant.orig 2007-12-30 14:08:01.0 +0100
+++ /usr/bin/module-assistant 2007-12-30 14:12:25.0 +0100
@@ -1286,6 +1286,7 @@
if(close($versionh)) {
$kernelvers{$_}=$1;
$kerneldirs{$1}=$_;
+push(@opt_kverslist, $1);
}
elsif(-r $_/Makefile) {
printmsg sprintf(gettext(Warning, %s seems to contain
unconfigured kernel source (see manpage for details)!), $_) if !$opt_quiet;
Bug#456956: [INTL:fi] Finnish translation of the debconf templates
Hey Esko, thanks for your contribution. I will include it in the next version, which will I will probably hold off a few weeks to wait for 0.6.0. Gr. Matthijs signature.asc Description: Digital signature
Bug#456590: fails to start without pulseaudio-esound-compat with default configuration
Package: pulseaudio Version: 0.9.8-1 Severity: important Tags: patch Hey, the default configuration of the pulseaudio daemon requires the esound compatibility layer to start. When only the pulsaudio package is installed, the following errors are reported: Dec 16 20:35:41 katherina pulseaudio[26311]: module.c: Failed to open module module-esound-protocol-unix: module-esound-protocol-unix.so: cannot open shared Dec 16 20:35:41 katherina pulseaudio[26311]: main.c: Module load failed. Dec 16 20:35:41 katherina pulseaudio[26311]: main.c: failed to initialize daemon. Dec 16 20:35:41 katherina pulseaudio[26310]: main.c: daemon startup failed. Removing the following line from /etc/pulse/default.pa fixes the problem. load-module module-esound-protocol-unix socket=/tmp/.esd/socket Replacing it with the following should provide a permanent solution: .ifexists /usr/lib/pulse-0.9/modules/module-esound-protocol-unix.so load-module module-esound-protocol-unix socket=/tmp/.esd/socket .endif I would guess that installing the pulseaudio-esound-compat would also fix the problem, but that is of course not good enough :-) Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.6 (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages pulseaudio depends on: ii adduser 3.105 add and remove users and groups ii libasound2 1.0.14a-2 ALSA library ii libasyncns0 0.3-1 Asyncronous name service query lib ii libc62.7-4 GNU C Library: Shared libraries ii libcap1 1:1.10-14 support for getting/setting POSIX. ii libdbus-1-3 1.1.1-3 simple interprocess messaging syst ii libltdl3 1.5.24-1A system independent dlopen wrappe ii liboil0.30.3.12-1+b1 Library of Optimized Inner Loops ii libpulsecore50.9.8-1 PulseAudio sound server core ii libsamplerate0 0.1.2-5 audio rate conversion library ii libsndfile1 1.0.17-4Library for reading/writing audio ii libwrap0 7.6.dbs-14 Wietse Venema's TCP wrappers libra ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip Versions of packages pulseaudio recommends: pn gstreamer0.10-pulseaudio none (no description available) pn libasound2-pluginsnone (no description available) pn padevchooser none (no description available) pn paprefs none (no description available) pn pulseaudio-esound-compat none (no description available) pn pulseaudio-module-hal none (no description available) pn pulseaudio-module-x11 none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450431: laptop-mode-tools: lm-profiler.conf(8) contains confusing statement
Package: laptop-mode-tools Version: 1.34-1 Severity: minor From the lm-profiler.conf (8) manpage: RECOMMEND_DEFAULT_SERVICES DEFAULT_SERVICES If DEFAULT_SERVICES is set to 1 (enabled), then lm-profiler will always suggest turning off the services listed in DEFAULT_SERVICES (separated by spaces). This says that DEFAULT_SERVICES must be set to 1 and to a space separated list of services to do its work. I suspect that RECOMMEND_DEFAULT_SERVICES must be set to 1 and DEFAULT_SERVICES to the list of services. Whatever the case, the current documentation is wrong and confusing. Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-gdb26fd2a-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages laptop-mode-tools depends on: ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip Versions of packages laptop-mode-tools recommends: ii acpid 1.0.4-7.1 Utilities for using ACPI power man ii hdparm7.7-1 tune hard disk parameters for high ii sdparm1.02-1 Output and modify SCSI device para -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#446809: bacula-director-mysql: Database password for catalog backups out in the open
Package: bacula-director-mysql Severity: important Tags: patch, security Hi, the default bacula configuration file supports backing up the catalog database using the make_catalog_backup script. For this, the following line is in bacula-dir.conf: RunBeforeJob = /etc/bacula/scripts/make_catalog_backup bacula bacula If the database is password protected, the password must be added as a third argument. This works as expected, but poses up a number of security risks. Firstly, when the backup fails, the complete command line is put into an email with the error messages, including the password. For example: 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: run command /etc/bacula/scripts/make_catalog_backup bacula bacula c1130ee16f7125579d6214bcd114b71 15-Oct 21:10 stdio.flexvps.nl-dir: BeforeJob: mysqldump: Got error: 1045: Access denied for user 'bacula'@'localhost' (using password: YES) when trying to +connect Since email is no secure channel, this can expose the database password. Having the database password in the error message hardly serves any purpose and should probably be avoided. Additionally, having the password on the commandline, makes it available to users on the same machine. The command lines of running processes are usually accessible to users, so running a simple [EMAIL PROTECTED]:~$ ps aux|grep catalog bacula 11706 0.0 0.0 4092 1452 ?S21:43 0:00 /bin/sh /etc/bacula/scripts/make_catalog_backup bacula bacula 0c1130ee16f7125579d6214bcd114b71 reveals the database password. It would be better to store the password in an external file, and pass that filename to the make_catalog_backup script. In this way, the make_catalog_backup script is still generic, but the database password is not exposed (though that file should be readable by the bacula user, not only by root). The attached patch achieves the above, while maintaining backwards compatibility. It might be better to remove backwards compatibility to prevent users from using the old, insecure way, however. Additionally, my modifications to the script could pose problems if someone uses a database password that is also the name of an existing file. Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-rc9-g1b60e5d0-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bacula-director-mysql depends on: pn bacula-director-common none (no description available) pn dbconfig-common none (no description available) ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy ii libc6 2.6.1-1 GNU C Library: Shared libraries ii libgcc1 1:4.2.1-4GCC support library ii libmysqlclient15off 5.0.45-1 MySQL database client library ii libstdc++6 4.2.1-4 The GNU Standard C++ Library v3 ii libwrap07.6.dbs-14 Wietse Venema's TCP wrappers libra ii mysql-client-5.0 [mysql 5.0.45-1 MySQL database client binaries ii python2.4 2.4.4-6 An interactive high-level object-o ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime Versions of packages bacula-director-mysql recommends: ii mysql-server-5.0 [mysql-serve 5.0.45-1 MySQL database server binaries --- make_catalog_backup 2007-10-15 21:43:20.0 +0200 +++ make_catalog_backup_safe2007-10-15 22:08:42.0 +0200 @@ -7,16 +7,16 @@ # of the output file (default = bacula). # $2 is the user name with which to access the database # (default = bacula). -# $3 is the password with which to access the database or if no password -# (default ) +# $3 is the name of a file which holds the password with which to access the +# database or if no password (default ). Can also be the actual +# password instead of a filename, but this is only provided for backwards +# compatibility and is insecure. # $4 is the host on which the database is located # (default ) # # BINDIR=/usr/bin -sleep 200 - cd /var/lib/bacula rm -f $1.sql if test xsqlite = xmysql ; then @@ -24,7 +24,11 @@ else if test xmysql = xmysql ; then if test $# -gt 2; then - MYSQLPASSWORD= --password=$3 + if [ -r $3 ]; then +MYSQLPASSWORD= --password=`cat \$3\` + else +MYSQLPASSWORD= --password=$3 + fi else MYSQLPASSWORD= fi
Bug#446355: bash: [COMPLETION] sudo -e should list filenames instead of commands
Package: bash Version: 3.1dfsg-8 Severity: wishlist sudo -e filename allows users to edit files through sudo. So, instead of completing commands, completion should list filenames. Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-rc9-g1b60e5d0-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages bash depends on: ii base-files4.0.1 Debian base system miscellaneous f ii debianutils 2.23.1 Miscellaneous utilities specific t ii libc6 2.6.1-1GNU C Library: Shared libraries ii libncurses5 5.6+20070825-1 Shared libraries for terminal hand bash recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423576: uswsusp: Problem solved in 2.6.23?
Package: uswsusp Followup-For: Bug #423576 Hey, I've been working with swap on LVM as well, and it works for me using 2.6.23-rc9. I've also tested 2.6.22, which did not work (though it does poweroff and breaks the swap signature, but does not resume). So, it seems that 2.6.23 will fix this problem. Perhaps the original reporter can verify this? Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23-rc9-g18ca6f26-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages uswsusp depends on: ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy ii libc6 2.6.1-1 GNU C Library: Shared libraries ii libgcc1 1:4.2.1-4GCC support library ii libgcrypt11 1.2.4-2 LGPL Crypto library - runtime libr ii liblzo2-2 2.02-3 data compression library ii libsplashy1 0.3.5Library to draw splash screen on b ii libx86-10.99-1.2 x86 real-mode library ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime Versions of packages uswsusp recommends: ii initramfs-tools 0.90a tools for generating an initramfs ii mount 2.13-2 Tools for mounting and manipulatin -- debconf information: uswsusp/suspend_loglevel: uswsusp/no_swap: uswsusp/resume_offset: uswsusp/early_writeout: true uswsusp/image_size: 666318110 uswsusp/snapshot_device: uswsusp/max_loglevel: uswsusp/shutdown_method: platform uswsusp/encrypt: false uswsusp/RSA_key_bits: 1024 uswsusp/continue_without_swap: true uswsusp/compute_checksum: false uswsusp/no_snapshot: uswsusp/compress: true uswsusp/create_RSA_key: false uswsusp/RSA_key_file: /etc/uswsusp.key uswsusp/resume_device: /dev/mapper/Xanthe-swap uswsusp/splash: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445974: hibernate: Should support s2ram -r (radeontool) option
Package: hibernate
Version: 1.96~pre-svn.r1136-1
Severity: wishlist
Tags: patch
Hey,
The attached patch adds support for the s2ram -r option to hibernate.
Gr.
Matthijs
-- Package-specific info:
--- configuration
== /etc/hibernate/common.conf ==
Verbosity 0
LogFile /var/log/hibernate.log
LogVerbosity 1
Distribution debian
SaveClock restore-only
UnmountFSTypes smbfs nfs vfat
UnmountGraceTime 1
OnSuspend 20 wpa_action wlan0 stop || true
UnloadModules rt2500pci
UnloadBlacklistedModules yes
LoadModules psmouse rt2500pci
== /etc/hibernate/disk.conf ==
TryMethod ususpend-disk.conf
TryMethod sysfs-disk.conf
== /etc/hibernate/hibernate.conf ==
TryMethod suspend2.conf
TryMethod disk.conf
TryMethod ram.conf
== /etc/hibernate/ram.conf ==
TryMethod ususpend-ram.conf
TryMethod sysfs-ram.conf
== /etc/hibernate/suspend2.conf ==
UseSuspend2 yes
Reboot no
EnableEscape yes
DefaultConsoleLevel 1
Compressor lzf
Encryptor none
FullSpeedCPU yes
Include common.conf
== /etc/hibernate/sysfs-disk.conf ==
UseSysfsPowerState disk
Include common.conf
== /etc/hibernate/sysfs-ram.conf ==
UseSysfsPowerState mem
Include common.conf
== /etc/hibernate/ususpend-both.conf ==
USuspendMethod both
Include common.conf
== /etc/hibernate/ususpend-disk.conf ==
USuspendMethod disk
Include common.conf
== /etc/hibernate/ususpend-ram.conf ==
USuspendMethod ram
USuspendRamForce yes
USuspendRamAcpiSleep 1
Include common.conf
--- /sys/power
== /sys/power/disk ==
[platform] test testproc shutdown reboot
== /sys/power/image_size ==
666318110
== /sys/power/resume ==
254:1
== /sys/power/state ==
standby mem disk
--- log
Starting suspend at Tue Oct 9 13:33:42 CEST 2007
hibernate: [01] Executing CheckLastResume ...
hibernate: [01] Executing CheckRunlevel ...
hibernate: [01] Executing LockFileGet ...
hibernate: [01] Executing NewKernelFileCheck ...
hibernate: [10] Executing EnsureUSuspendCapable ...
hibernate: [20] Executing MiscLaunchAuxFunc1 ...
Executing wpa_action wlan0 stop || true...
hibernate: [45] Executing FSTypesUnmount ...
hibernate: [59] Executing RemountXFSBootRO ...
hibernate: [89] Executing SaveKernelModprobe ...
hibernate: [90] Executing ModulesUnload ...
hibernate: [91] Executing ModulesUnloadBlacklist ...
hibernate: [98] Executing CheckRunlevel ...
hibernate: [99] Executing DoUSuspend ...
hibernate: Running /usr/sbin/s2ram -f -a 1 ...
hibernate: [90] Executing ModulesLoad ...
hibernate: [89] Executing RestoreKernelModprobe ...
hibernate: [70] Executing ClockRestore ...
hibernate: [59] Executing RemountXFSBootRW ...
hibernate: [01] Executing NoteLastResume ...
hibernate: [01] Executing LockFilePut ...
Resumed at Tue Oct 9 13:33:50 CEST 2007
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.23-rc9-g18ca6f26-dirty (PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages hibernate depends on:
ii console-tools 1:0.2.3dbs-65 Linux console and font utilities
Versions of packages hibernate recommends:
pn dash none (no description available)
ii hdparm7.7-1 tune hard disk parameters for high
ii uswsusp 0.7-1 tools to use userspace software su
pn vbetool none (no description available)
-- no debconf information
--- /root/ususpend 2007-10-09 12:05:50.0 +0200
+++ /usr/share/hibernate/scriptlets.d/ususpend 2007-10-09 12:08:03.0
+0200
@@ -9,6 +9,7 @@
AddConfigHelp USuspendRamVbeSave boolean Passes the -s flag to s2ram to
save VBE state before suspending and restore after resume
AddConfigHelp USuspendRamVbePost boolean Passes the -p flag to s2ram to
VBE POST the graphics card after resume
AddConfigHelp USuspendRamVbeMode boolean Passes the -m flag to s2ram to
get VBE mode before suspend and set it after resume
+AddConfigHelp USuspendRamRadeontool boolean Passes the -r flag to s2ram
to let radeontool turn of the backlight before suspending.
AddConfigHelp USuspendRamAcpiSleep number Passes the -a flag to s2ram to
set the acpi_sleep parameter before suspend: 1=s3_bios, 2=s3_mode, 3=both
AddShortOption n
@@ -21,6 +22,7 @@
USUSPEND_RAM_VBESAVE=0
USUSPEND_RAM_VBEPOST=0
USUSPEND_RAM_VBEMODE=0
+USUSPEND_RAM_RADEONTOOL=0
USUSPEND_RAM_ACPISLEEP=0
USuspendConfigEnabler() {
@@ -58,6 +60,9 @@
ususpendramvbemode)
BoolIsOn $1 $2 USUSPEND_RAM_VBEMODE=1 || return 0
;;
+ ususpendramradeontool)
+ BoolIsOn $1 $2 USUSPEND_RAM_RADEONTOOL=1 || return 0
+ ;;
ususpendramacpisleep)
USUSPEND_RAM_ACPISLEEP=$2 || return 0
;;
@@ -93,6 +98,7 @@
[ $USUSPEND_RAM_FORCE -eq 1 ] ARGS=$ARGS -f
[ $USUSPEND_RAM_VBESAVE -eq 1 ] ARGS=$ARGS -s
[ $USUSPEND_RAM_VBEPOST -eq 1 ] ARGS=$ARGS -p
+ [
Bug#438932: git-core: Inconsistency in README.Debian
Package: git-core Version: 1:1.5.2.4-1 Severity: minor README.Debian says: 3. Configure a web server for git. This allows people to use a git:// URL to access your repositories. A bit further down, it says: Now git-clone rsync://git.example.org/git/repo will work. And if you That should both probably be http:// Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22rfkill-g98ff3b8b-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-core depends on: ii libc6 2.6-2GNU C Library: Shared libraries ii libcurl3-gnutls 7.16.2-6 Multi-protocol file transfer libra ii libdigest-sha1-perl 2.11-2 NIST SHA-1 message digest algorith ii liberror-perl 0.15-8 Perl module for error/exception ha ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii perl-modules5.8.8-7 Core Perl modules ii zlib1g 1:1.2.3.3.dfsg-4 compression library - runtime Versions of packages git-core recommends: ii curl 7.16.2-6 Get a file from an HTTP, HTTPS or pn git-doc none (no description available) ii less 406-0 Pager program similar to more ii openssh-client [ssh-client] 1:4.6p1-4 secure shell client, an rlogin/rsh ii patch 2.5.9-4Apply a diff file to an original ii rsync 2.6.9-3fast remote file copy program (lik -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438932: Acknowledgement (git-core: Inconsistency in README.Debian)
In the same file, in the apache configuration is: Alias /git /var/git Shouldn't that be /var/cache/git instead, when the repositories are in /var/cache/git ? Gr. Matthijs signature.asc Description: Digital signature
Bug#433217: kernel-package: Version check compares wrong vars
Package: kernel-package Version: 11.001 Severity: normal Hey, in ruleset/targets/targets.mk:300, I find the following, under the debian/stamp-build-kernel target: $(if $(subst $(strip $(UTS_RELEASE_VERSION)),,$(strip $(version))), \ if [ -f $(UTS_RELEASE_HEADER) ]; then \ uts_ver=$$(grep 'define UTS_RELEASE' $(UTS_RELEASE_HEADER) | \ perl -nle 'm/^\s*\#define\s+UTS_RELEASE\s+(?)(\S+)\1/g print $$2;'); \ if [ X$$uts_ver != X$(strip $(UTS_RELEASE_VERSION)) ]; then \ echo The UTS Release version in $(UTS_RELEASE_HEADER); \ echo \$$uts_ver\ ; \ echo does not match current version ; \ echo \$(strip $(version))\ ; \ echo Reconfiguring. ; \ touch Makefile; \ fi; \ fi) This extracts the version number from utsrelease.h and compares it with $UTS_RELEASE_VERSION. AFAICS, $UTS_RELEASE_VERSION should by definition also contain the version extracted from utsrelease.h. It would be more logical to compare either $UTS_RELEASE_VERSION or $uts_ver with $version, which is also what the output would suggest (the current output does not match the check performed). All other version checks I found do exactly this. It seems that this is also why version mismatches appear to only be detected until after the entire kernel has been compiled (which kinda slowed down my debugging for #423721, for example). Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-rc6-ga5b67c9e-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kernel-package depends on: ii dpkg 1.14.5 package maintenance system for Deb ii dpkg-dev 1.14.5 package building tools for Debian ii file 4.21-1 Determines file type using magic ii gcc [c-compiler] 4:4.1.2-3 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-12 The GNU C compiler ii gettext 0.16.1-2 GNU Internationalization utilities ii make 3.81-3 The GNU version of the make util ii perl 5.8.8-7Larry Wall's Practical Extraction ii po-debconf1.0.9 manage translated Debconf template Versions of packages kernel-package recommends: ii bzip2 1.0.3-7high-quality block-sorting file co ii libc6-dev [libc-dev] 2.5-11 GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423721: kernel-package: -dirty is not always set correctly
Package: kernel-package Version: 11.001 Followup-For: Bug #423721 Hey, I've been looking a bit more into this stuff and found that -dirty is not always correcty set. In particular, if the git source tree is still clean when make-kpkg is first run, the debian target will not have -dirty in the package name. Later on, at the stamp-config fixes some idocy by removing scripts/package/builddeb and scripts/package/Makefile, which makes the git checkout dirty. So, by the time that utsrelease.h is generated, the checkout is dirty. I think this is exactly what the GIT_VERSION variable is supposed to fix, but it contains the full local version, with an extra -dirty appended. I've attached a patch that should work around this by doing the builddeb/Makefile fix before creating the debian/ dir, so the git checkout will be dirty from the very beginning. I think this is the most reliable way to handle this, if we really need to make the checkout dirty. It would, of course, be very much preferable if kernel-package did not touch any of the git-controlled files, so the checkout would remain clean (which gives the -dirty suffix a bit more meaning). I'm not sure what those files do or why they are a problem, but couldn't that be solved without modifying them? (I've checked that, after a full kernel_image, those two files are the only changes that make the checkout dirty). Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-rc6-ga5b67c9e-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kernel-package depends on: ii dpkg 1.14.5 package maintenance system for Deb ii dpkg-dev 1.14.5 package building tools for Debian ii file 4.21-1 Determines file type using magic ii gcc [c-compiler] 4:4.1.2-3 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-12 The GNU C compiler ii gettext 0.16.1-2 GNU Internationalization utilities ii make 3.81-3 The GNU version of the make util ii perl 5.8.8-7Larry Wall's Practical Extraction ii po-debconf1.0.9 manage translated Debconf template Versions of packages kernel-package recommends: ii bzip2 1.0.3-7high-quality block-sorting file co ii libc6-dev [libc-dev] 2.5-11 GNU C Library: Development Librari -- no debconf information diff -ur ruleset.orig/minimal.mk ruleset/minimal.mk --- ruleset.orig/minimal.mk 2007-07-15 18:53:21.0 +0200 +++ ruleset/minimal.mk 2007-07-15 18:38:16.0 +0200 @@ -89,6 +89,12 @@ minimal_debian: $(REASON) @echo This is kernel package version $(kpkg_version). + # work around idiocy in recent kernel versions + test ! -e scripts/package/builddeb || \ +mv -f scripts/package/builddeb scripts/package/builddeb.kpkg-dist + test ! -e scripts/package/Makefile || \ +(mv -f scripts/package/Makefile scripts/package/Makefile.kpkg-dist \ + (echo # Dummy file ; echo help:) scripts/package/Makefile) test -d debian || mkdir debian test ! -e stamp-building || rm -f stamp-building test -f debian/control || sed -e 's/=V/$(version)/g'\ diff -ur ruleset.orig/misc/version_vars.mk ruleset/misc/version_vars.mk --- ruleset.orig/misc/version_vars.mk 2007-07-15 18:53:05.0 +0200 +++ ruleset/misc/version_vars.mk2007-07-15 18:39:03.0 +0200 @@ -95,12 +95,6 @@ ifneq (,$(strip $(HAVE_BAD_VERSION))) $(error Error: $(VERSION)) endif - ifneq ($(strip $(CONFIG_LOCALVERSION_AUTO)),) -GIT_VERSION=$(shell /bin/sh scripts/setlocalversion) -ifneq ($(strip $(GIT_VERSION)),) - GIT_VERSION:=$(GIT_VERSION)-dirty -endif - endif else ifeq ($(DEB_HOST_GNU_SYSTEM), kfreebsd-gnu) VERSION=$(call doit,grep '^REVISION=' conf/newvers.sh | \ @@ -152,7 +146,7 @@ else echo ; \ fi) -version = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(iatv)$(LOCALVERSION)$(GIT_VERSION) +version = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(iatv)$(LOCALVERSION) # Bug out if the version number id not all lowercase lc_version = $(call doit,echo $(version) | tr A-Z a-z) @@ -163,7 +157,6 @@ VERSION=[$(VERSION)], PATCHLEVEL=[$(PATCHLEVEL)], \ SUBLEVEL=[$(SUBLEVEL)], EXTRAVERSION=[$(EXTRAVERSION)],\ iatv=[$(iatv)], LOCALVERSION=[$(LOCALVERSION)],\ - GIT_VERSION=[$(GIT_VERSION)] \ UTS_RELEASE_VERSION=[$(UTS_RELEASE_VERSION)], \
Bug#432711: kernel-package: local version not set when config is out of date
Package: kernel-package Version: 11.001 Severity: normal Hey, when fiddling around with version numbers for my kernels (while debuggind #423721) I noticed that the local version doesn't properly get set when .config is out of date. When, for example, running make-kpkg debian, minimal.mk will call misc/version_vars.mk for finding the kernel version. This in turn will use the debian_LOCALVERSION target in kernel_version.mk for finding the local version. Since the local version is dependent on the used configuration (for CONFIG_LOCAL_VERSION[_AUTO]) it will (I think, probably indirectly) call make config from the normal kernel Makefile (It will output my entire kernel configuration at least). When my configuration is from a previous kernel version (ie, I didn't run make oldconfig yet) the make config will hang halfway through when it finds a new config option). So, it does not output the local version as it should. Since the configuration is out of date, it is not illogical that things break, but it would be nicer to check the configuration first and issue a warning? Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-rc3-gcfb44989-dirty (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kernel-package depends on: ii dpkg 1.14.5 package maintenance system for Deb ii dpkg-dev 1.14.5 package building tools for Debian ii file 4.21-1 Determines file type using magic ii gcc [c-compiler] 4:4.1.2-3 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-12 The GNU C compiler ii gettext 0.16.1-2 GNU Internationalization utilities ii make 3.81-3 The GNU version of the make util ii perl 5.8.8-7Larry Wall's Practical Extraction ii po-debconf1.0.9 manage translated Debconf template Versions of packages kernel-package recommends: ii bzip2 1.0.3-7high-quality block-sorting file co ii libc6-dev [libc-dev] 2.5-11 GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383853: rred is some extraction mechanism?
Hey, it seems that rred is actually some extraction or patching method, since locate reveals /usr/lib/apt/methods/rred to exist. Also, various other bug reports talk about rred'ing as if it is something to do with downloaded pdiffs. Still, I would suggest something like Extracted or Processed, since the current rred looks like a spelling error... Gr. Matthijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372712: Max-Pdiffs option
Hey, I would propose a simple solution: Have a Acquire::Max-Pdiffs option. This is the number of pdiffs that will be downloaded, if more are required, a full download is done instead. The exact value would be dependent on the actual connection, but it should be possible to specify a decent default. People with really fast internet connections can tweak this option themselves (if it gets documented, see #376029). Also, this option might be used to replace Acquire::Pdiffs, for Max-Pdiffs = 0 would be always download full files, a special value all could be used to always do Pdiffs. Later, a special value auto might be added when there is some autodetecting mechanism that takes into account connection speed from previous updates. Gr. Matthijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430128: git-core: [amd64] Binary only upload breaks gitk dependency
Package: git-core Version: 1:1.5.2.2-1+b1 Severity: normal Hi, I'm not sure if this report should be here, or with gitk or somewhere entirely elsewhere, but I'll try here. The latest available version of git-core in unstable on amd64 is 1:1.5.2.2-1+b1. The problem is that gitk depends on git-core == 1:1.5.2.2-1. All other architectures, and all online references (packages.[qa.]debian.org) only list the not +b1 version, but that one is not available on amd64. Wondering what this +b1 version was exactly, I installed it and found this in the changelog: git-core (1:1.5.2.2-1+b1) unstable; urgency=low * Binary-only non-maintainer upload for amd64; no source changes. * Rebuild against libcurl3 -- Debian amd64 Build Daemon buildd_i386-excelsior Thu, 21 Jun 2007 12:51:29 + git-core (1:1.5.2.2-1) unstable; urgency=low So, the buid daemon seems to have bumped the version to rebuild for a broken libcurl3 or something of the like. I see two solutions here: * Bump the version to -2 and reupload with no changes. * Modify gitk to also depend on this version (though this will probably also need a -2 version bump). There might be other nifty solutions to this, but these are the ones my limited debian knowledge can conjure. Gr. Matthijs -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-rc3 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages git-core depends on: ii libc6 2.5-10 GNU C Library: Shared libraries ii libcurl3-gnutls 7.16.2-5 Multi-protocol file transfer libra ii libdigest-sha1-perl 2.11-2 NIST SHA-1 message digest algorith ii liberror-perl 0.15-8 Perl module for error/exception ha ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii perl-modules 5.8.8-7Core Perl modules ii zlib1g1:1.2.3-15 compression library - runtime Versions of packages git-core recommends: ii curl 7.16.2-4 Get a file from an HTTP, HTTPS or pn git-doc none (no description available) ii less 394-4 Pager program similar to more ii openssh-client [ssh-client] 1:4.3p2-11 secure shell client, an rlogin/rsh ii patch 2.5.9-4Apply a diff file to an original ii rsync 2.6.9-3fast remote file copy program (lik -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423721: GIT_VERSION contains (duplicate) localversion?
Hi, I've been fiddling around with the same problem for a while, here are my findings (and a suggestion for the real fix). The version that kernel-package finds for me is 2.6.22-rc4-g4d33a504-dirty-g4d33a504-dirty-dirty. This version is created at debian/ruleset/misc/version_vars.mk:155 version = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)$(iatv)$(LOCALVERSION)$(GIT_VERSION) Here, $LOCALVERSION = -g4d33a504-dirty and $GIT_VERSION = -g4d33a504-dirty-dirty I'm not really sure what these variables actually mean and are supposed to hold, but I find the initalization of GIT_VERSION a bit weird at debian/ruleset/misc/version_vars.mk:98 ifneq ($(strip $(CONFIG_LOCALVERSION_AUTO)),) GIT_VERSION=$(shell /bin/sh scripts/setlocalversion) ifneq ($(strip $(GIT_VERSION)),) GIT_VERSION:=$(GIT_VERSION)-dirty endif endif It would appear to me that 'setlocaversion' is supposed to set LOCALVERSION, not GIT_VERSION ? Seemingly it does, since GIT_VERSION contains LOCALVERSION with -dirty appended, as you would expect from this code. The main problem here is that the kernel itself (in utsrelease.h IIRC) thinks it's just 2.6.22-rc4-g4d33a504-dirty, without that GIT_VERSION crap. Halfway into the build process, this generates a version mismatch error. unsetting CONFIG_LOCALVERSION_AUTO fixes compile for me too, the version is now simply 2.6.22-rc4. In the main kernel Makefile:798, I find # If CONFIG_LOCALVERSION_AUTO is set scripts/setlocalversion is called # and if the SCM is know a tag from the SCM is appended. # The appended tag is determined by the SCM used. # # Currently, only git is supported. # Other SCMs can edit scripts/setlocalversion and add the appropriate # checks as needed. ifdef CONFIG_LOCALVERSION_AUTO _localver-auto = $(shell $(CONFIG_SHELL) \ $(srctree)/scripts/setlocalversion $(srctree)) localver-auto = $(LOCALVERSION)$(_localver-auto) endif localver-full = $(localver)$(localver-auto) This means that the CONFIG_LOCALVERSION_AUTO stuff is already done by the kernel Makefile itself and there is no need for version_vars.mk to fiddle around with GIT_VERSION anymore. AFAICS, the proper fix would be to throw out GIT_VERSION alltogether? Perhaps it was needed for older kernels, so it should get a version guard? Anyway, just my EUR 0,02. Gr. Matthijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
