Bug#610600: Update package sudo-ldap lenny->squeeze: sudoers record is not added to /etc/nsswitch.conf
reassign 610600 base-files thanks On Thu, 10 Feb 2011 20:37:44 +0100, Ulrich Zehl wrote: > Unconditionally adding a line to nsswitch.conf via the base-files package > will work, because the non-LDAP sudo does not read it in any case. Ok, thanks for commenting on this. I'll reassign this to the base-files package for action. If the maintainer(s) agree to add the entry in question, then I'll be happy to update future sudo-ldap packages to depend on a suitably fresh version of base-files. That won't directly help folks updating from lenny to squeeze right now, but if we can get updates to both packages into the first squeeze point release, it might still help a lot of people... Bdale pgptmD2WmfECQ.pgp Description: PGP signature
Bug#605576: sudo: doesn't use debconf for prompting
On Wed, 1 Dec 2010 14:37:13 +0100, Jakub Wilk wrote:
> This postinst snippet:
>
> constitutes a violation of Policy 3.9.1 ("Package maintainer scripts may
> prompt the user if necessary. Prompting must be done by communicating
> through a program, such as `debconf', which conforms to the Debian
> Configuration Management Specification, version 2 or higher.").
I've considered this before. This snippet should never fire unless
there's something very unusual about the user's system. Adding debconf
to the list of sudo dependencies just to handle this "virtually never"
sanity check really doesn't make sense to me.
If push comes to shove and pedantic adherence to this element of policy
is required, I'll probably just abandon this test in the postinst
entirely rather than add debconf support.
Bdale
pgpfGT5BJmpwK.pgp
Description: PGP signature
Bug#605580: sudo: support for noopt, nostrip
tags 605580 +fixed thanks On Wed, 1 Dec 2010 15:13:13 +0100, Jakub Wilk wrote: > The attached patch makes sudo's debian/rules respect the noopt and > nostrip build options. Thanks for the patch. Merged in my git repo for my next upload. Bdale pgpUGZ0qboKq0.pgp Description: PGP signature
Bug#605130: sudo: unowned files after purge (policy 6.8)
On Sat, 27 Nov 2010 22:58:14 +0100, Holger Levsen wrote: > Or wait, I wont. Removed control@ from to: on purpose, see below > > > I'm open to interesting suggestions (particularly if they come with > > working patches), but the current situation was the best I could come up > > with the last time I reviewed the alternatives. > > The use case you described will continue to work: if you have sudo installed > and install sudo-ldap, /etc/sudoers can be handled like it has been handled. > > But in the case of purge, I think /etc/sudoers should be removed, as this is > what purge is supposed to do. After thinking about this some more, the real problem is just that sudoers was not treated as a conffile. The big thing that's changed since the last time I considered making it one is that we now include support for local config fragments in /etc/sudoers.d, such that it really should be possible for /etc/sudoers to be unmodified on most systems. Thus, moving it to being a normal conffile now makes sense to me. I'll make the change for the next upload. Bdale pgppmsmXCcCpp.pgp Description: PGP signature
Bug#587886: my vote
I vote B, A, SQ. Bdale pgpvhzJuPo4cr.pgp Description: PGP signature
Bug#509585: nah
This kind of new user expanded verbosity seems better implemented somwhere like in the shell so that it applies to all commands, not just to those run through sudo. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#377136: reverted
Justin, this was indeed fixed as part of the response to #388659, but then reverted because the problem stated earlier in the thread, that /usr/bin/vi is not guaranteed to be present. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602699: closed by Bdale Garbee (Bug#602699: fixed in sudo 1.7.4p4-5)
On Fri, 03 Dec 2010 18:05:30 +0100, Alexander Kurtz wrote: > I think this is a security problem. Or am I missing something here? Why do you think this is a security issue? If you put someone in group sudo, you're giving them the keys to the kingdom. Changing the primary group with sudo -g doesn't *limit* the set of groups a member belongs to, it just changes what the primary group is for the duration of the command. So this just seems like normal and expected behavior to me. Bdale pgpHt7DiOcXc3.pgp Description: PGP signature
Bug#552390: /usr/sbin/amstatus: Still present in squeeze @ 2010-12-04
On Sat, 04 Dec 2010 01:19:29 -0500, Daniel Dickinson wrote: > The updated version hasn't made it to squeeze so this bug remains open > there. Yep, looks like I uploaded v3 bits to unstable too quickly, so the p2-2 upload never had time to get into testing. Will see what I can do about that. Bdale pgp5LG9t7WGKM.pgp Description: PGP signature
Bug#603371: Please Reassign to Package tar
tags 603371 +upstream +sid thanks On Sun, 14 Nov 2010 13:59:30 -0600, Martin Gallant wrote: > The bug still exists in the latest version 1.25-2. It appears to be known by tar upstream that you can't use --one-file-system and --listed-incremental together, which is what amanda is trying to do. http://www.mail-archive.com/bug-...@gnu.org/msg02994.html I personally use dump and not tar with amanda, so haven't seen the problem. Since the version of tar in squeeze is ok, a reasonable workaround is to downgrade to that version of tar until upstream resolves the problem. Bdale pgpgGSVUL6qNq.pgp Description: PGP signature
Bug#602241: tar: FTBFS on kfreebsd-*: 38: extract over symlinks FAILED
tags 602241 +help thanks On Tue, 02 Nov 2010 21:31:48 +0100, Cyril Brulebois wrote: > your package no longer builds on kfreebsd-*: > | 38: extract over symlinks FAILED (extrac13.at:27) Any idea what's different about a kfreebsd system that might cause this to fail? Bdale pgp4Mr5LuoJjN.pgp Description: PGP signature
Bug#606176: /usr/bin/openrocket wrapper does not pass arguments
On Tue, 07 Dec 2010 14:47:00 +1000, Anthony Towns wrote: tags 606176 +pending thanks > Running "openrocket blah.ork" doesn't work, but it does if you change > the wrapper script: Thanks, in my git for the next upload. Bdale pgp9ILkuwGksE.pgp Description: PGP signature
Bug#587558: gnuradio: Needs to be rebuilt as python 2.6 is now default
On Wed, 8 Dec 2010 14:10:26 -0500, "Pascal Giard, ing. jr, M.Ing." wrote: > any news on the matter? I've done some more work on it, but I'm currently heads-down working on something else and am not sure when I'll get a new set of packages uploaded. I personally consider all of the gnuradio bits currently in the archive worthless. If they're blocking a transition or something, I'll be happy to request their removal until/unless I can get a new upload done? Bdale pgpXwQ5eUuuC8.pgp Description: PGP signature
Bug#532123: recommends vs depends
I just had to chase this down on one of my servers. The fact that the recommends on geoip-database is indirect meant extra steps to investigate and fix the problem. So, the problem with not fixing this bug is that it breaks existing webalizer installations on upgrade to squeeze. FWIW, that makes this 'normal' and not 'wishlist' in my mind. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#532123: recommends vs depends
On Mon, 28 Mar 2011 23:59:54 +0200, Julien Viard de Galbert wrote: > I see your point, so a direct recommends on geoip-database will give > less steps to fixing the issue, however, a depends would install > geoip-database even for users not enabling the geoip feature... and I > still think thats just wrong. > > Do you think it's OK if I just add the recommends ? Probably. Is the geoip feature disabled by default on new installs? I honestly don't remember what it used to be, since my installation of webalizer was by no means recent! Bdale pgpYT0cxGb7xF.pgp Description: PGP signature
Bug#614268: [patch] add --return option to cowpoke
Package: devscripts
Version: 2.10.71
Severity: wishlist
The attached patch adds a --return option to cowpoke, that causes any
.deb and .changes files resulting from a build to be returned to the
current directory on completion of the build.
Note that to handle the case where multiple .deb files result from the
build of one .dsc, I've chosen to use patterns that looks like:
*package_version*deb
*package_version*changes
It is theoretically possible that this could return more results than
desired if multiple packages have been built with identical version
strings, but the only alternative would seem to be parsing the control
file in the package source to obtain a definitive list of binary package
names to look for, and that seems unnecessarily complicated.
Bdale
pgpXLXmLCDAfL.pgp
Description: PGP signature
>From ea818a01d2a0a9abd145ae2fed114db9955493ec Mon Sep 17 00:00:00 2001
From: Bdale Garbee
Date: Sun, 20 Feb 2011 11:33:07 -0700
Subject: [PATCH] add a new --return option that pulls build results to current directory
---
cowpoke.conf |3 +++
scripts/cowpoke.1 |5 +
scripts/cowpoke.sh | 22 ++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/cowpoke.conf b/cowpoke.conf
index 7a80a7f..18e203d 100644
--- a/cowpoke.conf
+++ b/cowpoke.conf
@@ -56,6 +56,9 @@ BUILDD_HOST=
# debootstrap or cdebootstrap.
#DEBOOTSTRAP="cdebootstrap"
+# If set to "yes", the .deb and .changes files resulting from the build
+# will be returned to the current directory after the build completes.
+#RETURNRESULTS="no"
# =
#
diff --git a/scripts/cowpoke.1 b/scripts/cowpoke.1
index c149d4f..eb3449e 100644
--- a/scripts/cowpoke.1
+++ b/scripts/cowpoke.1
@@ -60,6 +60,11 @@ is not passed it is an error for the specified \fB\-\-dist\fP or \fB\-\-arch\fP
to not have an existing cowbuilder root in the expected location.
.TP
+.B \-\-return
+Return the .deb and .changes files resulting from the build to the current
+directory after the build completes.
+
+.TP
.BI \-\-dpkg\-opts= "'opt1 opt2 ...'"
Specify additional options to be passed to \fBdpkg-buildpackage\fP(1). Multiple
options are delimited with spaces. This will override any options specified in
diff --git a/scripts/cowpoke.sh b/scripts/cowpoke.sh
index 60a81ac..00d5a02 100755
--- a/scripts/cowpoke.sh
+++ b/scripts/cowpoke.sh
@@ -80,6 +80,7 @@ cowpoke [options] package.dsc
--buildd="host" Specify the remote host to build on.
--buildd-user="name" Specify the remote user to build as.
--create Create the remote cowbuilder root if necessary.
+ --return Return results of the build to current directory.
The current default configuration is:
@@ -130,6 +131,10 @@ for arg; do
CREATE_COW="yes"
;;
+ --return)
+ RETURNRESULTS="yes"
+ ;;
+
--dpkg-opts=*)
DEBBUILDOPTS="--debbuildopts \"${arg#*=}\""
;;
@@ -311,6 +316,23 @@ ssh -t "$BUILDD_USER$BUILDD_HOST" "\"$INCOMING_DIR/$REMOTE_SCRIPT\" && rm -f \"$
echo
echo "Build completed."
+if [ "$RETURNRESULTS" = "yes" ]; then
+for arch in $BUILDD_ARCH; do
+ for dist in $BUILDD_DIST; do
+
+ RESULT_DIR="$(eval echo "\$${arch}_${dist}_RESULT_DIR")"
+ [ -n "$RESULT_DIR" ] || RESULT_DIR="$PBUILDER_BASE/$arch/$dist/result"
+ RESULTVER="$(eval echo $DSC | cut -d '_' -f 2 | sed -e 's/.dsc//')"
+ RESULTS="$(eval ssh "$BUILDD_USER$BUILDD_HOST" "ls $RESULT_DIR/*$RESULTVER*deb $RESULT_DIR/*$RESULTVER*changes")"
+
+ for result in $RESULTS; do
+ dcmd scp "$BUILDD_USER$BUILDD_HOST:$result" .
+done
+
+ done
+done
+fi
+
if [ -n "$SIGN_KEYID" ]; then
for arch in $BUILDD_ARCH; do
CHANGES="$arch.changes"
--
1.7.4.1
Bug#614232: sudo: Please backport $HOME fix in 1.7.4p4-4 to squeeze
On Wed, 23 Feb 2011 10:40:58 +0100, Philipp Kern wrote: > I don't see a prior discussion before upload on debian-release@. Did I miss > something? No. > The diff's a pain to review due to source v3[0]. As there's a patch series, > why isn't it used? I guess I'm just not that consistent about handling patches. If it's easier, feel free to look it over in my repo at git.gag.com. It's a single commit on the squeeze branch of the debian/sudo project. Bdale pgpE71ZA2QRDs.pgp Description: PGP signature
Bug#590023: NMU diff for elilo 3.12-3.1
On Fri, 30 Jul 2010 23:00:15 +0100, Ben Hutchings wrote: > I have uploaded the follow changes to delayed/7. Thanks. I may or may not convert this to a maintainer upload once I arrive at Debconf, but appreciate the help in either case! Bdale pgpT95YUHhfB1.pgp Description: PGP signature
Bug#292774: alternatives support for tar
tags +292774 wontfix thanks On Thu, 05 Aug 2010 13:20:42 +0200, Witold Baryluk wrote: > i would also like to have this possiblity, > to use bsdtar as tar provider. Currently > it is impossible to use it by bsdtar, becuase > tar should in first place provide alternative to tar. It's much more complicated than you suggest. First, because tar is 'essential' and 'required' in our packaging system, there are no dependency assertions present in other packages that need a working tar. This makes it hard to know what requirements exist, and to understand whether some other version of tar can really substitute for GNU tar. Since GNU tar has been "tar" for the entire history of Debian, it seems entirely possible and likely that some packages depend on features / command line options / etc of this version of tar that are not supported by alternatives like bsdtar. Second, dpkg has a known strong dependency on tar. That means that if anything in the system 'breaks' tar, it will be very hard for an average user to fix the problem... because they won't be able to install or upgrade packages. To me, this means that adding additional dependencies or package management complexity to tar is something we must consider *very* carefully. In summary, adding /etc/alternatives support to tar is the least of my concerns about making this change. A thorough analysis of the rest of the issues must be undertaken before we can begin to consider this request. Marking this bug 'wontfix' for now, since I currently have no motivation to engage in such an analysis. Bdale pgpcbydBYxwGC.pgp Description: PGP signature
Bug#591812: lintian test for menu icon type is out of date
Package: lintian While the packaging manual section 3.7 suggests that Debian menu requires an xpm format icon, that is not actually true. In all cases I've tried, a png is just fine too. Several packages now deliver png icons that work fine with both desktop and menu files. Currently, lintian emits the error: E: openrocket: menu-icon-not-in-xpm-format when it finds a non-xpm icon file. This seems inappropriate given that png files actually seem to work fine. Please consider downgrading this to a warning, or updating the set of file types to include png. Obviously, the packaging manual should also be updated, but I'm not sure offhand where responsibility for that lies. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591939: python-gnuradio: not installable in sid on any architecture - upgrade to newer libboost needed?
On Fri, 6 Aug 2010 18:13:17 +0200, Ralf Treinen wrote: > The common reason on all architectures seems to be > that it depends (indirectly) on libboost-thread1.40.0 which only lives > in testing but not in unstable. I guess that this dependency should be > upgraded to libboost-python1.42.0. Still working a regression suite problem with gnuradio upstream. Once that's resolved, a new upload should fix this and several related problems. Bdale pgpG7aqIPVapC.pgp Description: PGP signature
Bug#552390: amanda-common should (build) depend on procps
On Sat, 10 Apr 2010 22:03:23 +0200, Arnold Metselaar wrote: > When amanda-common is built on a system with procps installed autoconf > does the right thing with the variable $PS in Constants.pm: Aha! Thanks for chasing this down. Build dep added in my git repo for the next upload. Bdale pgp4gDY6cWvFb.pgp Description: PGP signature
Bug#523499: Ubuntu
tags 523499 +pending thanks On Sun, 24 Jan 2010 23:09:13 +0100, Philip Muskovac wrote: > This bug was also reported on Launchpad against Ubuntu today: The changes are now in my git repo waiting for the next upload. Updating the Debian BTS to reflect that. Bdale pgphrUZSyDxVt.pgp Description: PGP signature
Bug#582057: sudo: Segmentation fault with invalid UID
fixed 582057 1.7.2p6-1 thanks On Tue, 18 May 2010 00:32:52 +0200, Moritz Naumann wrote: > Package: sudo > Version: 1.6.9p17-2+lenny1 > Severity: important > > When invoking sudo with -u, passing an invalid (or valid but not > matching/existing) UID value, it segfaults. > > r...@pepper:~# sudo -u \#-1 > Segmentation fault > r...@pepper:~# For what it's worth, this does not happen with the much-newer sudo version 1.7.2p6-1 that is in unstable and testing. > Please ensure this is not a security issue. This version is not one that I uploaded, it was apparently built and uploaded by Giuseppe Iuculano on behalf of the security team in March of this year. Adding him to the CC list to see if there's any interest in chasing this further. Bdale pgpAgQr0Pcgjs.pgp Description: PGP signature
Bug#582486: gnuradio: Is it neccessary to conflict with python-wxgtk2.6 ?
tags 582486 +pending thanks On Fri, 21 May 2010 09:54:15 +0200, Christian Meyer wrote: > Is it neccessary to conflict with python-wxgtk2.6 when python-wxgtk2.8 is > required anyway? To be honest, I don't recall why the conflicts got added. I'll remove it on the next upload. Bdale pgpQNXALKS0vd.pgp Description: PGP signature
Bug#582706: tar: Please us xz/unxz instead of lzma
On Sun, 23 May 2010 00:36:10 +0200, Bill Allombert wrote: > at this stage xz-utils is priority: required while lzma is deprecated. > so tar should use unxz to decompress lzma archives. It looks like I can just use the configure option --with-lzma=xz. Since lzma upstream appears to recommend that everyone switch to xz, that seems like a reasonable solution. Do you agree? Bdale pgpO5yORycno3.pgp Description: PGP signature
Bug#582706: tar: Please us xz/unxz instead of lzma
On Sun, 23 May 2010 16:52:54 +0200, Bill Allombert wrote: > On the other hand this would fix 523494 (and you can remove the > Suggests: on lzma as well). Ugh. I guess I missed 523494 when I closed 523499 on the 1.23-1 upload. I'm not sure what the point of duplicating that bug was, but no matter. Thanks for pointing that one out... Bdale pgpGfMYJIt0qB.pgp Description: PGP signature
Bug#573108: Clarify what "ldap support" means.
tags 573108 +pending thanks On Tue, 09 Mar 2010 11:37:11 +1100, "Trent W. Buck" wrote: > a description like ... will help me remember why this package exists. Good point! Since I don't personally admin anything LDAP-related, I have at best a weak understanding of it myself... ;-) I'll update the description on my next upload. Bdale pgpBEwBj60Uay.pgp Description: PGP signature
Bug#565552: sudo: double free or corruption
On Sat, 16 Jan 2010 22:23:32 +0100 (CET), Cristian Ionescu-Idbohrn wrote: > | # sudo -i > | sudo: /etc/sudoers.d/local is mode 0644, should be 0440 > | >>> /etc/sudoers.d/README: /etc/sudoers.d/local near line 18 <<< > | sudo: parse error in /etc/sudoers.d/README near line 18 > | sudo: no valid sudoers sources found, quitting > | *** glibc detected *** sudo: double free or corruption (!prev): > | 0x081f2b00 *** I can't reproduce the glibc error, but you are correct that having a file in /etc/sudoers.d with too-open permissions "breaks" sudo in that it will report the error and not run the requested command. I'll forward that part of your bug report upstream for consideration. In the meantime, the workaround is clearly to be very careful about permissions on the files in /etc/sudoders.d ... Bdale pgpT1nG3bYH5K.pgp Description: PGP signature
Bug#573745: Please decide on Python interpreter packages maintainership
On Sat, 13 Mar 2010 17:24:51 +0100, Sandro Tosi wrote: > Package: tech-ctte > Severity: normal > > Hello Technical Committee, > we'd like you to decide about how the Python interpreter packages > should be maintained in Debian. Thank you for bringing this to the Committee's attention. However, I was a little surprised to see this filed without a CC to the current package maintainer. It seems our next step should be to invite him to comment on the issues raised from his perspective. Matthias? Bdale pgpZqy8ONrJN7.pgp Description: PGP signature
Bug#552390: can't reproduce
tags 552390 +moreinfo +unreproducible thanks I can't reproduce this error, so I'm not sure what to do about it. Do you have any other information to offer? Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#581393: Processed: reopen 581393
On Wed, 12 May 2010 23:21:13 +, ow...@bugs.debian.org (Debian Bug Tracking System) wrote: > > reopen 581393 You assert that there is a policy violation where there is none, and I've already explained how you can achieve a trivial resolution of the behavior that bothers you with the existing packages. Re-opening this bug without providing some further explanation of what you think sudo should do differently will generate no useful result. Bdale pgpa83KF3VPvM.pgp Description: PGP signature
Bug#581393: Processed: reopen 581393
On Thu, 13 May 2010 04:28:27 +0400, sergio wrote: > On 05/13/2010 04:05 AM, Bdale Garbee wrote: > > > You assert that there is a policy violation where there is none, and > > I've already explained how you can achieve a trivial resolution of the > > behavior that bothers you with the existing packages. > > In the Debian policy I see: > /var/run and /var/lock may be mounted as temporary filesystems[59], so > the init.d scripts must handle this correctly. > > "... _must_ handle ..." > > And sudo doesn't handle this correctly. So it's policy violation. > Where I'm wrong? Our difference of opinion is over whether showing the lecture every time is a failure or just an expected behavior when choosing to use RAMRUN. However, after re-reading the FHS sections on the various /var subdirs, I now believe that /var/lib may be a better location for the state information to reside in than /var/run. I'll raise this question with sudo upstream. Bdale pgpOCSz0vEwQI.pgp Description: PGP signature
Bug#581463: openrocket: bashism in debian/rules
On Thu, 13 May 2010 00:25:10 -0500, Raphael Geissert wrote: > This should work no matter whether bash or dash is used as /bin/sh: So icky ... But thanks, I get it now. Bdale pgprwGy5wsgdA.pgp Description: PGP signature
Bug#557050: grc and gnuradio-companion: error when trying to install together
On Fri, 14 May 2010 16:48:48 +0200, Julien Cristau wrote: > Conflicts are not meant for this. Debian policy says no two programs > with the same filename and different functionality are allowed, and the > only possible resolutions are to rename one or both of the programs. Wow. I don't recall policy section 10.1 at all, and I'm not at all sure that I think this makes the world a better place. But, you are correct in your assertion that policy demands this class of conflict be resolved. Johnathan, was there negativity to the change or just a lack of concern about the issue because we though Conflicts would take care of it? Seems to me that making the change is the right solution. Of course, we need to figure out why I'm still getting two failures in the test suite building against current Debian unstable pasted below before I will be able to upload a new version regardless of what we decide on this issue. Any thoughts? Bdale 1) test: qa_gr_fir_fff::t2 (F) line: 190 qa_gr_fir_fff.cc double equality assertion failed - Expected: -322997024 - Actual : nan - Delta : 2906973.216 2) test: qa_gri_mmse_fir_interpolator::t1 (F) line: 57 qa_gri_mmse_fir_interpola tor.cc double equality assertion failed - Expected: 0.192101076245308 - Actual : nan - Delta : 0.004 pgpypQW4xnNeE.pgp Description: PGP signature
Bug#556562: fixed
On Fri, 14 May 2010 12:05:41 -0400, Erik Lattimore wrote: > > This bug is related to #565223, which is fixed upstream or there is a > patch included in the ticket. Thanks for pointing this out. Bdale pgpTpioOYfOgs.pgp Description: PGP signature
Bug#573745: Please decide on Python interpreter packages maintainership
On Sat, 13 Mar 2010 17:24:51 +0100, Sandro Tosi wrote: > Package: tech-ctte > Severity: normal > > Hello Technical Committee, > we'd like you to decide about how the Python interpreter packages > should be maintained in Debian. I've spent several hours since my last message communicating with the current Python maintainer, reading various mailing list threads and bug logs, and generally trying to understand the situation as best I can. It bothers me that what you've brought to the TC is a rant about your frustrations culminating in a request to remove someone else from their role, rather than a crisper articulation of what's wrong and a plan that explains how we should move forward. In my reading and discussion with others, there are hints about different agreements at different times between different people about how to handle various transitions, but as someone not party to the various discussions over time, I wish I could find a single, well articulated policy for Python in Debian. There are more people I want to talk to, and perhaps one or more of them will make everything clear to me... but I do not want to delay things further. I realize this may not be what you had in mind when you asked the TC to "decide about how the Python interpreter packages should be maintained in Debian", but now that you've opened Pandora's box, I believe we have a responsibility to understand the underlying problems that apparently have plagued Python policy for years, so that whatever decision we take will ensure the most positive outcome for Python handling in Debian in the future. I'm adding the DPL to this reply because it seems possible that the only way to achieve this objective might be an in-person Debian Python Summit meeting, moderated by members of the TC, where we can work through all the issues and come to consensus. Perhaps we can resolve our problems by email and/or IRC, but the mere existence of this petition to the TC and what it implies about communication disconnects makes me doubt that. Before I'll be willing to support any Technical Committee action on this petition, I believe we need a detailed and competent plan articulated, that explains how we get from where we are today to a single policy for Python in Debian, and that covers at least: 1) our philosophy for handling multiple Python interpreter versions 2) the supported approach(es) to packaging Python modules 3) an analysis of the effort involved and who needs to do what 4) a tentative schedule of milestones to completion, including what can and should be done before squeeze freeze 5) explicit commitment by involved parties to do the required work > transitions to force some controversial, unrelated technical > changes to be implemented before these transitions happen. I think this is a key part of the problem. The Python maintainer does not seem to believe that these are unrelated technical issues. And the controversy that does exist seems now to be more fueled by a combination of emotion and inertia than technical concerns. We need to get past that, and focus our attentions squarely on a good Python technical policy and associated implementation plan. I think everything else will flow fairly easily if we can accomplish that. Bdale pgpxycmAOPu0n.pgp Description: PGP signature
Bug#574404: sudo: postinst uses prompting
On Wed, 17 Mar 2010 23:57:09 +0100, Jean-Christophe Dubacq wrote: Thanks for the questions on IRC yesterday, and for this but report. After some sleep and re-reading some of my changelog entries, this isn't quite as simple as it seemed yesterday. > * I do not understand why /etc/sudoers is not simply a conffile, >especially now that /etc/sudoers.d is supported. History and inertia, mostly. The current processing actually pre-dates clean conffile handling by dpkg, and largely pre-dates my taking over the sudo package from Michael Meskes in 1996. The one reason I can remember this morning to not just replace the current handling without further thought is that removing sudoers on purge can cause problems for people moving systems between sudo and sudo-ldap. Leaving the sudoers file in place on a purge was deemed the least evil choice the last time I reviewed this functionality in April of 2007 in response to #401366. > * the stanza with update-rc.d looks like it will not change anything In most cases, it won't. The code is there because a very old version of sudo created an inappropriate set of links for the startup script fragment. This stanza caused any lingering instances of that mess to be cleaned up. It has been enough years that we can probably remove that code with no penalty... but it certainly does no harm. Bdale pgpVBjVtLKab4.pgp Description: PGP signature
Bug#574404: sudo: postinst uses prompting
On Thu, 18 Mar 2010 21:22:25 +0100, Jean-Christophe Dubacq wrote: > And in fact, I think the best solution would be to do what some > databases do, and would correspond to what you aim to do with the other > files: namely, preventing losing root access for people using sudo as > sole root access. Ask a question with debconf about whether /etc/sudoers > should be deleted on purge, and if it is "yes", then delete. People > having a root password will gladly say it should be cleaned, and people > going to some length to have no root password will simply say no. > > But well, it is more work. Indeed, and adds a debconf dependency where none currently exists. I'll have to think about that. > In fact, what I meant is: "It won't do anything because the man page for > update-rc.d says: Oh, interesting. I'm inclined to believe that means the update-rc.d behavior has changed since I added that code (long ago), because I know it worked as expected "back then". This certainly makes it clear that it's time for that code to just go away... Thanks. Bdale pgp45unslRVgQ.pgp Description: PGP signature
Bug#574530: RM: littex; Lithuanian language support was added to TexLive 2009 (texlive-lang-lithuanian package) which makes littex obsolete.
On Fri, 19 Mar 2010 10:47:00 +0100, Alexander Reichle-Schmehl wrote: > > Texlive 2009 now supports Lithuanian language in a standard way > > (texlive-lang source package builds texlive-lang-lithuanian) so > > there is no need to use littex package. > > debian-history build-depends on littex, that needs to be resolved before > littext can be removed. I'll see if I can resolve the build dependency today. Bdale pgpNFd2V7PJRw.pgp Description: PGP signature
Bug#574530: RM: littex; Lithuanian language support was added to TexLive 2009 (texlive-lang-lithuanian package) which makes littex obsolete.
On Fri, 19 Mar 2010 10:47:00 +0100, Alexander Reichle-Schmehl wrote: > debian-history build-depends on littex, that needs to be resolved before > littext can be removed. I just uploaded debian-history 2.11 which no longer build depends on littex, so you are free to remove it now. Bdale pgpVSaQJmSCIb.pgp Description: PGP signature
Bug#575016: newer version upstream
Package: libjcommon-java Version: 1.0.10.dfsg-1 Severity: wishlist I'm packaging openrocket, which includes a copy of jcommon-1.0.16 in its source tree. When do you expect to upload a fresher version of the standalone package? Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575151: openrocket: Crash at startup
tags 575151 +pending thanks On Tue, 23 Mar 2010 21:57:35 +0100, j...@multani.info wrote: > Package: openrocket > Version: 1.0.0-1 > Severity: important > > After installing and running for the first time openrocket, I got the > following traceback on the console: Oops. It looks like some of the run-time dependencies aren't properly captured in the package. I had that right at one point, must have lost them when I rolled back some unrelated changes. I'll fix that in a -2 upload ASAP. In the meantime, installing the missing libraries should solve the problem: apt-get install libjcommon-java libjfreechart-java libmiglayout-java Sorry! Bdale pgpsrUiC7hVvi.pgp Description: PGP signature
Bug#575211: sudo crashes about wrong access permissions of private sudoers file
On Wed, 24 Mar 2010 10:34:48 +0100, Harald Dunkel wrote: > Package: sudo > Version: 1.7.2p1-1.2 > > I have installed a private sudoers file /etc/sudoers.d/tom. > Sudo did not like the access permissions, and crashed. > There was no crash after fixing the permissions as suggested. I can't reproduce the problem on my machine which is running 1.7.2p5-1 From unstable. Could you try with this version and let me know if you still see the problem? It should throw an error message but *not* exhibit the double free failure you see here. Bdale pgpIOMcLmJa78.pgp Description: PGP signature
Bug#578601: wildcards in /etc/sudoers are not working after update
On Wed, 21 Apr 2010 09:07:30 +0200, Ralf Gross wrote: > Package: sudo > Version: 1.6.9p17-2+lenny1 Where did you get this version? It's not one of mine. It's possible that one of the fixes for priv escalation holes found in those older versions of sudo might be causing the problem. I'd love to know if 1.7.2p6-1 which I uploaded to unstable yesterday works for you or not, it should back-port to lenny ok, but I haven't tried. Bdale pgpyEuBs3wOIz.pgp Description: PGP signature
Bug#578601: wildcards in /etc/sudoers are not working after update
On Wed, 21 Apr 2010 17:11:40 +0200, Ralf Gross wrote: > Hm, this version is not available on out local mirror yet. Instead I tried > 1.7.2p5-1 from sid, which could be installed without problem on lenny. > > The problem seems to be solved with this version: Cool! > What does this mean for the lenny version of sudo? It certainly seems that there's a bug in the version in question. Bdale pgpX8PU8YvBUd.pgp Description: PGP signature
Bug#562945: Bug#582755: Bug#562945: fails to install
On Fri, 18 Jun 2010 11:38:11 -0700, Steve Langasek wrote: > Personally, I don't think runit-run's behavior here is what's intended to be > allowed under Policy. I agree. The current behavior in the case where the question is answered "yes" seems completely inadequate, and the mere presence of the question strikes me as an acknowledgement of that fact by the maintainer! > In summary, my proposal would be to: > > - decline to override the runit-run maintainer, whose use of debconf is >discouraged but /not/ forbidden by Policy > - advise the Policy maintainers to proceed with the existing proposed >language regarding high-priority prompts > - refer the question of overall releasability of runit-run to the Release >Team Yes, this seems like an appropriate response from the TC. Bdale pgp8SDCMTFQKc.pgp Description: PGP signature
Bug#586887: cannot replace sudo by sudo-ldap when no root password has been set
On Wed, 23 Jun 2010 10:55:47 +0200, "Andreas B. Mundt" wrote: > when installing a ltsp-server in debian-edu, the installation fails > because sudo is removed and no root password set. This is caused by > sudo.prerm which checks whether the root account is locked. > > Unfortunately this happens even if at the same time sudo-ldap is > scheduled for installation. I don't know the sequence of what is getting installed when in your situation, but would a reasonable solution be to just start by installing sudo-ldap instead of installing sudo and then removing it? Bdale pgp5Jkd0mOpWh.pgp Description: PGP signature
Bug#422139: Please supply a sysvinit script
On Tue, 2009-02-03 at 20:01 +, Ian Jackson wrote: > It would be better to solve that problem (that the > administrator should be able to choose whether to run the daemon) with > a debconf question. I agree. Either a debconf question, or a default behavior of using sysvinit in the main package that is overridden if the git-daemon-run package is installed would make sense to me. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514146: amanda: permissions prob with backup home dir
On Wed, 2009-02-04 at 11:16 -0700, Glenn English wrote: > Package: amanda-server > Version: 1:2.5.2p1-4 > Severity: normal > File: amanda > > > User backup's home dir (/var/backup) isn't writable by backup. The amanda-common postinst creates the backup user, creates the home directory if it doesn't already exist, creates .amandahosts in that directory as a link to /etc/amandahosts if it doesn't already exist,a nd forces the permissions on that file. It has been a long time since I thought about the postinst contents, but I don't recall anyone ever having a permissions problem like this either. I suppose we could also force the ownership of the directory in the postinst, but before we make that change I'd like to understand more about how you got into this situation, if possible. Can you describe for me, briefly, the history of Amanda on this machine so we can see if there's some obvious issue that led to the current state that might better be resolved elsewhere? Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514016: options for fixing
On Thu, 2009-02-05 at 18:20 +0100, Thomas Viehmann wrote: > just as an exercise what might be done to fix this: > It would seem that the options are > - not fix it (for now), > - find something in current tar that works (I didn't), > - switch off tar, > - try to do something with tar > (new upstream - vs. release: ugh - has a "apply to symlink target" >--transform flag, but that also might need post-processing of >symlinks at end of bootstrapping), > - try to do some ld-preload(?) trickery for changing the way symlinks > are read, > - try to find some way to chroot before calling tar, one possibility > would be copying required files to some temp CWD, make tar look there > for the libraries, chrooting to the target and calling tar from (the > unchanged) CWD, > - add chroot option to tar (see patch). How about just fixing the offending package to use a relative symlink, like /lib64 -> lib? This is well within policy since they're adjacent objects in the same directory, and is less likely to break things or be a pain to maintain over time than any of the options above. I can't think of any negative consequence to this change, offhand? Adding a Debian-specific option to tar would certainly not be my first choice. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#512993: [INTL:es] Spanish debconf template translation for elilo
tags 512993 +pending thanks On Sun, 2009-01-25 at 17:10 +0100, Fernando González de Requena wrote: > Please find attached the spanish debconf template translation, proofread > by the debian-l10n-spanish mailing list contributors. Thank you! This is now in my local revision control system and will be part of my next upload. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511651: Dump dumps garbage on ext4
severity 511651 important thanks On Tue, 2009-01-13 at 03:31 +0100, Zlatko Calusic wrote: > Package: dump > Version: 0.4b41-6 > Severity: grave > Justification: causes non-serious data loss > > I've just noticed that dumps that I've been doing last few weeks are > completely unusable. And the reason for that is the recent switch of > all my filesystems from ext3 to ext4. I agree that this is unfortunate, but since dump is fairly explicit about being for ext2 and ext3, I don't accept that this is a bug of grave severity. I'm going to downgrade it to important for now. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#168606: [PATCH] Allow "-f -" to work with zgrep
tags 168606 +pending thanks On Sat, 2009-01-24 at 02:27 +1100, Carl Worth wrote: > Here's a patch that allows the "-f -" option to work with zgrep in the > same way that it works with grep. Thanks, Carl! Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513754: lack of type in posh
tags 513754 +wontfix thanks The lack of 'type' support in posh feels more like a bug to me than a feature. I'm not likely to work on this bug until #397601 is resolved, hopefully by someone pursuing the proposal to get 'type' added to the set of features expected to be supported by a shell in Debian policy. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#475022: any update?
Hi Alexander. Do you have any update on your ITP of connman? I want to use it for a project I'm working on, and the bits at git.moblin.org seem reasonable to package. If you're still interested, that's great, but if not please let me know and perhaps I'll take a stab at it. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509154: update?
Hi Marco! Any update on when we can expect a fresher udev build in unstable? The lack of libudev is blocking several interesting tools from being packaged for Debian. I note that Scott Remnant appears to have done a lot of work on on upstream version 136 which is now in Ubuntu, I haven't read through the entire changelog but perhaps some of the bugs might already be fixed there? https://edge.launchpad.net/ubuntu/+source/udev Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#430826: sudo-ldap: should use alternative config file
On Wed, 2009-03-11 at 16:01 +, Adrian Bridgett wrote: > Just a quick chase on this - it's almost there, just a typo to fix in > the package. It'd be great if this could make it into lenny. It might be possible for this to be petitioned in to a lenny point release. Exactly what the criteria for accepting changes might be for those isn't clear to me right now. I'm willing to upload a new sudo package version fixing just this bug, though, to ease the decision. > BTW there is a typo in the symlink bit I posted (it says > sudo-ldap,conf rather than sudo-ldap.conf). Good catch. > I think that's also worth having - at the moment, if the path is fixed > for the sudo-ldap package it will break upgrades. Actually, shouldn't this be conditionalized further so that the symlink is only created if both the new path doesn't exist and the old one does? If the old one doesn't exist, there isn't any point creating the link, is there? Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519643: printing ascii text no longer works as expected
Package: cups Version: 1.3.9-15 Ok, with foomatic v4 now in the archive and this version of cups pulling it in, #511009 is indeed fixed. That's great. Unfortunately, something else is now broken. If I take a simple ASCII text file and send it to any of my printers using lpr, it comes out in a font that's huge compared to what I used to get, maybe by a factor of 2 or so? As a result, text is clipped on the right side of the page (even on lines that aren't near 80 columns). I've gotten as far as confirming that the ps or pdf file fed to foomatic is wrong, but I haven't figured out where in the text -> ps/pdf chain things are broken. Any suggestions? Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#486405: ... make that 2.6.1
On Mon, 2009-03-16 at 16:29 +0100, Ralph Rößner wrote: > Bumping this request to Amanda version 2.6.1 . Having the pre- and > post-script features would be really helpful. Working on it already. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511009: all output printed as raw pdf
severity 511009 serious thanks I'm seeing this problem now. All of my printers started spewing pages of raw pdf when I upgraded to cups 1.3.9-14 yesterday from whatever was in unstable as of a week or so ago. All of them are HP devices using hplip and network interfaces. The problem apparently is that the files in /etc/cups/ppd ended up with two lines starting '*cupsFilter:', like: *cupsFilter: "application/vnd.cups-postscript 100 foomatic-rip" *cupsFilter: "application/vnd.cups-pdf 0 foomatic-rip" Removing the second line and changing the '100' in the first to '0' got things working again. I gather this is a transition problem in the move from ps to pdf that foomatic isn't quite ready for yet? In any case, it's a pretty horrific bug that really must get resolved before squeeze releases, so I'm increasing the severity on this bug to serious. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511009: foomatic 4.0?
Hi Chris! I raised the severity on cups bug #511009 yesterday to release-critical, since the move from postscript to pdf as the default cups output format broke all of my printers. As Keith Packard noted in a follow-up to the bug, it appears that foomatic 4.0 adds support for pdf input. So, updating the foomatic version in sid may be the best fix for this bug. I see you're the maintainer of foomatic-db and friends. When do you plan to upgrade the Debian packages to foomatic 4.0 or later? Are there other issues with that, or has it just not gotten attention yet? If the latter, would you like some help? Regards, Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#484841: staff group root equivalence
On Mon, 2009-03-02 at 00:48 -0800, Don Armstrong wrote: > Is there a use case for having people in the group staff with > /usr/local g+w that isn't better solved using sudo to provide similar > access? [I've never had people in the staff group, so I don't know > what people were using it for historically.] I can't think of such a case. I, too, have never used group 'staff' but have assumed others did since I seem to recall some push-back on the idea of changing this in the past. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#198991: sudoers: Related security implications
On Tue, 2009-03-03 at 21:39 -0600, Astrild wrote: > Package: sudo > Version: 1.6.9p17-2 > Followup-For: Bug #198991 > > > ok, this is quite simple, make sudo to always default to targetpw > Not much to explain, there was a little bug in Suse with kdesu and when they > tried to solve it, they faced a sec hole of a sudoers with no targetpw, so > they set it up. > > Details here: > http://lists.opensuse.org/opensuse-bugs/2007-01/msg00774.html I don't understand what relationship you think this information has to Debian bug 198991? Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#518493: sudoers: user can't modify sudoers file if not into
severity 518493 wishlist reassign 518493 debian-installer thanks On Fri, 2009-03-06 at 16:27 +0100, andso wrote: > Package: sudo > Version: 1.6.9p17-1 > Severity: normal > File: sudoers > > with debian-xfce i cant use directly sudo because i(user)'m not in sudoers > file, > after fresh install. I suppose i have to reboot in single mode and modify the > sudoers file > chears I want to make sure I understand. This is a new installation of Debian? And you chose the XFCE user environment, and expected the installer to leave things so that as the new user identified during the installation process you'd be able to use sudo immediately? This is not a bug in the sudo package. The sudo package provides a relatively empty 'template' /etc/sudoers file, but we would consider it a bug for the package to automatically elevate user privs. Since I don't think the Debian installer does anything intentionally to set up superuser privs for users I doubt it's actually a bug there either. However, since there are other distributions that do set up sudo automatically for the primary user at system install time, it's reasonable to suggest this as a feature enhancement (or 'wishlist') item for the Debian installer team to consider. I will downgrade the severity of this bug to 'wishlist' and reassign it to 'debian-installer' for their consideration. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#506122: increasing severity
severity 506122 serious thanks Increasing the severity on this to ensure the package isn't released stable with this bug still present. Blindly breaking postfix+postgrey integration clearly meets the 'makes the package unsuitable for release' criteria for severity serious. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516984: MAKDEV tries to change devices in read-only /dev/.static/dev/ without success
On Tue, 2009-02-24 at 16:37 -0500, sasha mal wrote: > Package: makedev > Version: 2.3.1-88 > Severity: critical > > During and after an update from etch to lenny, installation procedure > for packages that need creating devices cannot create them. Why is /dev/.static/dev/ read-only on your system? Do you know? I've upgraded a number of systems from etch to lenny now without ever seeing this, so I have to assume there's something different about how our systems. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#517024: please add a --no-pristine-tar option
Package: git-buildpackage Severity: wishlist By default, I have my .gbp.conf file set up to use pristine-tar. However, when dealing with a non-DFSG upstream tarball, it would be nice to be able to do something like: git-buildpackage --no-pristine-tar -S pristine-tar commit ../build-area//_.orig.tar.gz to generate an orig.tar.gz from the cleaned branch and get it into the pristine-tar branch. If you were to provide a clueful way of doing both of the above operations in one git-buildpackage invocation I might use it, but all I really want is to not have to fiddle with .gbp.conf and use the --git-ignore-new flag every time I want to create an orig.tar.gz... Thanks for considering this! Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522065: sudo-ldap: Does not read it's LDAP configuration since 1.7.0
On Tue, 2009-03-31 at 16:03 +0200, Fladischer Michael wrote: > Running `strace` shows that sudo does not open any of this configuration > files despite '/etc/sudoers'. Can you forward me the strace output, please? I don't personally use LDAP, so I don't have a quick way to try and reproduce the problem here. Looking at a trace may help me diagnose the problem. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522048: Is makedev usefull anymore?
On Tue, 2009-03-31 at 14:32 +0300, Riku Voipio wrote: > Package: makedev > Version: 2.3.1-88 > Severity: important > > As far I see, it is very hard to use debian these days without udev, > so makedev has become outdated. If makedev is not to be removed > yet, it should at least not be Priority: required anymore. That's an interesting suggestion. There are three cases we need to investigate and address before making such a change. One is the use of makedev in package postinst scripts. I don't know offhand what the set of packages are that have an implicit dependency on makedev, those would all need to be updated to make the dependency explicit before we take makedev out of the set of packages assumed to be present on a system. Another is the use of makedev in debootstrap and friends. It at least used to be a necessary part of the build environment for those tools if not the runtime. Adding explicit dependencies or build dependencies to such packages would be required if makedev is no longer assumed to be present on a system. And directly or indirectly through the *debootstrap packages, I assume debian-installer still has a dependency on makedev. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522048: Is makedev usefull anymore?
On Tue, 2009-03-31 at 20:51 +0300, Riku Voipio wrote: > On Tue, Mar 31, 2009 at 11:12:39AM -0600, Bdale Garbee wrote: > > One is the use of makedev in package postinst scripts. I don't know > > offhand what the set of packages are that have an implicit dependency on > > makedev, those would all need to be updated to make the dependency > > explicit before we take makedev out of the set of packages assumed to be > > present on a system. > > postinst scripts on my system use something like I did a search in the lintian lab on gluck today, and found that 103 current packages have one or more makedev calls in preinst/postinst. I haven't tried to analyze how many of those might fail if the makedev package were not present. > [ -x /dev/MAKEDEV ] && /dev/MAKEDEV foo > > some use "-e", bad maintainers... There might some packages that fail to > check. > > Btw, this was inspired by the fact that /dev/MAKEDEV symlink is gone > without fanfare in ubuntu jaunty. The still ship the package thou.. We > could fix it properly by leaving the package :) I've been telling people for something like a decade that they should call /sbin/MAKEDEV explicitly and not depend on the symlink in /dev, so I have little sympathy for any package affected by this change... however, I note that on my system, it's about an even split between packages that call /sbin/MAKEDEV and packages that depend on the /dev symlink. Sigh. > > Another is the use of makedev in debootstrap and friends. It at least > > used to be a necessary part of the build environment for those tools if > > not the runtime. Adding explicit dependencies or build dependencies to > > such packages would be required if makedev is no longer assumed to be > > present on a system. > > debootstrap: build-depends on debootstrap and builds a devices.tar.gz > during buildtime. I presume you meant build-depends on makedev, which sounds like what I remember. > cdebootstrap: doesn't use makedev at all, does some mknod's itself in a > helper package on runtime. Interesting. Good to know. > It is, ofcourse possible that devices.tar.gz / cdebootstrap-helper-makedev.deb > forget to create some devices that makedev will create anyway in > postinst (which will get installed automatically due to required > priority). Right. However, if we were to make the makedev package optional with all that implies, I suspect fixing up any serious consequences of this would be fairly easy. So I think we have enough information for me to write up a proposal to transition the makedev package to priority optional. I'm not inclined to do away with it entirely since I think there may be some residual value in having it around for a while longer. But forcing packages to be able to live without it sounds like a completely reasonable thing to pursue... Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522545: [Bash-completion-devel] Bug#522545: bash-completion: configuration file conflict with mtx
On Sat, 2009-04-04 at 21:03 +0200, David Paleino wrote: > > processing > > /var/cache/debtorrent/ftp.pl.debian.org_debian_dists_unstable_main_binary-all/pool/main/b/bash-completion/bash-completion_1.0-1_all.deb > > (--unpack): trying to overwrite `/etc/bash_completion.d/mtx', which is also > > in package mtx > > Is the version in mtx updated? If not, I'd suggest mtx's maintainer (CCed) to > grab the one from bash-completion's git repo. > > http://git.debian.org/?p=bash-completion/bash-completion.git;a=blob_plain;f=contrib/mtx;hb=a4c9bdc1774d234f322d214cf7636c10bd2db1c0 So, what's the right strategy for these? I added the file in Feb 2004 on request from Jon Middleton, per Debian bug #227456. I haven't given it a single thought since then... Does it make sense for me to continue to include the bash completion file in the mtx package, or should I instead stop including it and add a suggests on bash-completion to the package dependencies? Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#521432: gzip: --suffix segmentation fault with *.tgz file
On Fri, 2009-03-27 at 16:07 +0200, Jari Aalto wrote: > Package: gzip > Version: 1.3.12-7 > Severity: important Hi. Thanks for the problem report. What causes you to flag this problem as being of severity 'important'? It's not immediately obvious to me that this should be anything other than 'normal'. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#473228: tar: [manual] 1.19 new options are not listed in manual page
severity 473228 +wishlist thanks On Sat, 2008-03-29 at 14:46 +0200, Jari Aalto wrote: > Package: tar > Version: 1.19-3 > Severity: normal > Page http://www.gnu.org/software/tar/ lists options for 1.19: > > * New option --exclude-vcs excludes directories and files, created > by several widely used version control systems, e.g. CVS/, > .svn/, etc. > > * The --exclude-tag* and --exclude-cache* option families work > with incremental archives as well. > > They are missing frm the tar(1) manual page. The man page which I maintain for the Debian package typically lags the official docs. I'd be pleased to have a patch for the man page if you want to prepare one, otherwise I'll get to this when I can. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440573: closed by Bdale Garbee <[EMAIL PROTECTED]> (nothing to fix)
On Mon, 2008-03-10 at 14:42 -0400, Tony Lill wrote: > Here is my /etc/fstab > > /dev/md5/ ext3noatime,errors=remount-ro 0 1 > > Here's the output of mount: > > /dev/md5 on / type ext3 (rw,noatime,errors=remount-ro) > > Here's the entry from my disklist file: > > ds /comp-os > > Amanda seems to pulling /dev/root out of it's ass. I thinks it's still > an amanda bug. I think your use of '/' in this file is the problem. Not sure offhand where in the chain that's getting mapped to an actual block device. My entries look more like: hosta hda1comp-root hostb mapper/vg00-lvol3 comp-user Hope that helps. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#435244: still in 1.19?
On Wed, 2008-03-12 at 15:36 +0100, Andreas Tille wrote: > On Fri, 22 Feb 2008, Bdale Garbee wrote: > > > It would be very interesting to me to know if the performance of tar is > > still > > a problem for you in version 1.19-1 and later. Is this something you could > > try and report results to me on? I don't have any easy way to duplicate > > your > > circumstances with the systems I have at hand. > > Hmmm, I tried for several days but there is no visible change. I try > to track down the problem to a state where it might be possible to > be reproduced on your side. Thank you! Let me know what you learn and we'll figure out what to do from there. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470202: can't reproduce your problem
severity 470202 important tags 470202 +moreinfo +unreproducible thanks Hello Raphael. Sorry you're having trouble with amanda. I don't see the problem here, so suspect there might be something unusual in your config files. Can you send me a copy of them to look over? Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#602907: [Bug-tar] need help with tar output stability problem
On Wed, 10 Nov 2010 21:59:03 -0800, Paul Eggert wrote: > This file name is exactly 100 bytes long, and if I recall, that used > to be a problem area in GNU tar. The 1.24 tarball contains a longlink > representation of the file (which isn't right), whereas the 1.23 tarball > is right. Ugh. Smoking gun. I was carrying a patch around for ages to try and work around this bug, which tripped a bug in dpkg for a while. Finally realized it was no longer needed and removed it from my build of 1.24. So, Joey, I wonder if the tarballs you're seeing a size change on have files with 100 byte filenames? If so, sorry, but I'd been carrying that patch around since 1.15.something, I think... > Perhaps you got a prerelease version of 1.24, with bugs? Did you build > 1.24 from sources yourself? Have you tried with 1.25? What platform > are you running GNU tar on, and how do you build GNU tar? I'm pretty sure he's normally using my packages of tar for Debian, but he was building from git this afternoon trying to track this down. Bdale pgpTBzumJRwpO.pgp Description: PGP signature
Bug#602907: [Bug-tar] need help with tar output stability problem
On Wed, 10 Nov 2010 22:19:12 -0800, Paul Eggert wrote: > On 11/10/2010 10:14 PM, Bdale Garbee wrote: > > On Wed, 10 Nov 2010 21:59:03 -0800, Paul Eggert wrote: > >> This file name is exactly 100 bytes long, and if I recall, that used > >> to be a problem area in GNU tar. The 1.24 tarball contains a longlink > >> representation of the file (which isn't right), whereas the 1.23 tarball > >> is right. > > > > Ugh. Smoking gun. I was carrying a patch around for ages to try and > > work around this bug, which tripped a bug in dpkg for a while. Finally > > realized it was no longer needed and removed it from my build of 1.24. > > Ah, sorry, I'm a bit confused. Is your theory that this age-old patch > broke 1.24? My theory is that every version of Debian tar for quite a while was "broken", and 1.24 is when it got "right" again. I'll work with Joey on this some more tomorrow and see if we can confirm that. > If so, we don't need to do anything upstream. If not, then please let us > know (for example, what patch is it, and what test case illustrates the > need for the patch). I think you've given us the clue we needed to fix our problem, we'll be back if not. Thanks! Bdale pgpbp5guv7B9S.pgp Description: PGP signature
Bug#607328: version 5.11 is available
Package: eagle Severity: wishlist Eagle version 5.11 is now available, and every time you launch 5.10 it tells you that. Be nice to have updated packages. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#598345: tar: remove unneeded patch to src/create.c
On Tue, 28 Sep 2010 14:10:42 +0200, Lars Gustäbel wrote: > I browsed through the history and found out that this patch was > introduced back in 2004 to work around some problems in dpkg (bug > #230910). dpkg was fixed four weeks later (bug #232025), but the patch > has not been reverted up to this day. Thanks for bringing this to my attention. I agree with your analysis, and will revert this patch in my next Debian upload. Bdale pgphRdST58C9I.pgp Description: PGP signature
Bug#598567: sudo requires reauthentication on each use, ignoring time stamp
On Fri, 1 Oct 2010 09:12:31 +0200, Diggory Hardy wrote: > For me, then, turning tty_tickets off is a good enough solution. I'll try to > add a note into the fish users wiki. Feed me a suitable paragraph and I'll be happy to add it to the sudo README.Debian file. Bdale pgpZtkLfWFTWx.pgp Description: PGP signature
Bug#600892: sudo: Breaks webmin: no useful debugging output.
On Wed, 20 Oct 2010 22:15:43 -0200, Teresa e Junior wrote: > Since we upgraded from sudo 1.7.2 to 1.7.4, webmin is broken. I know nothing useful about webmin. Can you use sudo from the command line as the affected user ok? In other words, I'm trying to understand if the problem is that sudo just isn't working, or if something has changed in sudo that violates some expectation of webmin. Bdale pgpPep2DqqmQx.pgp Description: PGP signature
Bug#601469: sudo not working with ircp
On Tue, 26 Oct 2010 17:00:20 +0200, Yellowprotoss wrote: > $ sudo ircp "/tmp/tm.txt" > Connecting...failed > > during sending a regular file (readable) I don't know anything about ircp, so this doesn't tell me anything about what you expected to happen that didn't happen. It looks like sudo is invoking ircp, so it's likely that something about the environment that sudo creates for the program you're running violates some expectation of the program. Bdale pgpZnn3Oq4UAu.pgp Description: PGP signature
Bug#560766: working on it
retitle 560766 "ITP: heekscad -- Free CAD based on Open CASCADE" retitle 561002 "ITP: heekscnc -- CNC machining add-in for HeeksCAD" thanks I'm using these two now for my own purposes, and will do the extra work to upload policy-compliant packages. The only issue I see so far is that add-ins like heekscnc need access to some heekscad source files during the build, so it may make sense to create one Debian source package that emits multiple binary packages. Bdale pgppIunmlULsy.pgp Description: PGP signature
Bug#609741: new include line in sudoers is not valid
On Tue, 11 Jan 2011 21:41:48 -0600, Joe Neal wrote: > Package: sudo > Version: 1.7.4p4-6 > Severity: important > > Upon uncommenting the the new line in sudoers to include files in > /etc/sudoers.d, visudo gives a syntax error warning on exit. What do you mean "uncommenting"? The line is active in the sudoers file as shipped. Did you remove the leading '#' from the includedir? If so, you introduced a syntax error. See the sudoers man page for details. Bdale pgpNiOP0lS2V6.pgp Description: PGP signature
Bug#609839: unblock: sudo/1.7.4p4-6
On Wed, 12 Jan 2011 22:38:56 +0100, Moritz Muehlenhoff wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package sudo. It fixes CVE-2011-0010. > > unblock sudo/1.7.4p4-6 > > There are some non-security fixes since the -2 version in testing, > though. I would love to see -6 replace -2 in testing. I just reviewed my commit logs, and all of the changes in that range were either packaging improvements, or minimal patches from upstream to fix real bugs. In particular, note that the patch from upstream that took us from -5 to -6 also has potential security implications (in some circumstances a user could change default group without the expected password prompt). Bdale pgpwA5h2Qyf2e.pgp Description: PGP signature
Bug#609825: pax ustar format lacking devmajor/devminor entries
On Wed, 12 Jan 2011 14:37:47 -0500, Stew Benedict wrote: > The version of pax shipped with Debian and Ubuntu does not seem to > populate the devmajor/devminor fields according to the ustar format. The pax in Debian is built from sources acquired from the OpenBSD project. For many years, we used a version that was, frankly, ancient, and driven by complaints that it didn't handle large files well, etc, in July of 2009 I built a fresh version from the head of OpenBSD CVS. I just reviewed the diff between my source tree and the current OpenBSD head of CVS, and I see nothing changed that might be even remotely related. I'm not particularly motivated to try and chase down this problem, but if you or someone else want to, I'd certainly be happy to accept a patch. But I have to say that it seems *really* weird to me for the LSB suite to depend on pax. It's not a default part of the base install of any Linux distribution I know of. If the goal is to have an LSB suite that tests relevant compatibility issues between different Linux distributions, then I would personally strongly recommend switching the tests to use GNU tar, then work with upstream to reconcile any issues... I've found them quite responsive and easy to work with over the years. Bdale pgpFAGmV41yuh.pgp Description: PGP signature
Bug#602709: tar: diff for NMU version 1.24-1.1
On Sun, 7 Nov 2010 13:16:06 +, Simon McVittie wrote: > As discussed with cworth on IRC yesterday, I've prepared an NMU for tar > (versioned as 1.24-1.1) which I will upload directly to sid (assuming my > smoke-testing is successful), to try to avoid packages intended for squeeze > mis-building. Thanks! Bdale pgpjQS8iZ3mYN.pgp Description: PGP signature
Bug#592049: remove makedev from experimental
Package: ftp.debian.org Severity: wishlist The makedev 3.3.8.2 version in experimental is a developmental dead-end, and I intend to do no further work on it. Please remove it from the archive. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592376: places menu in sqeeze doesn't allow access to remote filesystems using sudo
reassign 592376 gnome-panel thanks On Mon, 09 Aug 2010 13:24:43 -0400, tony wrote: > Package: sudo > Version: 1.7.2p7-1 > Severity: normal > > After installing squeeze and setting it up with sudo (using blank root > password) the places menu doesn't allow access to remote filesystems. It > prompts for root password but doesn't accept user password or blank root > password. It is highly unlikely that this is due to a problem in sudo. I gather the 'places menu' is a gnome panel thing, so reassigning the bug there for further attention. Bdale pgpm0fGFUcmHt.pgp Description: PGP signature
Bug#599376: (no subject)
On Thu, 07 Oct 2010 16:55:25 -0400, Matthew Gabeler-Lee wrote: > tag 599376 upstream > forwarded 599376 http://www.gratisoft.us/bugzilla/show_bug.cgi?id=445 > thanks > > Issue is in upstream, upstream has a patch for it. Patch applies to Debian > source cleanly and fixes the issue for me. Thanks for chasing this down, I'll apply that patch and upload a new version shortly. Bdale pgpfQFBJ3GQp8.pgp Description: PGP signature
Bug#598141: sudo: segfaults on -g
tags 598141 + unreproducible moreinfo thanks On Sun, 26 Sep 2010 22:03:02 +0200, Jakub Wilk wrote: > Package: sudo > Version: 1.7.4p4-3 > $ sudo -g staff id > Segmentation fault I can't reproduce this. Any other clues? Bdale pgpBWnA4NswQg.pgp Description: PGP signature
Bug#598022: pod markup in sudoers(5) manpage
On Sat, 25 Sep 2010 14:45:35 +0200, Jakub Wilk wrote: > Some pod markup leaked to the sudoers manpage verbatim: > > $ man sudoers | grep -F 'F<' > > F Looks like there's code in sudoers.man.pl which is called during the pod to man conversion to try and fix up things like this that pod2man gets wrong that just isn't working. I'll push this upstream. Bdale pgp0ARVfaQp8v.pgp Description: PGP signature
Bug#368297: problem appears to lie in libldap
reassign 368297 libldap-2.4-2 thanks I'm reassigning this but to libldap-2.4-2 since it now appears that the problem isn't actually in sudo, but in the interaction between libldap, gnutls, and gcrypt. Bdale -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#598141: sudo: segfaults on -g
On Fri, 8 Oct 2010 12:26:24 +0200, Jakub Wilk wrote: > Have you tried with the minimal /etc/sudoers I attached to the first > message? No, good point. I'll try again when I have some more time to pursue this. Bdale pgpx2Ld3G1J0m.pgp Description: PGP signature
Bug#594377: sudo resets niceness
reassign 594377 libpam-modules thanks Since the issue really seems to be undocumented defaults in pam_limits, I'm reassigning this bug for resolution there. Bdale pgpgc6jIAJWVl.pgp Description: PGP signature
Bug#573745: Things have changed significantly for the better
On Tue, 06 Jul 2010 13:10:47 +0200, Bernd Zeimetz wrote: > We definitely need to get rid of the mess of different helpers in Squeeze+1 > without waiting until a month before the freeze. The reason that there are two > helpers is insane enough and it is about time to fix that. I agree. As a casual user of Python and maintainer of packages that deliver Python scripts, the current situation is really confusing. > I'm wondering why there should be more than one team to maintain > -defaults and Python itself. It doesn't make sense to have more than > one team as it makes the coordination even harder. I agree on this, too. I doubt there are any good technical reasons for more than one team here, but there may well be a reasonable division of responsibilities that would lead to different lists of maintainers and/or uploaders on the different packages. Some people would read that as "different teams", perhaps? [shrug] Bdale pgp3LNe7KWhjo.pgp Description: PGP signature
Bug#587558: gnuradio: Needs to be rebuilt as python 2.6 is now default
On Tue, 29 Jun 2010 15:46:47 -0400, Pascal Giard wrote: > Package: gnuradio > Version: 3.2.2.dfsg-1 > Severity: normal > > Python 2.6 is now the default while python modules for GNURadio are only > built/installed for python 2.5. Thanks. I'm working a toolchain problem in the regression suite with upstream, as soon as that's resolved I'll make a fresh upload. Bdale pgpyruJPt0QRt.pgp Description: PGP signature
Bug#589227: cpmtools: possible FHS violation, as fsck.cpm and mkfs.cpm are not in /sbin
On Thu, 15 Jul 2010 23:42:00 +0200, Christoph Anton Mitterer wrote: > The FHS in turn specifies: > "The following files, or symbolic links to files, must be in /sbin if the > corresponding subsystem is installed: > ... > fsck.* > mkfs.* > " > (see http://www.pathname.com/fhs/pub/fhs-2.3.html#SPECIFICOPTIONS8). You pose an interesting question. After thinking about it a bit, here's my current take on it. I interpret "corresponding subsystem is installed" to mean that the kernel knows how to mount and use the filesystem type in question. To the best of my knowledge, that is not true for CP/M filesystems, which I believe can only be manipulated from user space and not directly mounted. Also, the overall definition for /usr/sbin in the FHS says "This directory contains any non-essential binaries used exclusively by the system administrator." That is clearly not true in this case. All this suggests to me that leaving the two executables in question in the /usr/bin directory where they are now is a better choice than moving them. > I don't judge whether /sbin is really a better location, just > wanted to bring this to your attention :) No problem. It's an interesting question. Do you agree with my analysis? Bdale pgpjvLkCoAzeH.pgp Description: PGP signature
