Re: Example for use of dh_strip --dbg-package=... and CDBS?
fltk1.1 does this. Here's its rules file: #!/usr/bin/make -f include /usr/share/cdbs/1/rules/buildcore.mk include /usr/share/cdbs/1/class/autotools.mk include /usr/share/cdbs/1/rules/debhelper.mk # The original definition also includes -fno-exceptions, which we # might as well punt so that throwing exceptions from callbacks # actually works. We also punt -Wall, which CDBS puts in CFLAGS. FLTK_OPTIM="$(CFLAGS) -Wunused -Wconversion -fPIC -D_REENTRANT" DEB_CONFIGURE_EXTRA_FLAGS = --enable-shared --enable-threads --enable-xft --without-links DEB_CONFIGURE_SCRIPT_ENV = DEB_MAKE_INVOKE= make OPTIM=$(FLTK_OPTIM) DEB_MAKE_CHECK_TARGET = DEB_INSTALL_CHANGELOGS_ALL = CHANGES DEB_INSTALL_DOCS_ALL = CREDITS README DEB_DH_MAKESHLIBS_ARGS = -V DEB_DH_SHLIBDEPS_ARGS = -l debian/libfltk1.1c102/usr/lib -Lfltk1.1c102 DEB_DH_STRIP_ARGS = --dbg-package=libfltk1.1c102 clean:: rm -rf autom4te.cache build/fltk1.1-doc:: cd documentation && make fltk.ps && make fltk.pdf binary-predeb/fluid:: binary-fixup/libfltk1.1c102 [Likewise for ncbi-tools6, but its rules file is much hairier.] -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Thomas Viehmann <[EMAIL PROTECTED]> writes: > +pcsx: i386# i386 > assembly AFAICT, this is only because its Linux/Makefile forces CPU to ix86 unconditionally. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: StrongARM tactics
Ryan Schultz <[EMAIL PROTECTED]> writes:
> PCSX 1.6 does not compile with GCC4 when the ix86 flag is not specified, even
> on i386. I don't know about amd64, but my other partially-ASM (using NASM
> like PCSX) package (libopenspc) will not build on amd64, so I'm assuming that
> the same is true here -- I'll change it if someone can confirm that it will
> build and work.
It built on my AMD64 system with a crude patch (attached, along with
the resulting log) that drops the CPU setting unconditionally, but I
haven't actually tested the result -- I built it mainly because I'm a
packrat. ;-)
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
diff -u pcsx-1.6df/debian/control pcsx-1.6df/debian/control
--- pcsx-1.6df/debian/control
+++ pcsx-1.6df/debian/control
@@ -6,7 +6,7 @@
Standards-Version: 3.6.2
Package: pcsx
-Architecture: i386
+Architecture: any
Depends: ${shlibs:Depends}
Recommends: psemu-sound, psemu-input, psemu-drive, psemu-video
Description: Sony PlayStation emulator
diff -u pcsx-1.6df/debian/changelog pcsx-1.6df/debian/changelog
--- pcsx-1.6df/debian/changelog
+++ pcsx-1.6df/debian/changelog
@@ -1,3 +1,12 @@
+pcsx (1.6df-1.0) unstable; urgency=low
+
+ * NMU of sorts (though no actual upload intended.)
+ * debian/control: Change architecture from i386 to any.
+ * Linux/Makefile: don't force CPU to ix86 (should be done conditionally
+in debian/rules).
+
+ -- Aaron M. Ucko <[EMAIL PROTECTED]> Mon, 28 Nov 2005 10:42:36 -0500
+
pcsx (1.6df-1) unstable; urgency=low
* Initial release Closes: #137355
only in patch2:
unchanged:
--- pcsx-1.6df.orig/Linux/Makefile
+++ pcsx-1.6df/Linux/Makefile
@@ -7,7 +7,7 @@
all: pcsx
-CPU = ix86
+# CPU = ix86
OPTIMIZE = -O2 -fomit-frame-pointer -finline-functions -ffast-math
FLAGS = -D__LINUX__ -DPCSX_VERSION=\"${VERSION}\" -DPACKAGE=\"pcsx\"
dpkg-buildpackage: source package is pcsx
dpkg-buildpackage: source version is 1.6df-1.0
dpkg-buildpackage: source changed by Aaron M. Ucko <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture amd64
fakeroot debian/rules clean
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for strip... strip
checking for rm... rm
checking for rmdir... rmdir
checking gtk+2... checking for pkg-config... /usr/bin/pkg-config
checking for gtk+-2.0 > 2.0.0... yes
checking GTK_CFLAGS... -DXTHREADS -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include
checking GTK_LIBS... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm
-lpangoxft-1.0 -lpangox-1.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0
configure: creating ./config.status
config.status: creating Makefile.cfg
touch configure-stamp
dh_testdir
dh_testroot
rm -f build-stamp configure-stamp
# Add here commands to clean up after the build process.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && /usr/bin/make clean
make[1]: Entering directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
rm -f Makefile.cfg
rm -f *.o ../*.o ..//*.o pcsx
rm -f config.*
make[1]: Leaving directory `/home/amu/src/pcsx/pcsx-1.6df/Linux'
dh_clean
dpkg-source -i -b pcsx-1.6df
dpkg-source: building pcsx using existing pcsx_1.6df.orig.tar.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.diff.gz
dpkg-source: building pcsx in pcsx_1.6df-1.0.dsc
debian/rules build
dh_testdir
# Add here commands to configure the package.
cd /home/amu/src/pcsx/pcsx-1.6df/Linux && ./configure --bindir=/usr/games
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking for C compiler default outpu
Re: c2a transition: libraries still needing transition
Nathanael Nerode <[EMAIL PROTECTED]> writes: > aqsis It would be nice if whoever uploads this could also address #324025 (64-bit FTBFS, patch available). > It would be very nice to finish these off. Once all these libraries are > transitioned, the remaining C++ programs using the old ABI can be queued for > automatic binNMUs by the release team, so these are the only source uploads > still needed just for the transition (not including uploads to fix FTBFSes, > RC bugs, etc.) It's not quite that simple, as some applications will also need sourceful uploads because tight dependencies between binary-all and binary-arch packages yielded broken binNMUs: cinepaint kgeography pingus (maybe others, those are just the ones I've run into that haven't been fixed yet). Surprisingly, only pingus has a bug open about the matter (#342231). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gconf transition
"Alejandro Bonilla" <[EMAIL PROTECTED]> writes: > /usr/lib/libgconf2-4/gconf-sanity-check-2: error while loading shared > libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such > file or dir > gconf-sanity-check-2 did not pass, logging back out Fun! :-/ > Which package gets the bug report? Looks like libgconf2-4, for lacking proper dependencies (on libpango1.0-0, at the very least). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Heimdal and openssh
Russ Allbery <[EMAIL PROTECTED]> writes: > Juha Jäykkä <[EMAIL PROTECTED]> writes: > >>> * Interoperate with ssh-krb5 << 3.8.1p1-1 servers, which used a >>> slightly >>> different version of the gssapi authentication method (thanks, Aaron >>> M. Ucko; closes: #328388). > >> Perhaps this is THE patch which makes them all work together while >> openssh folks claim they don't? This is a side-issue, but it would be >> nice to know. > > That may very well be the case, yeah. I've not done a lot of > experimentation. As I recall, that patch (which I lifted from ssh-krb5) just addresses interoperation with old (3.5-era) versions of the "unofficial" patch, which is otherwise stabler than the upstream-blessed gssapi support. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351276: ITP: python-dsv -- Python module for delimiter-separated-value files
Package: wnpp Severity: wishlist Owner: "Aaron M. Ucko" <[EMAIL PROTECTED]> * Package name: python-dsv Version : 1.4.0 Upstream Author : Cliff Wells <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/python-dsv/ * License : standard CNRI Python license Description : Python module for delimiter-separated-value files Python-DSV is an alternative to Python's standard csv module, with somewhat different usage and optional support for wxWidgets-mediated user interaction in the course of format autodetection. Like the standard module, it supports a wide range of delimiters and handles both import and export. I'm packaging this in the course of reviving bitpim's ITP (#265585). I will probably issue a single binary package, for Python 2.3, because that's all that python-wxgtk2.x supports anyway. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'sarge-unsupported') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ./configure in debian/rules
Frank Küster <[EMAIL PROTECTED]> writes: > Were can I read up on how and why I should do this? AFAIR, the policy /usr/share/doc/autotools-dev/README.Debian.gz has advice on how to run configure scripts sanely. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AT&T Korn Shell
"Josh Hurst" <[EMAIL PROTECTED]> writes: > Seems these libraries are statically linked. It may be worth to think > about providing shared library versions since there are many > applications which can use libshell and libast. For example AT&T > claims a 30%+ performance improvement for perl applications if sfio > (provided by libast) is used instead of stdio. There are sfio-dev and sfio2000 packages, though nothing in the archive appears to be built against them at present. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding dependencies to e2fsprogs: libdevmapperr, libselinux and libsepoll
Theodore Ts'o <[EMAIL PROTECTED]> writes: > Actually, because of the e2fsck-static package, e2fsprogs has to have > a build-depends on libselinux. There doesn't seem to be a way to say, > "except on non-Linux platforms" for a build-depends as far as I know, > unfortunately. Any suggested solutions? I believe Build-Depends: dpkg-dev (>= 1.13.12), libselinux-dev [linux-any], ... is supposed to work nowadays. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292572: ITP: praat -- program for speech analysis and synthesis
181 U+026F # É 182 U+FFFD # ï 183 U+FFFD # ï 184 U+0278 # É 185 U+01A5 # Æ 186 U+0253 # É 187 U+032F # Ì 188 U+0330 # Ì 189 U+0290 # Ê 190 U+1D0A # á 191 U+0153 # Å 192 U+02A2 # Ê 193 U+0318 # Ì 194 U+026C # É 195 U+028C # Êinduction [ÉnËdÊkÊÉn] 196 U+0263 # É 197 U+FFFD # ï 198 U+029D # Ê 199 U+02CC # Ëoligarchic [ËÉlÉËgÉËkÉk] 200 U+02C8 # Ëreversionary [rÉËvÉËÊnÉrÉ] 201 U+026B # É 202 U+200A # â 203 U+031F # Ì 204 U+2197 # â 205 U+2198 # â 206 U+025C # É 207 U+02A0 # Ê 208 U+0324 # Ì 209 U+033C # Ì 210 U+0281 # Ê 211 U+027B # É 212 U+025A # É 213 U+02DE # Ë 214 U+0295 # Ê 215 U+0284 # Ê 216 U+21BF # â 217 U+21C3 # â 218 U+030B # Ì 219 U+0301 # Ì 220 U+0304 # Ì 221 U+0300 # Ì 222 U+030F # Ì 223 U+0302 # Ì 224 U+030C # Ì 225 U+0306 # Ì 226 U+0303 # Ì 227 U+028D # Ê 228 U+027A # É 229 U+0270 # É 230 U+0302 # Ì 231 U+0265 # É 232 U+039B # Î 233 U+0302 # Ì 234 U+0256 # É 235 U+0257 # É 236 U+02E0 # Ë 237 U+02EC # Ë 238 U+0267 # É 239 U+025F # É 240 U+0127 # Ä 241 U+026D # É 242 U+0334 # Ì 243 U+030C # Ì 244 U+030C # Ì 245 U+0299 # Ê 246 U+0268 # É 247 U+0273 # É 248 U+0272 # É 249 U+02D0 # Ëshootingrange [ËÊuËtÉÅreÉndÊ] 250 U+0266 # É 251 U+0199 # Æ 252 U+0291 # Ê 253 U+029B # Ê 254 U+0255 # É 255 U+0288 # Ê -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Another load of typos
Florian Zumbiehl <[EMAIL PROTECTED]> writes: >> FLTK Please consider this ambiguous (like FAQ), as upstream favors the pronunciation "fulltick" (and makes a point of noting so on the main http://www.fltk.org/ page because a lot of users nevertheless do spell it out). Thanks. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#303609: ITP: libdata-dumper-perl -- stringified perl data structures, suitable for both printing and eval
Um, as far as I can tell, this module is already present in perl-base, and even at the correct version: $ dlocate -S /usr/lib/perl/*/Data/Dumper.pm perl-base: /usr/lib/perl/5.8.4/Data/Dumper.pm $ fgrep VERSION /usr/lib/perl/5.8.4/Data/Dumper.pm $VERSION = '2.121'; As such, I see no reason to package it separately. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck available again / filesystem shaked
Sven Luther <[EMAIL PROTECTED]> writes: > Just one question, how do we access the box if the .ssh directory has been > disabled ? AFAICT, it still consults LDAP (db.d.o) for authorized keys. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: namespace conflict != package Conflict?
Sebastian Kuzminsky <[EMAIL PROTECTED]> writes: > The cogito /usr/bin/git is a tiny little helper script hardly worth its > inode, but it's in the upstream package and I dont want to remove it or > rename it. As others have asked, why not? Does anything actually rely on the script existing by that name? At any rate, if you're absolutely dead set on keeping it, I suppose you could divert any preexisting instance of /usr/bin/git to, say, /usr/bin/git.not-cogito, and then have the script fall back to it when not called with one of the handful of supported first arguments: #!/bin/bash -norc cmd=git-$1-script if command -v "$cmd" >/dev/null 2>&1; then shift exec "$cmd" "$@" else exec -a "$0" /usr/bin/git.not-cogito "$@" fi (You'd likewise need to divert /usr/share/man/man1/git.1.gz, and perhaps add a pointer to the diverted manpage in your version.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.net brokenness?
Andres Salomon <[EMAIL PROTECTED]> writes: > I've discovered that I can no longer log into wiki.debian.net. When > visiting pages, it informs me that I'm AnonymousUser; when I try to edit a > page, it tells me that the web page doesn't not allow anonymous editing. > However, it doesn't provide a link to log in (or maybe I'm just missing > the link?). This makes it rather difficult to actually update wikis. AFAICT, you just need to follow the link labeled AnonymousUser and enter some other username... -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Running x86-64 debian inside i386 pbuilder on AMD64
Sander Marechal <[EMAIL PROTECTED]> writes: > Quick question: Do I only need the AMD64 linux-image package, or also > the linux-restricted-modules package? You need corresponding versions of whichever modules package(s) you currently have installed. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Sander Marechal <[EMAIL PROTECTED]> writes: > I don't think Debian should do that, but perhaps the process to install > them after the fact could be easier for people who are not full blown > Linux admins? Are you aware of module-assistant? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is lack of UTF support an RC bug?
Marcin Owsiany <[EMAIL PROTECTED]> writes: > It doesn't matter for ekg2, which will stay in experimental for quite a > while I'm afraid, but it is important for at least two other of my > packages (which are in etch) which don't support UTF-8 at all. And I'm > reasonably sure they are not the only packages in etch which don't > support UTF. Right; for instance, as noted in #229702/#236214, libfltk1.1 and its ~30 reverse-dependencies have the same limitation, which upstream won't address because doing so would break the ABI. > Don't get me wrong, I'm not against UTF-8, but just dropping everything > that doesn't support it, without a former warning, sounds ridiculous. Agreed. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc-4.2 build-depends?
[EMAIL PROTECTED] writes: > here. Also, the same solution should be used (eg. split the > package). The gcc-4.x packages are already set up to support building the Java and Ada compilers (and associated libraries) separately from the rest of GCC; however, there is no need to do so for 4.2 while it is still only in experimental. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Looking for a program which generates binary formats decoders from a high-level description
BitPim's protogen.py seems similar to what you're looking for; its canonical use is for making it easier to communicate with mobile phones (particularly BREW-based GSM models), but its packet description language should be rich enough to handle at least some of the examples you give as is. The resulting decoders (and encoders, should you have need of them) are in Python. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Looking for a program which generates binary formats decoders from a high-level description
Stephane Bortzmeyer <[EMAIL PROTECTED]> writes: > a message of 0 lines which said: ^ It wasn't quite that short. ;-) > It seems so, thanks, but it is hard to say because the file in > http://www.bitpim.org/pyxr/c/projects/bitpim/src/protogen.py.html > seems quite underdocumented. Any other documents you know? http://bitpim.svn.sourceforge.net/viewvc/bitpim/trunk/bitpim/dev-doc/packetdescription.txt?revision=3493&view=markup For further examples, you can also look at any of bitpim's *.p files (under src/phones in the source tree, and installed in /usr/share/bitpim/code/phones). You should also be able to ask questions on the bitpim-devel mailing list; only subscribers may post, but volume's pretty low. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL question
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Sat, Mar 25, 2006 at 06:24:50PM +0100, Arthur de Jong wrote: >> On Wed, 2006-03-15 at 14:06 -0800, Thomas Bushnell BSG wrote: >> > The resolution which passed excludes documentation with front cover >> > texts. Read it. >> >> I re-read it, and it states: >> | This means that works that don't include any Invariant Sections, Cover >^ >> | Texts, Acknowledgements, and Dedications (or that do, but permission > ^ >> | to remove them is explicitly granted), are suitable for the main >> | component of our distribution. > > That includes both front- and back-cover texts. Perhaps Thomas meant "excludes from main" rather than "excludes from eviction." -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First AMD64 Binary Uploaded
Yee-ha! This makes a wonderful (if moderately belated) first birthday present for my em64t workstation. :-) One question, though: what's the contact address for the new buildd's administrators? I tried [EMAIL PROTECTED] (to call #359023 to their attention), but it bounces. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: First AMD64 Binary Uploaded
Kurt Roeckx <[EMAIL PROTECTED]> writes: > I've requested the binNMU to be done, it should probably get > build tomorrow somewhere. Thanks. > For now I suggest you contact [EMAIL PROTECTED] OK, thanks; I considered that, but wasn't sure it was focused enough. (Granted, -devel isn't that focused either, but it is more developer-oriented.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#360163: ITP: libannexlib-ocaml -- Library of miscellaneous OCaml code
Ewan Mellor <[EMAIL PROTECTED]> writes: > Do I need to do anything to the ITP to reflect this, or should I > just close it any start again? I'd say it's sufficient, and not even strictly necessary, to retitle the bug. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 uploads
Aurelien Jarno <[EMAIL PROTECTED]> writes: >> kid3 > > This one dep-wait on the wrong package. Yeah, the dep-wait should be dropped to reflect the recent upload. Speaking of dep-wait, there appear to be a few bugs whose fixes would probably clear out most of http://buildd.debian.org/stats/?arch=amd64&state=Dep-Wait : atlas3 bug #351646 (needs tweaking for new make) gdal bug #360389 (bad cast, fix pending since Tuesday) ruby1.9 bug #321316 (needs less optimization or [AFAICT] new upstream) wxwidgets2.6 bug #350695 (FTBFS with new make, fix "pending" for months) wxwindows2.4 bug #350696 (likewise) A lot of the others simply need to desupport old versions of Python. > I also noticed cpuburn has not been rebuilt, probably because it is > listed i386 only in Package-Arch-Specific, whereas the amd64 team was > probably using another version of this file. Likewise for mindi and mondo, at least. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: id gives conflicting results
Russ Allbery <[EMAIL PROTECTED]> writes: > I wonder if the weird AFS PAG hack is corrupting the process group list in > some way. It would be the first time I'd heard of that problem if so, but That's quite possible, as I've observed similar behavior on my amd64 machine (but neglected to report it previously). To wit, my regular user account is a member of group adm, and id(1) confirms so, but the kernel reports EPERM on log files that only group adm can read when I have a PAG. :-/ -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: small quirks setting up a cross-compile toolchain
Tyler MacDonald <[EMAIL PROTECTED]> writes: > Has anybody else run into this? Is there something I can do that's > cleaner and closer to The Debian Way than manually making symlinks? Install the Debian toolchain-source package and go from there. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Version woes (packaging SWT milestones)
Shaun Jackman <[EMAIL PROTECTED]> writes: > it must start with 3.0.x. Perhaps 3.0.3.1M4? Ugly. Any thoughts? Post-sarge, I believe 3.1~m4 should work. For now, I'd probably call it 3.0+3.1m4, which is slightly less ugly IMO than having dots throughout. (I've used a similar notation for FLTK prereleases.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#194515: ITP: debdivert -- Debian packaging aid to create patch packages
Andreas Metzler <[EMAIL PROTECTED]> writes: > I still don't get why you wouldn't simply generate a modified version > and install it _instead_ of the original package, unless foo also > include a switch-debdivert-foo package that enables to choose to > switch to officila package faster than 'dpkg -i official.deb' I can kind of see this. If your modified version has the same name as the original, you might end up accidentally upgrading to a version without the desired changes. On the other hand, if it has a different name, it cannot be a full substitute because dpkg still doesn't support versioned provides. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Debian conference in the US?
Russell Coker <[EMAIL PROTECTED]> writes: > I don't assume that everyone agrees, just the 49.X% that voted for him. This figure is not as meaningful as it might seem; we still use a non-preferential voting system, in which votes for non-mainstream candidates are effectively wasted. :-/ > The most amusing thing was that no USian even bothered to ask me > whether I am implementing such a boycot myself, they just made their > assumptions and jumped into the flame-war. Toward the beginning of the thread, I specifically asked who would actually be unwilling to show up, as opposed to merely knowing other developers with that stance. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Orphaning my packages
David Nusinow <[EMAIL PROTECTED]> writes: > Another point of note is that nascent packagers are encouraged to adopt > other software that's already in the archive before packaging new > items. In this case, he is merely following that advice. Granted. OTOH, applications may be a better place to start, inasmuch as they are easier to deal with in many respects and accidentally breaking them may not necessarily affect anything else (though it obviously depends on the program in question). > - David Nusinow Any relation to the Nusinoviches? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: buildd failure
Attila SZALAY <[EMAIL PROTECTED]> writes: > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) Hm, http://buildd.debian.org/build.php?arch=&pkg=libzorpll seems to indicate that the hppa autobuilder never attempted 2.0.26.4-1 for some reason. Try building it yourself in paer's sid chroot? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: aptitude borked [was: Re: Fun with python-apt]
"David A. Greene" <[EMAIL PROTECTED]> writes: > guarantee it will work because it seems as though apt thinks > apt-listchanges is still installed. This is a matter of configuration files; try purging apt-listchanges, and if that doesn't work remove /etc/apt/apt.conf.d/20listchanges yourself. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: package descriptions dummy/transitional
Bernd Eckenfels <[EMAIL PROTECTED]> writes: > Is there a way I can get a list of those "you can remove it safely after > upgrade (if no others depend on it)" packages? deborphan --guess-dummy --guess-only tries to do this, and automatically filters out packages that you can't yet remove. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: kernel 2.5.73+, fakeroot, debuild - a small problem
Marek Habersack <[EMAIL PROTECTED]> writes: > 2. Modify fakeroot to check the kernel version, the type of fs on which it > is currently working and have it issue a sysctl to enable > restricted_chown. It looks better than #1 but it might incurr Er, is this even possible as an ordinary user? > 5. Influence the XFS/kernel maintainers to change the default value of > restrict_chown to enabled. I agree that this is the best solution. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Accepted java-gnome 0.8.0cvs20030627-1 (source)
If you're going to leave out any architecture-specific packages from your uploads, please still include at least the arch-all packages, since the autobuilders skip them. Thanks. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Debootstrap, Sid, and console-tools-libs
"Matthew P. McGuire" <[EMAIL PROTECTED]> writes: > E: Couldn't download console-tools-libs You need a newer version of debootstrap; it looks like 0.1.17.29 corrects console-tools-libs to libconsole. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
problem setting up interlibrary dependencies
I'm running into difficulties getting vibrant6 [1] to comply with the new policy requiring full inter-library dependencies. The source of the complication is that two of the libraries come in OpenGL and non-OpenGL variants, but certain intervening libraries are OpenGL-agnostic and therefore come in only one variant. Since OpenGL is a pretty hefty dependency, I'd like to avoid it if possible, and not have the intermediate libraries indirectly require it; on the other hand, the GL-enabled variant of the higher-level library (ncbicn3d) specifically needs the GL-enabled variant of the lower-level library (vibrant) in order to work properly. I would also like for packages that request linkage against plain vibrant not to end up depending on the GL variant, even if built on systems with the GL variant installed. (On the other hand, packages that specifically try to link against the GL variant should get it) I haven't quite been able to come up with a reasonable arrangement that satisfies all of these constraints. The closest I've come up with so far falls apart the moment ldconfig runs: BASELINE: libvibrant-nogl.so.6.1.: real file, soname libvibrant.so.6 libvibrant-nogl.so.6 -> libvibrant-nogl.so.6.1. [libvibrant-nogl.so -> libvibrant-nogl.so.6.1.] [libvibrant.so -> libvibrant-nogl.so] WITHOUT libvibrant6-gl: libvibrant.so.6 -> libvibrant-nogl.so.6 WITH libvibrant6-gl: libvibrantOGL.so.6.1.: real file, soname libvibrantOGL.so.6 libvibrantOGL.so.6 -> libvibrantOGL.so.6.1. [libvibrantOGL.so -> libvibrantOGL.so.6.1.] libvibrant.so.6 -> libvibrantOGL.so.6 (clobbered by ldconfig :-/) I could perhaps kludge around this by having libvibrant6-gl also contain a dummy library with a soname of libvibrant.so.6 that pulls in libvibrantOGL.so.6 and sorts after libvibrant-nogl.so.6.1., but that would be gross, and lead to odd-looking ldd output. Any suggestions? Should I just punt and force everyone to use the OpenGL version? (That would certainly be simplest, but I'd really prefer to avoid the dependency bloat if I can.) [1] I am simultaneously renaming the package to libvibrant6, so please refrain from commenting on its archaic name. ;-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: problem setting up interlibrary dependencies
Steve Langasek <[EMAIL PROTECTED]> writes: > So to restate, you have two libraries which export similar ABIs, but not > identical; the GL-enabled version of the library exports additional > entry points which are only of use to a subset of callers. You want to > supply distinct .so links for each library, so that at build-time a > program can clearly specify which variant it wishes to link against; and > you don't want to drop the non-GL variant, because OpenGL is a hefty > dependency for those who don't need it. Right. I would moreover like for the GL variant to supersede the non-GL variant when both are installed, since that's what the GL-neutral higher-level libraries will be linking against. The way this worked up to now was that the only library dependencies were on libc, with both variants residing in a single package that did not depend on libGL(U); applications using the higher-level libraries would have to link explicitly either against the non-GL variant or against the GL variant and libGL(U). > 1) Divide the library into two parts: one which provides the non-GL > functions, and one which provides *only* the GL functions. This This would definitely be a pain, given that the two variants are built from the same sources, just with different #defines. > 2) Continue to ship complete versions of each library, tagging each with > a unique soname and keeping their associated filenames entirely > separate. If someone wants the non-GL version, they link with > -lvibrant; if they want the OpenGL-enabled version, they link with > -lvibrant-gl. Disadvantage: if you have a higher-level library that > would use the non-GL version of the library, and an application that > would use both this higher-level library and libvibrant-gl, you would > have both libvibrant and libvibrant-gl loaded into memory, which > probably won't work too well unless you implement symbol versioning as > well. Right, though I think I want the *opposite* of what symbol versioning would give me: if the GL variant shows up at runtime in any fashion, the process should not use any symbols from the non-GL variant, even if it pulls it in indirectly. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Using reportbug with Gnus
Marcus Frings <[EMAIL PROTECTED]> writes: > | Symbol's function definition is void: gnus-agent-possibly-save-gcc Confirmed; FWIW, I have reportbug 2.20, emacs21 21.3-1, and gnus 5.10.2-3. > Okay, I read man reportbug, I read /usr/share/doc/reportbug/ and I looked > in /usr/share/reportbug/ where `gnus-agent-possibly-save-gcc' could have > been used but nowhere I found this option to be used/set. The call seems to be from within Gnus, which I guess doesn't quite manage to load properly: Debugger entered--Lisp error: (void-function gnus-agent-possibly-save-gcc) gnus-agent-possibly-save-gcc() run-hooks(message-header-hook) message-send-mail(nil) message-send-via-mail(nil) message-send(nil) message-send-and-exit(nil) call-interactively(message-send-and-exit) Adding (load "gnus-load" t) to the top of /usr/share/reportbug/reportbug.el fixes it, at least on my system. Incidentally, you might also be interested in debbugs-el, which provides a nice report-debian-bug command. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Using reportbug with Gnus
Peter S Galbraith <[EMAIL PROTECTED]> writes: > That would be `M-x debian-bug'. :-) Oops, so it would; I crossed it with report-emacs-bug. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Future releases of Debian
Nick Lopez <[EMAIL PROTECTED]> writes: > The reason I havn't offered them for general Debian machines is that there > are already (generally better) machines available on better connections. Last I checked, there weren't any public mips or mipsel machines. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Future releases of Debian
Karsten Merker <[EMAIL PROTECTED]> writes: > There is an official mips system available to all developers (casals.d.o). Oh, cool, I must have missed that announcement. > If you need stuff tested on a mipsel system in the meantime, please send me > an email and I will try to get account on another mipsel system for you. Nah, no rush. Thanks, though (and thanks to Noah for actually making it happen ;-)). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: debconf 2005 in Vienna, Austria
Joshua Kwan <[EMAIL PROTECTED]> writes: > Feh, we need one in the States... I'm totally raring to go to a debconf > in the states, but there is a severe lack of $ (and parental permission) > with regards to going to one in europe :( Don't worry; as far as I know, the proposed conference in DC next spring I asked about a few weeks ago is still planned. Meanwhile, I doubt I'd make it to anything in Vienna, but I'm fine with people meeting there, or anywhere else they can find critical mass. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: package name change (moviemate -> mediamate)
Sean 'Shaleh' Perry <[EMAIL PROTECTED]> writes: > you should Conflict, Replace, and provide MovieMate. This will ensure a > smooth transition. You instead (may) want to upload a package called > moviemate which is a dummy package that depends on MediaMate. I'd say "as well as" rather than "instead," though of course you'll need to limit the conflict to pre-transition versions so that the dummy package is actually installable Otherwise, yeah, just make the change as smooth and transparent as you can. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: package name change (moviemate -> mediamate)
"Jamin W. Collins" <[EMAIL PROTECTED]> writes: > I was thinking about the dummy package approach, but then the dummy > package would just hang around indefinitely, right? Well, until the user removes it; the description usually hints at that, and deborphan will also optionally point out dummy packages you can safely remove. At any rate, having a dummy package installed isn't a big deal; they aren't exactly huge. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Bug#205471: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]
Julian Gilbey <[EMAIL PROTECTED]> writes: > I really like this idea, thank you! I will accept directory names Thanks. :-) > matching the regexp /^$package(-.*)?$/ - does that seem reasonable? Yep, though I might change the * to a +. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: [rene@debian.org: Bug#205471: devscripts: running debuild could lead to deleting _all_ backup dirs/files on the system]
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > I do have the following four cases: > > > > It should definitely allow package-upstreamver, since that's more or less canonical. However, generalizing a bit and simply checking that the name of the directory starts with the name of the source package would allow your other cases while still avoiding things like $HOME (unless your username happens to match the package name, but that's probably too much of a corner case to worry about). BTW, no need to Cc: me. (No big deal, though.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Accepted fltk 1.0.11-11.1 (i386 source all)
Congratulations, you've just broken binary compatibility by (implicitly) rebuilding with G++ 3.3. I'm preparing a new NMU that switches back to G++ 2.95 (except on IA64, which needs 2.95, and HPPA, which needs 3.0). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Accepted fltk 1.0.11-11.1 (i386 source all)
Andrew Suffield <[EMAIL PROTECTED]> writes: > So what you were saying is, the package could not be built from source > correctly anyway, and he only fixed one of the two bugs? Right. (Emphasis on "correctly" -- the build did nominally succeed.) > That's an independant bug; why was it not filed when g++ 3 became the > default? Good question. Lameness? At any rate, I have uploaded an -11.2 which should (I think...) restore sanity and keep -11.1 from making it out of incoming. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: where to install additional kernel modules?
martin f krafft <[EMAIL PROTECTED]> writes: > Where then should comedi install itself? comedi drivers are for data > acquisition cards. /lib/modules/VERSION/misc? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: where to install additional kernel modules?
Christoph Hellwig <[EMAIL PROTECTED]> writes: > no. that's wrong for 2.4+ kernels. Interesting, as it seems to be the status quo; I have a bunch of modules in /lib/modules/2.4.21/misc (from four different modules packages produced via make-kpkg), which incidentally all seem to load fine. No need to Cc me, BTW. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Bug#208313: RFA: alsa-xmms -- ALSA 0.9 output plugin for XMMS
Package: wnpp Severity: normal Since I hardly ever listen to music on my computer these days except when testing this package, I should probably hand it over to somebody who uses it more actively. It's pretty low maintenance(*), so I'm content to keep it indefinitely; OTOH, that also means that interested parties need not worry much about load. I am willing to serve as sponsor for any prospective developer who wishes to take the package over. (*) I've had to upload a new (Debian or upstream) version roughly once every three weeks on average, and the changes between versions have generally been fairly small. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Where are we now? (Was: Bits from the RM)
Stephen Frost <[EMAIL PROTECTED]> writes: > Or, alternatively, this was the only crappy NMU that was noticed while > quite a few others were made against ancient packages with inactive > maintainers who didn't notice or didn't care. I'm not terribly > interested in going through all the NMUs done and attempting to prove > this but I find it more likely than the possibility that only one poor > NMU was done during that period. No, you're not alone; I got to clean up after an overly hasty NMU of fltk 1.0.x that switched to G++ 3.x without adding c102. (I must admit, however, the package was asking for trouble by neither forcing the right [older] compiler version nor even carrying a warning about the situation in the BTS.) Fortunately, I was able to react in time to keep that NMU from advancing beyond incoming. Nevertheless, I feel that the 0-day NMU period generally went quite well. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Who needs libcurl3?
Domenico Andreoli <[EMAIL PROTECTED]> writes: > unfortunately heimdal bug #316980 makes curl FTBS :( :-/ Can you use MIT krb5 instead? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIT krb5 vs. Heimdal for curl's GSSAPI support (Re: Who needs libcurl3?)
Domenico Andreoli <[EMAIL PROTECTED]> writes:
> i'm not a kerberos guru, i never used it and probably i will never be
> interested in it. i added this package only after a debian user asked
> for GSSAPI support in curl (FYI bug #241553).
Got it. :-)
> anybody knows if curl will modify its behaviour switching to MIT krb5?
It oughtn't, though it looks like you need to edit debian/rules in
addition to debian/control:
diff -u curl-7.14.0/debian/control curl-7.14.0/debian/control
--- curl-7.14.0/debian/control
+++ curl-7.14.0/debian/control
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Domenico Andreoli <[EMAIL PROTECTED]>
Uploaders: Matthias Klose <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>> 3.0.0), autotools-dev, binutils (>= 2.14.90.0.7),
libssl-dev, zlib1g-dev, stunnel, heimdal-dev [!hurd-i386], libidn11-dev,
groff-base, libdb4.2-dev
+Build-Depends: debhelper (>> 3.0.0), autotools-dev, binutils (>= 2.14.90.0.7),
libssl-dev, zlib1g-dev, stunnel, libkrb5-dev [!hurd-i386], libidn11-dev,
groff-base, libdb4.2-dev
Standards-Version: 3.6.1
Package: curl
diff -u curl-7.14.0/debian/rules curl-7.14.0/debian/rules
--- curl-7.14.0/debian/rules
+++ curl-7.14.0/debian/rules
@@ -46,7 +46,7 @@
ifeq (${DO_GSSAPI},yes)
mkdir -p debian/build-gssapi
- cd debian/build-gssapi && ../../configure ${CONFIGURE_ARGS}
--with-gssapi-includes=/usr/include --with-gssapi-libs=/usr/lib
+ cd debian/build-gssapi && ../../configure ${CONFIGURE_ARGS}
--with-gssapi=/usr
endif
touch configure-stamp
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: todos: command not found
João Silva <[EMAIL PROTECTED]> writes: > Anyone knows what package brings the todos command? $ apt-file search bin/todos sysutils: usr/bin/todos -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-proxy
Brian May <[EMAIL PROTECTED]> writes: > However, I prefer the approach over apt-cacher, as the apt-sources > entries remain independent of the server that will be used to retrieve > the files. I originally kept away from apt-cacher for exactly that reason, but it now (as of version 1.0.6) supports a path_map directive that allows for symbolic names. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possible mass bug filing: missing shared library dependencies
Neil Williams <[EMAIL PROTECTED]> writes: >> Aaron M. Ucko <[EMAIL PROTECTED]> >>libncbi6-dev > > (Just a sample of the -dbg and -dev packages) This was genuinely buggy (oops), as it ships a couple of utilities alongside the other content; I've just uploaded a fixed version. Thanks for bringing it to my attention, Niko! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to hijack gtkglext
William Pitcock <[EMAIL PROTECTED]> writes: > I've already prepared an upload for this. It should hopefully go > sometime today. Great; thanks for taking it off my DDPO page. ;-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Looking for co-maintainer for mercurial
[migrating to -curiosa] Julian Andres Klode <[EMAIL PROTECTED]> writes: > BTW, I think that hg is now the only VCS package which is not maintained in > its > own VCS format. (or are there other packages, too?) $ apt-cache showsrc rcs | grep Vcs Vcs-Browser: http://git.debian.org/?p=users/rfrancoise/rcs.git Vcs-Git: git://git.debian.org/git/users/rfrancoise/rcs.git I can't say I entirely blame its maintainer, though. ;-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#467097: ITP: eficas -- ASter Command FIle Editor
Sylvestre Ledru <[EMAIL PROTECTED]> writes: > What do you want me to put as an author ? Electricité de France would be > OK ? In that case, I might give both the current legal form and a clarifying comment: EDF S.A. (historically named Electricité de France) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: where to register TeX related software with doc-base?
Ralf Treinen <[EMAIL PROTECTED]> writes: > Sorry if this has been answered before, but looking at section 2.3.3 of > the doc-base manual (version 0.8.10) I cannot find a section TeX. If > memory serves me right we used to have a section "tex", at least I > used to register the docs of some my TeX-related packages there :-) > Has this section been removed on purpose? If yes, where should > TeX-related documenation go now? Good question; with the currently declared hierarchy, I'd suggest Programming/TeX, but I acknowledge that that's still not entirely intuitive. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Default value for CFLAGS/LDFLAGS set by dpkg
Kurt Roeckx <[EMAIL PROTECTED]> writes: > I also have to wonder that if we have something like this as default, > why -Bsymbolic-functions would be a good default, and not -Bsymbolic. It's also worth noting that the original proposal ( http://lists.debian.org/debian-devel/2007/12/msg00090.html ) gave testing -Bsymbolic-functions as a potential use case, but *NOT* as an actual proposed default (at least AFAICT). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Specification for the 'Bugs' field in 'debian/control'
Ben Finney <[EMAIL PROTECTED]> writes: > I don't want to just guess based on existing packages and hope I get > it right. Where can I find the specification for this 'Bugs' field? deb-control(5): Bugs: The url of the bug tracking system for this package. The current used format is ://,like deb- bugs://bugs.debian.org. You might also find /usr/share/doc/reportbug/README.developers to be of interest. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Correct way to rename a binary package
Luca Capello <[EMAIL PROTECTED]> writes: > Package: hunchentoot > Version: 2.0 > Provides: cl-hunchentoot [1] > Replace: cl-hunchentoot (<< 2.0) > Conflicts: cl-hunchentoot (<< 2.0) > > Package: cl-hunchentoot > Depends: hunchentoot > > Am I correct? I believe so, modulo one typo (Replace: vs. Replaces:). Thanks for taking care to allow a smooth transition. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#538202: ITP: virt-what -- detect if we are running in a virtual machine
Laurent Léonard writes: > Description: detect if we are running in a virtual machine What does it offer over the existing imvirt package? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.2
Bastian Blank writes: > What happens if someone install libc-bin without a new libc6 then? At present, I would expect that to run into file conflicts with libc6. In the future, yes, that could be a problem without appropriate Breaks: or Conflicts: declarations. :-/ One possible workaround could be to follow gtk+-2.0's lead: keep the actual binaries in the lib package, but place them under /usr/lib and have the bin package just ship symlinks to them. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#543150: ITP: pdkim -- cryptographically identify the sender of email
Magnus Holmgren writes: > * Self-contained, no dependencies (except libc), thanks to code included > from the PolarSSL project. >From a Debian perspective, that's a policy violation, not a feature! Please arrange for it to use an external PolarSSL installation. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556643: ITP: togl -- a Tk OpenGL widget
Christophe Trophime writes: > The license states that "Modifications to this software may be copyrighted by > their authors > and need not follow the licensing terms described here, provided that > the new terms are clearly indicated on the first page of each file where > they apply.". Does it mean the it is not DFSG? No, it just means that it's not under the GPL or another "copyleft" license. http://togl.cvs.sourceforge.net/viewvc/togl/Togl/LICENSE?revision=1.3&view=markup looks like a typical MIT- (or modern BSD-) style license to me; the portion you quoted is simply a reminder that it's legal to produce non-free derived works. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#412570: ITP: fldigi -- digital modem program for hamradio operators
Benjamin Seidenberg <[EMAIL PROTECTED]> writes: > I would suggest adding a word about the interface - is it a GUI or > console program? FLTK is a GUI toolkit. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] AMD64 specific bug on libblitz0 (#424644)
Andreas Tille <[EMAIL PROTECTED]> writes: > The AMD64 package was builded by a sid autobuilder and if ... last week, with g++-4.1 4.1.2-5, which still had #421790. > I did understand the thread correctly the problem should > not happen, right? It should not happen with the version of g++-4.1 *currently* in sid, but last week's version is another matter entirely. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] AMD64 specific bug on libblitz0 (#424644)
Andreas Tille <[EMAIL PROTECTED]> writes: > That means if I would ask for a binary only upload for AMD64 this bug > would be fixed? I believe so. > How can I ask for this? Per http://zomers.be/~luk/blog/content/binNMU.html , simply email a rebuild request to debian-release. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is Ron Lee MIA? (was Re: wxwidgets2.8)
Bart Martens <[EMAIL PROTECTED]> writes: > Thanks for explaining why filezilla is not yet updated. If you have the > time, you might want to offer help to the maintainer of wxwidgets2.6: Likewise, bitpim has moved to 2.8 upstream, forcing me to hold back or backport various GUI-related changes on their part, so I'd also greatly appreciate seeing wxWidgets 2.8 in Debian. However, I am concerned that its maintainer (Ron Lee) may have gone altogether MIA, as I see no indication of Debian-related activity on his part since the end of February; has anyone seen any sign of him since? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ron Lee MIA?
"Paul Wise" <[EMAIL PROTECTED]> writes: > I exchanged a couple of emails with him about GPG signing in April. Good to know; apologies for the false alarm. > I'm thinking there needs to be a co-maintainence team for wxWidgets, > and ron seems open to the idea. Sounds reasonable, though I'm spread too thin already to participate myself; wxWidgets is rather large and popular for anyone to take on solo, even with close ties to upstream. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#480563: Doesn't strip binary NMU version (+b1, +bN etc.) when reporting bugs
"Sandro Tosi" <[EMAIL PROTECTED]> writes: > I'm more inclined to Chris' position (not strip because binNMU can > introduce bugs not present in previous version) but DDs more > experienced than me can have a wider view and a different opinion. I'd tend to agree -- better to err on the side of sending extra information, which the BTS can presumably at least arrange to ignore for the time being if fully handling it is too involved. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Available papersizes vs. default papersizes
Frank Küster <[EMAIL PROTECTED]> writes: > I would like to solve a long-standing bug and finally make TeX aware of > libpaper and its system-wide paper size setting. Thanks; I, for one, would greatly appreciate that. > However, taking the intersection of paper sizes the different program's > configuration files accept as default, I end up with a4paper and letter. AFAICT, those are also the only two sizes that standard locales use, so I don't think supporting any others is particularly crucial (though Johannes's suggestions are worth considering if you want to widen the set slightly). -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need g++-3.4 package in lenny
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > I need older gcc and g++ as I have a lot of iostream.h in my code. If that's the only consideration, you should be able to use 4.1 and 4.2, both of which exist in lenny. That said, I would echo others' advice to port to the modern .h-less headers; iostream.h predates the standard, and has been deprecated for years. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: postinst-has-useless-call-to-ldconfig with a -dev package because of .so development files ?
Xavier Roche <[EMAIL PROTECTED]> writes: > I suppose that dh_makeshlibs adds it because of .a/.so devel files > being placed in /usr/lib (?) More likely because of the private shared libraries in /usr/lib/httrack/libtest. > Is there a clean way to prevent that ? dh_makeshlibs -X/usr/lib/httrack/libtest -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Changelog and patche
"Sandro Tosi" <[EMAIL PROTECTED]> writes: > You can ask lintian to be more verbose, adding -v option to its call. I'd suggest -i, as -v merely traces lintian's activity in more detail. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (UPDATED) mass bug filing for undefined sn?printf use
Kees Cook writes: > Aaron M. Ucko >ncbi-tools6 Not any more; I uploaded a fixed version (6.1.20080302-4) more than a week ago, and it's even propagated to lenny because the release team honored my request to unblock it. (Thanks!) I just hadn't previously bothered replying to the thread, even privately. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#512834: ITP: ocaml-autoconf -- autoconf macros for OCaml
Adeodato Simó writes: > Package: autoconf-archive I agree that that makes sense as a long-term location. If you're impatient, perhaps you could (temporarily?) add it to ocaml-tools. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to track down the data of package installations
That sounds like the xfwm4/gtk-2.12 deadlock fixed in xfwm4 4.4.1-3, which evidently hasn't actually made it into testing yet despite its high urgency. :-/ -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Although this is an interesting idea, I have misgivings about running even temporarily with any sort of extra privileges; C++ executables in particular may run a fair bit of code from static objects' constructors before main() ever starts. I would counter-propose introducing some sort of ELF tag that ld could set and the kernel and ld.so could check; while this would be more involved, it would be less hackish and would avoid introducing new potential vulnerabilities. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Steve Langasek <[EMAIL PROTECTED]> writes: > There are no extra privileges; noptrace is intended to be a group that owns > no files other than the sgid binaries, can write to none of them, contains > no users, is unable to ptrace any other processes that it couldn't already, > and doesn't grant privileges to kill any processes that the user couldn't > already kill. It's an extra group membership, but where do you see extra > privileges here? The key word is "intended" -- I can easily envision situations in which group-noptrace-writable files exist, either due to inconsistent uid/gid mappings across filesystem boundaries or due to executables accidentally winding up mode 2755. To be sure, both are corner cases and arguably operator error, and exploiting them requires additional bugs, but why take the chance? Furthermore, it would be nice to be able to create a protected executable for personal use without having special privileges, or to be able to mount a filesystem nosuid without losing process protection. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using sgid binaries to defend against LD_PRELOAD/ptrace()
Martin Pitt <[EMAIL PROTECTED]> writes: > That would be ideal, of course. Does ELF support anything like that? AFAICT, it should be possible to use a custom .note.* or .gnu.* section for such purposes. I'm not an ELF expert, though. > P.S. Please honour m-f-t, thanks. Sorry about that; I read most debian lists via GMANE, and have not yet worked out how to tweak Gnus to honor it automatically. I'll try to keep an eye out, and have taken care to include you directly on this reply. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT: Errors when replacing syslog by syslog-ng
Frans Pop <[EMAIL PROTECTED]> writes: > OK, but why are there _two_ identical messages for both klogd and anacron? Probably once for the real package "sysklogd" and once for the virtual package "system-log-daemon", since the dependencies explicitly list both. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: XMMS doesn't like itself much...
As the erstwhile alsa-xmms maintainer, I can officially confirm Cameron's explanation: the latest upstream XMMS version (1.2.8) incorporates the ALSA plugin itself, so there's no longer any need for a separate package and you should go ahead and remove the obsolete alsa-xmms package in favor of the new xmms version. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: XMMS doesn't like itself much...
Matt Bonner <[EMAIL PROTECTED]> writes: > Thanks! I was wondering if it wouldn't have been clearer to say > that XMMS 1.2.8 Provides alsa-xmms instead of saying alsa-xmms > Conflicts with xmms. Any thoughts? xmms both provides and conflicts (with) alsa-xmms; dselect just only chooses to mention the latter relationship, at least on that screen. I agree that its interface could be better, and personally favor aptitude; however, it doesn't have explicit conflict-resolution screens at all. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: XMMS doesn't like itself much...
Matt Bonner <[EMAIL PROTECTED]> writes: > Amazing. dselect managed to mention 4 relationships, but not that one. > "There has to be a beter way..." Erm, actually, I just took another look at your original mail and saw the provides line at the bottom. Still, I would suggest giving aptitude a try. BTW, debian-user might have been a more appropriate list. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Changes in t1lib.
"Artur R. Czechowski" <[EMAIL PROTECTED]> writes: > I changed the naming scheme. All binary packages contain version in its > name, i.e.: t1lib-dev is now named t1lib1-dev. Of course old packages are If you're renaming them anyway, why not follow Policy 8.1 and s/t1lib/libt1-/ (yielding libt1-1, etc.)? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Changes in t1lib.
"Artur R. Czechowski" <[EMAIL PROTECTED]> writes: > And last but not least: upstream name is t1lib. I do not like to change it > until it is really needed. Fair enough; that's probably the best argument. (I similarly resisted renaming alsa-xmms to xmms-alsa because I felt it would be better to keep the upstream name.) At any rate, only the ftpmasters can raise binding objections; since they evidently didn't, I will let it drop and wish you (and the packages) well. -- Aaron M. Ucko (Ucho, historically, AFAICT.)
Re: Victory Abah
"Quinn, Ryan PO" <[EMAIL PROTECTED]> writes: >I am writing you in response to an E-mail I got from a Mr. Victory Abah. > He said he wants to transfer some money to one of my accounts. I looked him > up on the web and the only thing I got from him was the request to transfer > 152 million dollars to your account. Is this a guy ligit, did you pursue > this? The offer is almost certainly a scam; please see <http://www.ftc.gov/bcp/conline/pubs/alerts/nigeralrt.htm>. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Bug#221492: ITP: smile -- [Biology] Find statistically significant patterns in sequences
Steffen Moeller <[EMAIL PROTECTED]> writes: > * URL : http://www.example.org/ > * License : none *cough* > Description : [Biology] Find statistically significant patterns in > sequences This should be an uncapitalized noun phrase: perhaps something like "tool to infer structured motifs in biological sequences" > SMILE inferences structured motifs from multiple DNA or protein > sequences. The extraction is made according to multiple > criteria given by the user. Since version 1.4, SMILE accepts extractions > on any kind of sequences written on any alphabet, searching for motifs > on any alphabet that may even be degenerated. This could also use some rephrasing: how about SMILE infers structured motifs from multiple DNA or protein sequences according to a user-specified set of criteria. It handles arbitrary sequence alphabets, which may even be degenerate. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Henning Makholm <[EMAIL PROTECTED]> writes: > doesn't seem to be available in a documented way to people who have > their own $HOME/.fvwm2rc) FTR, you can do something like this: Read /etc/X11/fvwm/menudefs.hook AddToMenu Applications "Applications" Title + "&Debian" Popup "/Debian" + "" Nop + "X&term"Execxterm + "&uxterm" Execuxterm + "X&calc -rpn" Execxcalc -rpn + "&Galeon" Execgaleon -- Aaron M. Ucko, who'd be happy to hack together converters if he had reason to believe it would put an end to this perpetual bickering.
Re: recovery status update
Julian Gilbey <[EMAIL PROTECTED]> writes: > It makes a lot of sense to restrict auric permanently and have an > up-to-date mirror for general access purposes. The issues I can think > of are: Although I agree that there is definitely something to be said for this approach, I would like to note an additional issue with it: - how to verify that katie will process uploads as expected (I'd been running dinstall -n, via dput -D; I suppose it would be possible to upload separately to the mirror and test there, but that's awkward.) > - how to run the DELAYED queue Extra ftp upload directories? sftp access to the full queue area? > - how to give developers the possibility of seeing what's in the queue I believe http://incoming.debian.org/ is functioning as usual (though it's a bit hard to tell shortly after a dinstall run ;-) ). Other queues, especially queue/new, can also be interesting to inspect, but mirror delay there would hardly be the end of the world. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: recovery status update
Josip Rodin <[EMAIL PROTECTED]> writes: > On Tue, Dec 09, 2003 at 03:37:55PM -0500, Aaron M. Ucko wrote: >> - how to verify that katie will process uploads as expected (I'd been >> running dinstall -n, via dput -D; I suppose it would be possible to >> upload separately to the mirror and test there, but that's awkward.) > > Seems to me that, with proper checks before upload and a properly done > upload itself, dinstall -n is superfluous. I can't remember when was the > last time I got my stuff rejected by e.g. a competing upload, mistaken > number, or anything like that... And even if something does get rejected, > you only have to wait around five minutes to find out. Hm, yeah, I must admit that there's much less call for this now that automatic feedback occurs every 15 minutes rather than only once a day. >> I believe http://incoming.debian.org/ is functioning as usual (though >> it's a bit hard to tell shortly after a dinstall run ;-) ). Yep. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: recovery status update
Clint Adams <[EMAIL PROTECTED]> writes: > - how to run madison and wanna-build I thought the idea was for the unrestricted mirror to include a read-only copy of the database madison consults. wanna-build presumably needs more real-time access, though. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
