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: 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#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: 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: 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: 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: 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: 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.
Re: pthread + malloc = segfault
kai stammerjohann <[EMAIL PROTECTED]> writes: > i compile the app (contains c and c++ files) with "gcc -g -O0 -lstdc++ > -lpthread ..." > (the code works under windows and multithreaded c++ libs, so there aren't any > faults in the code) Either that or you got lucky; you might want to try enlisting a memory checker such as valgrind or Electric Fence to verify that you don't have a subtle bug. > should i link to special threadsafe c++ libs (and if, how) ? Change "-lpthread" to "-pthread" to ensure that your code is compiled for thread safety. [Incidentally, this is somewhat off-topic unless you plan to package the code in question...] -- 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 formal naming for NetBSD porting effort(s)
Nathan Hawkins <[EMAIL PROTECTED]> writes: > If you wanted Greek names, there are plenty of obscure nymphs, satyrs, > centaurs, etc. to choose from. Since the Greeks classified them as > neither evil spirits nor deities, many of them would qualify as daemons > in the classical sense. We could also go for "species," especially if we wanted recognizable names: FreeBSD -> faun NetBSD -> naiad or nereid OpenBSD -> oread I also like the street idea (though I've forgotten whose it was, sorry); does anyone who actually knows the area have suggestions? IIRC, there are a bunch of DDs in the Bay Area -- 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.
Preferred way to build shared objects from PIC archives?
The shared libraries in ncbi-tools6 and related packages currently start out as static archives of PIC objects, which then get turned into shared libraries with commands of the form gcc -shared -Wl,-soname=libddvlib.so.6 -o libddvlib.so.6.1.20020426 \ -Wl,-whole-archive libddvlib.a -Wl,-no-whole-archive This (admittedly roundabout) procedure works fine on i386, and has worked on other platforms until now, but as of some time in the past three months has started failing on arm with /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o): In function `__dummy': __dummy.o(.text+0x0): multiple definition of `__dummy' /usr/lib/gcc-lib/arm-linux/2.95.4/libgcc.a(__dummy.o)(.text+0x0): first defined here and a slew of similar messages. Is this a toolchain bug, or am I going about things the wrong way? (Building the shared libraries directly, while obviously preferable, would require too much tweaking to the awkward upstream build system.) Please Cc me on replies, as I do not subscribe to -devel. -- 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: Preferred way to build shared objects from PIC archives?
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > No, that should work fine. I don't know what's broken... you may wish > to try extracting all the objects via ar and relinking them; that > should be pretty easy, but I'm not sure it will help. That's actually how upstream does it, but then there are complications due to the fact that some libraries only contain *.glo instead of *.o (the former having OpenGL support enabled). Anyway, I managed to find the problem: on arm, the linker honors --no-whole-archive but silently ignores -no-whole-archive, so GCC's insertion of -lgcc -lc -lgcc leads to those errors when the linker sees the second -lgcc. (Sigh.) I have no idea why it's decided to become so picky, or why the problem only happens on arm, though I have to admit that the man page for ld only lists the double-dash form. -- 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.
Debian conference in the US?
[I've already asked a few relevant individuals about this, but am opening it up to the list at their suggestion.] I've recently been in touch with somebody (a lawyer and professor concerned with government open source policy) who is interested in sponsoring a Debian conference here in Washington, DC, next spring, in conjunction with an international conference on open source in government. I understand that there has been historical opposition to holding events in this country, due in large part to our lovely political climate. While I can certainly sympathize -- I'm no fan of the DMCA and its ilk either -- I would like to offer some counterarguments: * Although I am unfortunately in no position to guarantee anyone's safety, I would estimate the risk of being arrested for DMCA violations or the like as extremely low unless you've managed to offend somebody important; the government really has better things to do, especially given the potential bad PR. * Quite a few of us already live in the US, and find the lack of local conferences rather inconvenient. * As mentioned, we have an enthusiastic sponsor lined up, which is a definite plus. What are other developers' feelings on the matter these days? -- 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?
Ben Collins <[EMAIL PROTECTED]> writes: > If we're doing "let's have a conf where we normally don't" how about we > have it on the US's east coast aswell. I'd personally argue for the > nothern Virginia are myself. This would probably be in DC proper (specifically, at GWU) -- so a bit further north/east, but still well south of NY and thus hitting a previously neglected region. > Too many conferences are held on the US's West coast, and if conferences > do get to the East coast, they are always in New York. That leaves the > south eastern US folks out in the cold. Indeed. -- 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?
Joe Drew <[EMAIL PROTECTED]> writes: > While convenient for american developers, there are rather a number of > non-american developers who will not set foot on American soil, due in > part to the DMCA and (I imagine) the apparent dangers to non-americans > coming into the country. Two of the people I originally contacted said this too, but always in the third person. I ask again, who on this list actually still feels this way? -- 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?
Andreas Schuldei <[EMAIL PROTECTED]> writes: > What do we get from that sponsor? Conference rooms, network, accomodation, > food, flights and tshirts? His response: } We would provide the conference facilities and try to get accomodations with } some LUG members. There may be more, but I need to check what else we could } provide. -- 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: Error in upgrading libgd-perl?
This is a consequence of its broken build-depends (Bug #193602). -- 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
Stefan Schwandter <[EMAIL PROTECTED]> writes: > I'd be glad if someone could orphan the packages that nobody wants to > take right now, because I don't have access to a debian system to do > it myself. I'd be willing to adopt fltk1.1, and will also upload a new build of spiralsynthmodular shortly unless somebody takes it before then. -- 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
Morgon Kanter <[EMAIL PROTECTED]> writes: > This one time, at band camp, Stefan Schwandter <[EMAIL PROTECTED]> wrote: > > fltk, fltk1.1: The Fast Light Toolkit (www.fltk.org). A C++ GUI toolkit. > > I'd be interested in taking these over if no one else wants to, because > one if my ITPs (Quat) depends on these. No offense, but are you actually a DD? I can't seem to find you in the database, or even the new-maintainer queue. -- 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
Morgon Kanter <[EMAIL PROTECTED]> writes: > None taken. And no, I am not. [a DD] OK, then, I'm going ahead and taking fltk1.1. -- 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
"Goulais, Raphael" <[EMAIL PROTECTED]> writes: > Does this mean that debian policy is that DD have priority over a non-DD ? > Perhaps Morgon wants to become a DD ... and packaging fltk1.1 could be an > interesting work for him, and could give him some help in the process of > displaying interest to the debian community. Who are you to take over this > package, just because you made it through the processs before him ? First of all, he said "if no one else wants to"; I wanted to, as I had already been doing some work with the package and had a relevant ITP of my own. Also, he seems to have no official status whatsoever; if he's serious about wanting to maintain stuff, he is welcome to go through the NM process. Please note that I will be happy to consider suggested patches from him or any other member of the community. -- 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#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: 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: 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: 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: 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: ncbi-tools6 vs. testing
Ah, now it's there; yay. I'm still curious what was holding it up, though. -- Aaron M. Ucko, KB1CJC <[EMAIL PROTECTED]> (finger [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: Upcoming Section changes in the archive
Joerg Jaspert writes: > Its lisp. Not one special part of it, just lisp. So other dialects as > well, if someone gets me a list of packages (or matches) for it. As I mentioned directly to override-change before encountering this message, I'd argue that my goo package is a (somewhat exotic) candidate. In general, here's a first cut at a full list, including it and your initial proposals: albert cl-* clisp* cmucl* common-lisp-controller drscheme elib elk gambc gauche* gcl* goo guile-* lush* mzscheme oaklisp plt-scheme sawfish-lisp-source sbcl* scm scheme2c scheme48 scsh* sigscheme slib slime stalin tinyscheme xml-to-sexp *-el *-elisp *-lisp Thanks! BTW, while compiling that list, I also ran across a couple more httpds: araneida and hunchentoot. -- 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: Upcoming Section changes in the archive
Joerg Jaspert writes: > Its lisp. Not one special part of it, just lisp. So other dialects as > well, if someone gets me a list of packages (or matches) for it. One more: ikarus (which I initially overlooked because it's only available on i386 :-/). -- 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: Upcoming Section changes in the archive
Daniel Moerner writes: > chicken-bin Ah, yes, I meant to list that but forgot; good catch. > mzscheme and drscheme are just plt-scheme transitional packages by now True; in that case, perhaps they should go to oldlibs until they retire altogether. -- 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: What's wrong with meta-gnome2 ?
[Copying the original poster because I'm not certain he's subscribed; apologies for any resulting duplication.] Olivier Berger writes: > Updating meta-gnome2 makes 1 non-depending packages uninstallable on > i386: gnome-desktop-environment > binary package gnome-desktop-environment is part of > source package meta-gnome2 (explained above) I agree that this message is not as clear as it could be. In practice, I believe the reason for the delay is that gnome-desktop-environment has recently gained a conflict against gstreamer0.10-gnomevfs, which is however still a dependency of several packages. Not all of these are necessarily problematic, but one certainly is: gnome-dbg (which also comes from meta-gnome2) depends on gstreamer0.10-plugins-base-dbg (from gst-plugins-base0.10), which historically depended on gstreamer0.10-gnomevfs. Version 0.10.23-3 has downgraded that to a suggestion, but only showed up as a low-priority upload on June 17, so as things stand I wouldn't expect the new meta-gnome2 to hit testing until at least the 27th. See also http://bugs.debian.org/532469 . -- 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: 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: 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: 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: 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: 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]
