Re: MBF proposal: remaining users of fltk1.1 (vs. fltk1.3).
Simon McVittie writes: > In an ideal world the non-RC mass-bug-filing would have happened at the > earliest point when the FTLK maintainers considered 1.1 to be deprecated, > with bugs escalated to RC when it becomes feasible to consider removing it > altogether. Yeah, I've been sitting on this notion entirely too long; reverse dependencies' maintainers have generally been proactive about migrating (thanks, everyone!), and continued maintenance of 1.1 hasn't been much of a burden. Per that second point, I'm open to carrying 1.1 in full through one more release if necessary, so I'll leave the bugs as non-RC for now. > You probably can't drop the -dev package unless/until you're ready to > drop the shared library, because it would be a RC bug for dependendent > packages to be unbuildable (consider what would happen if there was a > security update to the dependent package during the bullseye cycle). Understood. I was thinking more in terms of dependent software from outside the archive, though that is of course a secondary concern. >> Subject: #PACKAGE#: Please migrate to FLTK 1.3 >> >> #PACKAGE# still builds against FLTK 1.1, for which it is long past >> time for Debian to drop support. Please migrate to 1.3, which is >> generally as simple as adjusting #PACKAGE#'s build dependencies and >> ensuring that it uses UTF-8 rather than a legacy text encoding. (That >> said, please also make sure that you're linking FLTK dynamically, >> e.g. via fltk-config --ldflags rather than fltk-config --ilbs.) > > I think you mean "--libs", not "--ilbs". Yeah, oops. > This is an unusual calling convention and it might be worth mentioning > explicitly that these options don't do what you would expect from their > names. How about replacing that parenthetical remark with a separate paragraph reading Also, please note that fltk-config (in both branches) differs from typical *-config scripts in having --libs yield paths to *static* libraries. If your build has been making use of this syntax, please substitute --ldflags to obtain proper dynamic linkage. (FLTK does not yet offer pkg-config metadata, sorry.) > Tangentially related to this, it would be great if you could get FLTK > upstream to provide pkg-config metadata (.pc file). The fltk-config script > can't be made "Multi-Arch: same" without considerable extra hacking, and > pkg-config is generally preferred by distros. Yeah, I'm well aware of that, but it would need multiple .pc files, and upstream hasn't historically showed much interest in supplying them: https://www.fltk.org/str.php?L2180 However, it looks like they may finally be coming around: https://github.com/fltk/fltk/issues/22 In general, thanks for weighing in! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
MBF proposal: remaining users of fltk1.1 (vs. fltk1.3).
Debian has had two versions of the FLTK GUI toolkit with nearly identical APIs for over nine years: 1.1 and 1.3. The only breaking change in the 1.3 series is that it expects text to be in UTF-8 rather than legacy national encodings, which Debian has generally deprecated for quite some time; meanwhile, 1.1 is thoroughly dead upstream. As such, I would like to try to drop 1.1, or at least its development package, in time for bullseye. (I know it's relatively late in the cycle, but the necessary changes should generally be minimal.) I see 19 source packages that still make use of 1.1, as listed at the end of this message. I can and will take care of packages belonging to the QA Group (epm and htmldoc) and Science Team (imview) myself, but propose to file bugs against the remaining 16, via a template along the lines of Subject: #PACKAGE#: Please migrate to FLTK 1.3 #PACKAGE# still builds against FLTK 1.1, for which it is long past time for Debian to drop support. Please migrate to 1.3, which is generally as simple as adjusting #PACKAGE#'s build dependencies and ensuring that it uses UTF-8 rather than a legacy text encoding. (That said, please also make sure that you're linking FLTK dynamically, e.g. via fltk-config --ldflags rather than fltk-config --ilbs.) For more details, please see the debian-devel thread starting at https://lists.debian.org/... Thanks! Please let me know if you have any concerns, or if I should additionally file a bug or two against lintian to catch the use of FLTK 1.1 and/or static FLTK linkage. (I haven't swept for the latter among packages using 1.3, but I do see that several packages build-depend on 1.1 but have no corresponding runtime dependencies.) Also, please keep me copied on replies. Thanks! Debian ACE maintainers ace Debian ALSA Maintainers alsa-tools Debian Go Packaging Team golang-github-yosssi-ace Debian Multimedia Maintainers csound Debian Multimedia Maintainers horgand paulstretch Debian QA Group htmldoc Debian Science Maintainers imview Debichem Team drawxtl Marcelo Soares Mota posterazor Paul Brossier aconnectgui alsamixergui Peter Pentchev wmanager Thierry Randrianiriana xdiskusage Tiago Bortoletto Vaz rakarrack -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#896712: ITP: golang-github-dataence-porter2 -- Native Go English Porter2 stemmer
Package: wnpp Severity: wishlist Owner: "Aaron M. Ucko" * Package name: golang-github-dataence-porter2(-dev) Version : 0.0~git20150829.0.56e4718 Upstream Author : Jian Zhen / Dataence, LLC * URL : https://github.com/dataence/porter2 * License : Apache 2.0 Programming Lang: Go Description : Native Go English Porter2 stemmer Porter2 implements the english Porter2 stemmer. It is written completely using finite state machines to do suffix comparison, rather than the string-based or tree-based approaches. As a result, it is 660% faster compared to string comparison-based approach. I intend to package this library under the auspices of debian-med for the sake of recent ncbi-entrez-direct releases. However, if somebody from the Go team wants to take this package over, they're certainly welcome to it. ;-) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Bug#810949: ITP: ncbi-entrez-direct -- NCBI Entrez utilities on the command line
Package: wnpp Severity: wishlist Owner: "Aaron M. Ucko" * Package name: ncbi-entrez-direct Version : 3.60 Upstream Author : Jonathan Kans * URL : http://www.ncbi.nlm.nih.gov/books/NBK179288 * License : Public Domain Programming Lang: Perl, Go, Bourne shell Description : NCBI Entrez utilities on the command line Entrez Direct (EDirect) is an advanced method for accessing NCBI's set of interconnected databases (publication, sequence, structure, gene, variation, expression, etc.) from a terminal window or script. Functions take search terms from command-line arguments. Individual operations are combined to build multi-step queries. Record retrieval and formatting normally complete the process. EDirect also provides an argument-driven function that simplifies the extraction of data from document summaries or other results that are returned in structured XML format. This can eliminate the need for writing custom software to answer ad hoc questions. Queries can move seamlessly between EDirect commands and UNIX utilities or scripts to perform actions that cannot be accomplished entirely within Entrez. With all due respect to the Go packaging team, I feel that maintaining EDirect within Debian Med or perhaps Debian Science would be more appropriate, as it falls outside the mainstream Go ecosystem. Yes, one individual tool happens to be written in Go, but EDirect otherwise consists of a mixture of Perl and shell scripts, and the Go tool has no dependencies beyond the standard library. Also, I am inclined to build the tool in question with gccgo rather than golang-go, which is available for fewer architectures and provides no obvious way to obtain dynamic linkage against system libraries, for which Policy 10.1 calls. I'm debating whether to go fully dynamic (yielding, on amd64, a 228K executable depending on a 34M library with hardly any other reverse dependencies) or to link libgo statically (yielding a 3.2M executable with no exotic dependencies). I suppose the fully dynamic approach is better practice, but would appreciate feedback on this point. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
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#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: 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#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: 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: 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: 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
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: 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: (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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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()
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: 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: 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]
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: [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]
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: 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: [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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: ./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]
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: 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]
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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#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: 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: 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: 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: 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: 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.
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: 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: 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
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: 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: 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: 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: 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: 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: 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: 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...
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: 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: 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.
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 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.
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: 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: 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: [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: 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: 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: 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: 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: 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: 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: 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: 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: 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.
