Bug#1035620: New release 2024-07
On Thu, Aug 01, 2024 at 09:10:05PM +, Martin wrote: > are you OK with the new version and new upstream? > I'ld try my luck and upload then. I'm happy for you to adopt the package, if you're up for taking on permanent maintenance. Otherwise, I'd like to be able to cast an eye over a diff before upload, just for paranoia's sake. - Matt
Bug#932473: shorewall6 init script is broken in buster too
found 932473 5.2.3.2-1 severity 932473 important thanks I've noticed this problem is present in the buster version of shorewall6, also. I've bumped the severity because it "has a major effect on the usability of a package". - Matt
Bug#924422: Unbound 1.9.3 is packaged; is this bug OK to be closed?
Happened to notice this bug, seems that it no longer needs to be open because 1.9.3 is in the archive. Didn't want to unilaterally close it just in case, though. - Matt
Bug#768549: Workaround for missing packages after chroot creation
I've managed to work around the problem of missing packages, in general, with the following collection of commands (run from within the context of the chroot): yum clean metadata yum check dependencies \ | grep 'has missing requires' \ | sed 's/.\+has missing requires of //' \ | sed 's/ [=<>].\+//' \ | while read dep; do yum install -y "$dep"; done I run this after I run rinse (as part of a larger image building system), but I assume this could be stuck in a post-install hook or something. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#785685: Patch to provide libruby2.2-dbg (debugging symbols)
Attached is a patch to enable a debugging symbols package.
- Matt
diff --git a/debian/control b/debian/control
index fcd422e..e4eff5b 100644
--- a/debian/control
+++ b/debian/control
@@ -64,6 +64,22 @@ Description: Libraries necessary to run Ruby 2.2
This package includes the 'libruby-2.2' library, necessary to run Ruby 2.2.
(API version 2.2.0)
+Package: libruby2.2-dbg
+Section: debug
+Priority: extra
+Multi-Arch: same
+Architecture: any
+Depends:
+libruby2.2 (= ${binary:Version}),
+${misc:Depends}
+Description: Debugging symbols for libruby2.2
+ Ruby is the interpreted scripting language for quick and easy
+ object-oriented programming. It has many features to process text
+ files and to do system management tasks (as in perl). It is simple,
+ straight-forward, and extensible.
+ .
+ This package includes the debugging symbols for the 'libruby-2.2' library.
+
Package: ruby2.2-dev
Multi-Arch: same
Architecture: any
diff --git a/debian/rules b/debian/rules
index 1af9bce..d65e1cd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -104,3 +104,7 @@ import-orig-source:
test -n "$$UPSTREAM_VERSION"
cd $(UPSTREAM_GIT) && git archive --format=tar --prefix=ruby-$(UPSTREAM_VERSION)/ v$(shell echo $(UPSTREAM_VERSION) | tr . _) | xz -c > /tmp/ruby-$(UPSTREAM_VERSION).tar.xz
gbp import-orig /tmp/ruby-$(UPSTREAM_VERSION).tar.xz
+
+.PHONY: override_dh_strip
+override_dh_strip:
+ dh_strip --dbg-package=libruby2.2-dbg
Bug#769398: add config file support to picocom
On Thu, Nov 13, 2014 at 12:19:44PM +0100, Matteo Croce wrote: > this patch adds support for a minimal configuration file: > > $ cat ~/.picocomrc > port = /dev/ttyUSB0 > baud = 115200 Nice. Not sure when I'll get around to incorporating this (jessie's *just* been frozen, so no point rushing for that), but it'll go in at some stage. Thanks for the contribution. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752098: picocom: source download URL outdated
On Thu, Jun 19, 2014 at 09:13:01AM -0600, Greg Schenzel wrote: > The copyright file states: > > "It was downloaded from http://efault.net/npat/hacks/picocom/"; *Technically*, that is still correct -- I *did* download it from there originally. The URL may no longer work, but I'm not claiming that it's still an active URL. > That URL is defunct and the project is now hosted by Google Code at: > > Homepage: https://code.google.com/p/picocom/ > Download: https://picocom.googlecode.com/files/picocom-1.7.tar.gz Thanks for the pointers, I'll fling up a new package with updated links (and I might even go hog-wild and add a Homepage: field to debian/control). - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747376: Any further information needed for LTS list creation?
Hi,
I just wanted to check if there was anything further you needed to know in
order to create the debian-lts-{changes,announce} lists?
- Matt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747376: Requesting debian-lts-{changes,announce} mailing lists
On Thu, May 08, 2014 at 08:27:33AM +0200, Alexander Wirt wrote: > > Post policy: Moderated. Pre-approval should be allowed for whatever will be > > sending .changes files to the list (something in ftpmaster land; > > sorry I don't know any more about that). Initial moderators can be > > myself (mpal...@debian.org) and Moritz Muehlenhoff (j...@debian.org); > > we'll add more people as we get up to speed. > > Those changes lists are usually without any manual interaction. Unless > someone objects I would create this list similiar to the other -changes > lists. No, that's even better. I wasn't sure if we could do that, or if there had to be human moderators behind the scenes to deal with the "overflow", so I thought I'd supply as much info as possible. > > Post policy: Moderated. Pre-approval should be allowed for any message > > signed by a key in the Debian keyring. Initial moderators can be > > myself (mpal...@debian.org) and Moritz Muehlenhoff (j...@debian.org); > > we'll add more people as we get up to speed. > > Our moderation method currently allows either moderation via keyring (bi it > developers/dms or a custom keyring) or classic moderation, but not a > combination of both. I/we can implement such a combination, but that needs > testing and time. If you want this list soon, I would recommend to stick to > one of the traditional methods (Moderators or a keyring). Happy for it to be all-keyring, all-the-time. Then nobody has to spend time pointing-and-clicking away the spam. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740744: dns323-firmware-tools: Please migrate to Ruby 2.0/2.1
On Tue, Mar 04, 2014 at 05:02:31PM +0100, Christian Hofstaedtler wrote: > As per the Debian Ruby team bits, all versions of Ruby < 2.1 will be > removed from jessie. A month ago you told me to migrate to Ruby 1.9, now you're saying that isn't enough. Can you make up your mind, please? > Please test your package with Ruby 2.0 and 2.1, and then switch the Why do I need to test against 2.0 if you're removing everything earlier than 2.1? > Depends: line to read "ruby" instead of "ruby1.9.1". Is that going to break when you upgrade the "ruby" package to pull in Ruby 2.2, and my code isn't 2.2 compatible? Or has Ruby upstream finally decided that backwards-compatibility is a worthy goal? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702144: Dependency on rubygems blocks removal of Ruby 1.8
On Wed, May 22, 2013 at 12:16:38PM +0200, Laurent Bigonville wrote: > Le Wed, 22 May 2013 09:11:08 +1000, > Matt Palmer a écrit : > > > On Tue, May 21, 2013 at 01:35:55PM +0200, Laurent Bigonville wrote: > > > I'm not sure this is a good idea as long as both ruby 1.8 and 1.9.1 > > > are used. > > > > > > The user has the ability (using the alternatives) to switch between > > > 1.8 and 1.9.1. So that means that even if 1.9.1 is installed, the > > > user could still use 1.8 and the rubygems package might be missing. > > > > That's a possible issue. What if rubygems was a recommends? It'd > > still be pulled in normally by default, but it would at least not > > *block* removal of Ruby 1.8. Makes it rather difficult to do a sane > > dependency chain, though. > > Vagrant package is not the only package that has a hard dependency > against rubygems. I would say that the same solution should be applied > to all the other package as well. Quite possibly. > > What does Vagrant even use rubygems for directly? It seems odd that > > a tool to manage VMs would need to install gems itself. > > Rubygems is used to manage plugins that can be loaded in vagrant. I > didn't really investigate how difficult is was to disable this feature. That sounds like you don't *need* rubygems in order to, perform the essential use of the package (manage VMs) but only to enable certain optional features. I certainly don't recall vagrant ever installing gems anywhere on my behalf (if it stuck them somewhere out of the way, I'm yet to stumble across them). In that case, making rubygems a Recommends seems entirely appropriate. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#702144: Dependency on rubygems blocks removal of Ruby 1.8
On Tue, May 21, 2013 at 01:35:55PM +0200, Laurent Bigonville wrote: > I'm not sure this is a good idea as long as both ruby 1.8 and 1.9.1 are > used. > > The user has the ability (using the alternatives) to switch between > 1.8 and 1.9.1. So that means that even if 1.9.1 is installed, the user > could still use 1.8 and the rubygems package might be missing. That's a possible issue. What if rubygems was a recommends? It'd still be pulled in normally by default, but it would at least not *block* removal of Ruby 1.8. Makes it rather difficult to do a sane dependency chain, though. What does Vagrant even use rubygems for directly? It seems odd that a tool to manage VMs would need to install gems itself. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#701086: ledger: consider packaging a newer git snapshot
On Thu, Feb 21, 2013 at 08:23:30AM -0400, David Bremner wrote: > There have been 850 commits in git since the version packaged in > experimental. I don't know about the stability of the current > version, but I guess it is pretty difficult to get support upstream > for an 10 month old snapshot. >From the chatter on the mailing list, it seems like the git tree is kept relatively stable. Packaging a new snapshot probably wouldn't be particularly difficult. > If you point me to the packaging repository (and there is one), I'd be > willing to have a go at updating it. I'm from the old school; a .diff.gz was good enough for Ian Murdock, it's good enough for me! (Get offa mah lawn!) I'm not particularly active with ledger at the moment; if you'd like to move the packaging into git and switch to team maintenance between the two of us, I wouldn't object. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#693309: dns323-firmware-tools: Support more DNS-xxx devices
On Thu, Nov 15, 2012 at 11:56:56AM +, Jamie Lentin wrote: > I modified dns323-firmware-tools a while back to unpack and pack the firmware > for other DNS devices, as well as storing defaults for each device within > the scripts themselves. > > I've tested this by unpacking and repacking D-Link's firmware packages and get > a byte-for-byte identical file out the other end. > > If there aren't any objections, it'd be nice to get it merged into mainline. > I tried using the email address on the maintainer's website but got no > response. > > All the code is here:- > > https://github.com/lentinj/dns323-firmware-tools Yep, I got that, just haven't had an appropriate opportunity to respond and merge. Given that we're in freeze now, there isn't much of a rush to get this into Debian, but if you've got a pressing need to have an updated package, let me know and I'll put this higher in my todo list. - Matt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#606515: setting package to netcfg netcfg-static, tagging 606515
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # netcfg (1.60) UNRELEASED; urgency=low # # * Wait for link detection on static interface configuration. #Closes: #606515. # package netcfg netcfg-static tags 606515 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#414117: setting package to netcfg netcfg-static, tagging 414117
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # netcfg (1.60) UNRELEASED; urgency=low # # * Wait for up to 3 seconds (in 0.25s increments) looking for the link on #an interface. Add a progress bar to show the progress of this #operation. Closes: #414117. # package netcfg netcfg-static tags 414117 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#399071: setting package to netcfg netcfg-static, tagging 399071, tagging 496647
# Automatically generated email from bts, devscripts version 2.10.35lenny7 # via tagpending # # netcfg (1.60) UNRELEASED; urgency=low # # * Clarify the requirements for hostnames. Closes: #399071. # * Modify ethtool-lite so that it distinguishes between "ethtool failed" #and "ethtool says link is down". This should reduce link up/link down #confusion. Closes: #496647. # package netcfg netcfg-static tags 399071 + pending tags 496647 + pending -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#502821: Enhances oldsys-preseed patch for the DNS-323
A better patch, based on Martin Michlmayr's feedback, is attached. Enjoy!
- Matt
unchanged:
--- a/installer/build/pkg-lists/netboot/network-console/arm/orion5x.cfg
+++ b/installer/build/pkg-lists/netboot/network-console/arm/orion5x.cfg
@@ -7,6 +7,8 @@ ext2-modules-${kernel:Version}
ext3-modules-${kernel:Version}
# needed by oldsys-preseed on the Kurobox Pro
jffs2-modules-${kernel:Version}
+# needed by oldsys-preseed on the DNS-323
+minix-modules-${kernel:Version}
# To control the LED and beeper on QNAP devices
input-modules-${kernel:Version}
qcontrol-udeb
only in patch2:
unchanged:
--- b/packages/oldsys-preseed/functions
+++ b/packages/oldsys-preseed/functions
@@ -104,6 +104,15 @@
echo "$1" | grep "^$2=" | sed "s/^$2=//"
}
+# Get the value from a string in the form of var = "value" from a file.
+# Named for the sib.conf file on the DNS-323 that this function was
+# originally written for.
+# $1 = file to read
+# $2 = var to read
+get_sib_var() {
+ grep "^$2[[:space:]]*=" $1 |sed "s/^$2[[:space:]]*=[[:space:]]*\"\(.*\)\"[[:space:]]*$/\1/"
+}
+
# Add a string to a variable; deals with the fact when a string is empty
# $1 = variable name
# $2 = string
@@ -143,6 +152,19 @@
DOMAIN=$(get_var "$sysconf" "domain_name")
}
+# Parse the sib.conf file, as found in the Dlink DNS-323
+# $1 = path to sib.conf
+parse_sib_conf() {
+ if [ "$(get_sib_var "$1" "CF-IP-DHCP-ENABLE")" = "0" ]; then
+ NET_CONFIG="static"
+ fi
+ IPADDRESS="$(get_sib_var "$1" "CF-IP-STATIC-IP")"
+ NETMASK="$(get_sib_var "$1" "CF-IP-STATIC-IP-NETMASK")"
+ GATEWAY="$(get_sib_var "$1" "CF-IP-STATIC-IP-GATEWAY")"
+ var_add NAMESERVERS "$(get_sib_var "$1" "CF-IP-DNS1")"
+ var_add NAMESERVERS "$(get_sib_var "$1" "CF-IP-DNS2")"
+ HOSTNAME="$(get_sib_var "$1" "CF-SYS-MODEL-STR")"
+}
# Generating
only in patch2:
unchanged:
--- b/packages/oldsys-preseed/oldsys-preseed
+++ b/packages/oldsys-preseed/oldsys-preseed
@@ -231,6 +231,27 @@
fi
umount $path/sda1 || true
rmdir $path/sda1 $path || true
+ elif echo "$machine" | grep -q "^D-Link DNS-323"; then
+ check_file /proc/mtd
+ rootfs=$(get_mtdblock "MTD1")
+ if [ -z "$rootfs" ]; then
+log "Can't find rootfs MTD partition"
+exit 0
+ fi
+
+ INTERFACE="eth0"
+ path=/tmp/oldsys-preseed
+ mkdir -p $path/rootfs
+ mount -t minix -o ro /dev/$rootfs $path/rootfs
+ parse_sib_conf "$path/rootfs/sib.conf"
+ umount $path/rootfs
+ sanity_check_static_config
+ if [ "$NET_CONFIG" != "static" ]; then
+IPADDRESS=192.168.0.32
+NETMASK=255.255.255.0
+GATEWAY=192.168.0.1
+[ -z "$NAMESERVERS" ] && NAMESERVERS=192.168.0.1
+ fi
else
exit_unknown
fi
only in patch2:
unchanged:
--- /dev/null
+++ b/packages/oldsys-preseed/tests/arm/dns323-static.preseed
@@ -0,0 +1,8 @@
+d-i netcfg/choose_interface select eth0
+d-i netcfg/get_ipaddress string 192.168.0.2
+d-i netcfg/get_netmask string 255.255.255.0
+d-i netcfg/get_gateway string 192.168.0.254
+d-i netcfg/get_nameservers string 192.168.0.254 192.168.0.255
+d-i netcfg/confirm_static boolean true
+d-i netcfg/disable_dhcp boolean true
+d-i netcfg/get_hostname string home
only in patch2:
unchanged:
--- /dev/null
+++ b/packages/oldsys-preseed/tests/arm/dns323-static.test
@@ -0,0 +1,5 @@
+INTERFACE=eth0
+parse_sib_conf $TEST_DIR/dns323_sib.conf
+sanity_check_static_config
+generate_preseed_file "$1"
+
only in patch2:
unchanged:
--- /dev/null
+++ b/packages/oldsys-preseed/tests/arm/dns323-dhcp.preseed
@@ -0,0 +1,3 @@
+d-i netcfg/choose_interface select eth0
+d-i netcfg/use_dhcp boolean true
+d-i netcfg/get_hostname string home
only in patch2:
unchanged:
--- /dev/null
+++ b/packages/oldsys-preseed/tests/arm/dns323-dhcp.test
@@ -0,0 +1,4 @@
+INTERFACE=eth0
+parse_sib_conf $TEST_DIR/dns323_dhcp_sib.conf
+sanity_check_static_config
+generate_preseed_file "$1"
only in patch2:
unchanged:
--- /dev/null
+++ b/packages/oldsys-preseed/tests/arm/dns323-dhcp_sib.conf
@@ -0,0 +1,29 @@
+CF-SYS-MODEL-STR = "home"
+CF-WEB-IDLE-TIME = "5"
+CF-IP-DHCP-ENABLE = "1"
+CF-IP-STATIC-IP = "192.168.0.2"
+CF-IP-STATIC-IP-NETMASK = "255.255.255.0"
+CF-IP-STATIC-IP-GATEWAY = "192.168.0.254"
+CF-IP-DNS1 = "192.168.0.254"
+CF-IP-DNS2 = "192.168.0.255"
+CF-TIMEZONE = "8"
+CF-METHOD = "2"
+CF-WEB-USER-IDLE = "5"
+CF-TIMESERVER = "216.200.93.8"
+CF-WL-WIRELESS = "0"
+CF-WL-COMM-MODE = "0"
+CF-WL-SSID = ""
+CF-WL-CHANNEL = ""
+CF-WL-AUTH = "1"
+CF-WL-SECURITY-MODE = "1"
+CF-WL-ENCRYPTION-MODE = "1"
+CF-WL-KEY-FORMATE = "1"
+CF-WL-DEFAULT-KEY = "1"
+CF-WL-KEY-VALUE-1 = ""
+CF-WL-KEY-VALUE-2 = ""
+CF-WL-KEY-VALUE-3 = ""
+CF-WL-KEY-VALUE-4 = ""
+CF-WL-PSK = ""
+CF-WL-MACADDRESS = ""
+CF-WL-SIGNAL = ""
+CF-WL-CONNECT = "1"
only in patch2:
unchanged:
--- /dev/null
+++ b/packages/oldsys-preseed/tests/arm/dns323-static_sib.conf
@@ -0,0 +1,29 @@
+CF-SYS-MODEL-STR = "home"
+CF-WEB-IDLE-TIME = "5"
+CF-IP-DHCP-ENABLE = "0"
+CF-IP-STATIC-IP = "192.168.0.2"
+CF-IP-STATIC-IP-NETMASK = "255.255.255.0"
+CF-IP-STATIC-IP-G
Bug#498284: puppet: initscript ignore /etc/default/puppet
On Fri, Oct 24, 2008 at 10:59:15AM +0100, Adrian Bridgett wrote: > Another reason for obeying START is when you do an update of puppet > package. If it doesn't obey START it will run puppet and possibly > apply a bunch of changes to a server. I'm paranoid and on production > systems _always_ run puppet in --noop mode before running live. invoke-rc.d takes care of this situation. If puppet isn't using this mechanism, then that's a bug. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441775: certification fails
merge 441775 440346 thanks On Tue, Sep 11, 2007 at 02:28:57PM +0900, Jun Nishikawa wrote: > Package: puppet > Version: 0.23.2-3 > Severity: important > > Looks like certification is failing. > "puppetca --list" does not return hostname and cannot sign either. I'm going to take a wild stab and guess that the change of $ssldir has bitten you. 0.23.2-3 moved /etc/puppet/ssl to /var/lib/puppet/ssl and changed the default config parameter for ssldir on all services to that directory. Most likely, what you'll need to do is take any parameters you've custom set in the deprecated config files (puppetd.conf, puppetmasterd.conf, puppetca.conf, etc), move them into puppet.conf (in the appropriate section, if necessary) and then delete the deprecated config files. Once you do that, your certificates will most likely verify again and all will be well. Then you can just delete the (bogus) /etc/puppet/ssl. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
