Re: fstab update for persistent device names
* Bastian Blank ([EMAIL PROTECTED]) [070726 11:40]: > For the libata-pata support we need to change fstab on several arches to > not break all systems which uses them. > > We need to decide which arches needs this rewrite now and which value > should be filed in. I'd like to ask you to postpone such changes until we split the etch+.5-kernel off (because we don't want to change the fstab on the new kernel, but on the upgrade from etch to lenny). (And, BTW, I don't think this is a kernel-only topic, so setting Cc accordingly). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fstab update for persistent device names
On Fri, Jul 27, 2007 at 09:23:37AM +0200, Andreas Barth wrote: > * Bastian Blank ([EMAIL PROTECTED]) [070726 11:40]: > > For the libata-pata support we need to change fstab on several arches to > > not break all systems which uses them. > > > > We need to decide which arches needs this rewrite now and which value > > should be filed in. > > I'd like to ask you to postpone such changes until we split the > etch+.5-kernel off (because we don't want to change the fstab on the new > kernel, but on the upgrade from etch to lenny). i don't see this correlation as it is easy to revert back to old IDE instead of PATA for the etch kernel. according to dannf the target kernel wouldn't be 2.6.23 (fedora 8) but a later kernel when oldstable no longer receives security support. so that would mean scheduling that change very late in the release process of lenny!? > (And, BTW, I don't think this is a kernel-only topic, so setting Cc > accordingly). agreed it's a userspace trouble, so leave it to the user :P no seriously the debian-installer team needs to be too in the loop as they would need to sync the decision too for newly installed boxes. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le vendredi 27 juillet 2007 à 03:52 -0700, Steve Langasek a écrit : > > In the end, the people who know whether an application should be given > > tags that will exclude it from certain menus are the application's > > maintainers, not the menu systems maintainers. So far they have been > > reasonable about what is included in the menu, and I have no reason to > > think this wouldn't remain like that. > > In that case, I guess I'm confused, because I had the impression that you > were still opposed to migrating the existing Debian menu to use the > freedesktop standard. Sorry, that wasn't clear: people are currently reasonable with what they include in the *freedesktop* menu. I'm not fond of the idea of converting the Debian menu entries because it will lead to including all that's currently in the *Debian* menu, which is not reasonable. If desktop entries are not generated automatically, and if there are clear rules on how they should be tagged, I think only a small number of maintainers wouldn't follow them. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: List of (un)sponsored packages on Mentors (approximate)
> I find it easy enough to do: > > $ sudo apt-get update > $ apt-src -bi install $package > > apt-src will then "install" the source of the package into the current > working directory, then "b"uild it, and then "i"nstall the resulting > binaries. > > This works just fine for me with the deb-src mentors line. Unfortunately, there is a problem with this approach: when the binary package depends on some packages, that I don't have on my system, the dpkg will refuse to install it and I need to apt-get those packages by hand and then install it again. This should be fully automatic though, but it isn't. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
On Thu, Jul 26, 2007 at 11:37:33AM +0200, Josselin Mouette wrote: > Le jeudi 26 juillet 2007 à 10:54 +0200, Wouter Verhelst a écrit : > > One thing I do not like about the GNOME usability philosophy is > > precisely this: catering for the novice user is great, but the GNOME > > usability philosophy caters for novice users *at the expense of > > experienced users*. > This widespread belief is entirely untrue. It is true, and your posts in this thread are the evidence of it. So far, the only proposal I've seen for allowing users to get access to the "non-default" menu entries, after they've been hidden in GNOME, is by letting them hunt down a config option in a settings menu /which is nowhere near the menu itself/. That's a bad UI; it might be ok for novices, but it's not ok for non-novices *or for novices who aren't looking to be novices for all eternity*. Making "advanced" configuration options available only to those who already know where to look ensures that there will always be a large gap between the knowledgeable elite, and the uninformed consumers. > I have no business into changing other environments' menus. If you're going to be making unilateral decisions about classes of graphical applications that shouldn't be shown in the menu because they don't fit with your ideal of what a desktop menu should look like, I don't think you have any business changing GNOME's menu either. Identifying, as a project, classes of applications that aren't appropriate for inclusion in the menu of a desktop environment at all, and excluding those, is perfectly reasonable; but you appear to insist on referring to the classes identified so far, such as console apps and language interpreters, as *examples* of things you would trim from the GNOME menu, reserving for yourself the right to make the final decisions about what else you'll decide to cut. As a user of GNOME in Debian, I'm not at all ok with that. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding desktop files to misc packages
Le vendredi 27 juillet 2007 à 02:44 -0700, Steve Langasek a écrit : > So far, the only proposal I've seen for allowing users to get access to the > "non-default" menu entries, after they've been hidden in GNOME, is by > letting them hunt down a config option in a settings menu /which is nowhere > near the menu itself/. Right-clicking on the menu isn't near the menu itself? If you have better suggestions to make it accessible, please don't hesitate. > That's a bad UI; it might be ok for novices, but > it's not ok for non-novices *or for novices who aren't looking to be novices > for all eternity*. Making "advanced" configuration options available only > to those who already know where to look ensures that there will always be a > large gap between the knowledgeable elite, and the uninformed consumers. Despite not being, I think, a novice user, I almost never crave in the advanced configuration options. They are advanced because there is no need for them in the general case, novice user or not. > > I have no business into changing other environments' menus. > > If you're going to be making unilateral decisions about classes of graphical > applications that shouldn't be shown in the menu because they don't fit with > your ideal of what a desktop menu should look like, I don't think you have > any business changing GNOME's menu either. > > Identifying, as a project, classes of applications that aren't appropriate > for inclusion in the menu of a desktop environment at all, and excluding > those, is perfectly reasonable; but you appear to insist on referring to the > classes identified so far, such as console apps and language interpreters, > as *examples* of things you would trim from the GNOME menu, reserving for > yourself the right to make the final decisions about what else you'll decide > to cut. As a user of GNOME in Debian, I'm not at all ok with that. You make it sound like somehow I would dictate what would be in the menu by removing any application I don't like or use. This has never been my intent. I have quoted window managers and console applications as examples because they are the only identified classes so far; it is hard to tell what will need to be excluded until the desktop files are actually created and we can start seeing what the menu looks like. In the end, the people who know whether an application should be given tags that will exclude it from certain menus are the application's maintainers, not the menu systems maintainers. So far they have been reasonable about what is included in the menu, and I have no reason to think this wouldn't remain like that. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: adding desktop files to misc packages
On Fri, Jul 27, 2007 at 12:29:35PM +0200, Josselin Mouette wrote: > Le vendredi 27 juillet 2007 à 02:44 -0700, Steve Langasek a écrit : > > So far, the only proposal I've seen for allowing users to get access to the > > "non-default" menu entries, after they've been hidden in GNOME, is by > > letting them hunt down a config option in a settings menu /which is nowhere > > near the menu itself/. > Right-clicking on the menu isn't near the menu itself? If you have > better suggestions to make it accessible, please don't hesitate. It wasn't clear to me that this would be togglable from right-clicking on the menu. Although my above criticism wouldn't apply, I'm still not altogether happy with this prospect because you're not just hiding the applications, you're effectively /hiding the fact that they're hidden/, by giving no UI hint that brings this information to your attention. (If your response to this is "but all you have to do is right click", well - I think that supports *my* position rather well, since that's an instance where you're giving a /verbal/ hint because there's no visual indicator in the interface itself.) Context menus are great for operations that you know you want to perform on the current data/window/interface element. Unhiding menu entries isn't an operation that you know you want to perform, if you don't know that menu entries are being hidden in the first place! So it's imperative that hiding menu entries in this way is only used for *very* esoteric tools that are just plain incompatible with the environment; not just for applications that don't meet some aesthetic standard, or that you (or someone else) think are unlikely to be used. (I guess it's reasonable to consider console applications "incompatible with the environment", but then, hasn't GNOME itself supported, since long before .desktop files existed, marking apps as "runs in xterm" in launchers?) > You make it sound like somehow I would dictate what would be in the menu > by removing any application I don't like or use. This has never been my > intent. I have quoted window managers and console applications as > examples because they are the only identified classes so far; it is hard > to tell what will need to be excluded until the desktop files are > actually created and we can start seeing what the menu looks like. Why is this hard to tell? Are the kinds of things that would need to be suppressed not evident from the menu policy? > In the end, the people who know whether an application should be given > tags that will exclude it from certain menus are the application's > maintainers, not the menu systems maintainers. So far they have been > reasonable about what is included in the menu, and I have no reason to > think this wouldn't remain like that. In that case, I guess I'm confused, because I had the impression that you were still opposed to migrating the existing Debian menu to use the freedesktop standard. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434912: ITP: abinit -- A package for electronic structure calculations
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: abinit Version: 5.3.4 Upstream Author: Prof. Xavier Gonze URL: http://www.abinit.org/ License: GPL Description: ABINIT is a package whose main program allows one to find the total energy, charge density and electronic structure of systems made of electrons and nuclei (molecules and periodic solids) within Density Functional Theory (DFT), using pseudopotentials and a planewave basis. . ABINIT also includes options to optimize the geometry according to the DFT forces and stresses, or to perform molecular dynamics simulations using these forces, or to generate dynamical matrices, Born effective charges, and dielectric tensors. Excited states can be computed within the Time-Dependent Density Functional Theory (for molecules), or within Many-Body Perturbation Theory (the GW approximation). In addition to the main ABINIT code, different utility programs are provided. . Homepage: http://www.abinit.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434929: ITP: python-asynqueue -- asynchronus task queueing based on the Twisted framework
Package: wnpp Severity: wishlist Owner: Eric Evans <[EMAIL PROTECTED]> * Package name: python-asynqueue Version : 0.1 Upstream Author : Edwin A. Suominen <[EMAIL PROTECTED]> * URL : http://foss.tellectual.com/trac/AsynQueue/wiki * License : GPL Programming Lang: Python Description : asynchronous task queueing based on the Twisted framework AsynQueue is a Python module which provides task queueing with prioritization and a powerful worker/manager interface. Worker implementations are provided for running tasks via threads, separate Python interpreters, and remote worker nodes. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (700, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Eric Evans [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#434951: python2.4-doc: File created by latex2html included
Package: python2.4-doc Severity: serious Justification: Policy 2.2.2 the file 'Doc/html/style.css' in python2.4-doc is partially created by LATEX2HTML, and as I have learned, that is a violation of the DFSG. Correct me if I'm wrong. /Carl Fürstenberg -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-1-686 (SMP w/1 CPU core) Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: fstab update for persistent device names
On Fri, Jul 27, 2007 at 10:24:19AM +0200, maximilian attems wrote: > On Fri, Jul 27, 2007 at 09:23:37AM +0200, Andreas Barth wrote: > > * Bastian Blank ([EMAIL PROTECTED]) [070726 11:40]: > > > For the libata-pata support we need to change fstab on several arches to > > > not break all systems which uses them. > > > > > > We need to decide which arches needs this rewrite now and which value > > > should be filed in. > > > > I'd like to ask you to postpone such changes until we split the > > etch+.5-kernel off (because we don't want to change the fstab on the new > > kernel, but on the upgrade from etch to lenny). > > i don't see this correlation as it is easy to revert back to old IDE > instead of PATA for the etch kernel. > according to dannf the target kernel wouldn't be 2.6.23 (fedora 8) > but a later kernel when oldstable no longer receives security > support. so that would mean scheduling that change very late in the > release process of lenny!? We talked about doing it a little earlier at debconf, but after talking to zobel we're back at the December estimate. But yeah, I think the sooner we switch for lenny, the better. Lets just hope that we get quite a bit of etch & 1/2 testing from our users. The fact that using backports from sid will probably[1] be non-trivial for the libata-effected folks will hopefully encourage installs from the etch+1/2 repo. [1] probably, because I've still a lot of unanswered questions about the device name changes. waldi: do you have a plan that you're not sharing, or is this still open to discussion? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: emacs21 removal?
(Cc: debian-devel@lists.debian.org for mass bug filing) On July 20, 2007 at 7:10AM +0900, tats (at vega.ocn.ne.jp) wrote: > On July 15, 2007 at 9:38PM +0900, > tats (at vega.ocn.ne.jp) wrote: > > > What's the plan for the emacs21 package? Rob, will you remove > > emacs21 when emacs22 is moved to testing? > > > > I don't make an objection to removing emacs21. If emacs21 will > > soon be removed, I'll submit bugreports to packages which depend > > on emacs21. > > There is now emacs22 in lenny/sid. While emacs21 still exists, to > prefer emacs22 (or emacs), I'll submit bug reports with `Severity: > wishlist'. If emacs21 is removed, the severities will be bumped up. I've submited a wishlist Bug #434978 to lintian to add a new check. I'm starting to submit wishlist bug reports. If emacs21 is removed, I'll submit bug reports to all of the following packages with `Severity: serious' or so. Sandra Jean Chua (Sacha) <[EMAIL PROTECTED]> remember-el Masayuki Hatta (mhatta) <[EMAIL PROTECTED]> a2ps cedet jde salahuddin pasha (salahuddin66) <[EMAIL PROTECTED]> c-sig Jari Aalto <[EMAIL PROTECTED]> edb OHASHI Akira <[EMAIL PROTECTED]> develock-el easypg elpoint initz liece lsdb riece Ben Armstrong <[EMAIL PROTECTED]> junior-writing Paul Brossier <[EMAIL PROTECTED]> supercollider Trent Buck <[EMAIL PROTECTED]> paredit-el Hubert Chan <[EMAIL PROTECTED]> windows-el David Coe <[EMAIL PROTECTED]> oo-browser Vivek Dasmohapatra <[EMAIL PROTECTED]> lpc-mode Debian Edu Developers <[EMAIL PROTECTED]> debian-edu Debian FDT tools team <[EMAIL PROTECTED]> asn1-mode ttcn-el Debian GNU Smalltalk maintainers <[EMAIL PROTECTED]> gnu-smalltalk Debian OCaml Maintainers <[EMAIL PROTECTED]> ocaml Debian Octave Group <[EMAIL PROTECTED]> octave2.1 octave2.9 Yann Dirson <[EMAIL PROTECTED]> bigloo Eric Dorland <[EMAIL PROTECTED]> post-el Free Ekanayaka <[EMAIL PROTECTED]> t-gnus Zak B. Elep <[EMAIL PROTECTED]> ecb Arnaud Fontaine <[EMAIL PROTECTED]> emms nethack-el Romain Francoise <[EMAIL PROTECTED]> prcs Peter S Galbraith <[EMAIL PROTECTED]> gri mh-e Kevin Glynn <[EMAIL PROTECTED]> mozart Debian QA Group <[EMAIL PROTECTED]> cmail ilisp manued-el prolog-el scheme48 skribe tramp trr19 Fredrik Hallenberg <[EMAIL PROTECTED]> artist Tollef Fog Heen <[EMAIL PROTECTED]> xslide Hidetaka Iwai <[EMAIL PROTECTED]> mell prime-el suikyo Joerg Jaspert <[EMAIL PROTECTED]> bbdb elib Isaac Jones <[EMAIL PROTECTED]> haskell-mode Timo Jyrinki <[EMAIL PROTECTED]> malaga Yauheni Kaliuta <[EMAIL PROTECTED]> dictem Matthias Klose <[EMAIL PROTECTED]> python-mode python2.4 python2.4-doc python2.5 python2.5-doc Mario Lang <[EMAIL PROTECTED]> bhl biomode emacs-chess Chris Lawrence <[EMAIL PROTECTED]> css-mode html-helper-mode rnc-mode Camm Maguire <[EMAIL PROTECTED]> acl2 cxref ess maxima OHURA Makoto <[EMAIL PROTECTED]> oneliner-el Christoph Martin <[EMAIL PROTECTED]> gtalk Roland Mas <[EMAIL PROTECTED]> edict-el idl-font-lock-el Daigo Moriwaki <[EMAIL PROTECTED]> tdiary Matthieu Moy <[EMAIL PROTECTED]> xtla Ramakrishnan Muthukrishnan <[EMAIL PROTECTED]> quack-el Mike O'Connor <[EMAIL PROTECTED]> gnuserv Masahito Omote <[EMAIL PROTECTED]> anthy uim Javier Fernandez-Sanguino Pen~a <[EMAIL PROTECTED]> remem Ben Pfaff <[EMAIL PROTECTED]> w3-el-e21 w3-url-e21 Andrés Roldán <[EMAIL PROTECTED]> elfsh Joel Rosdahl <[EMAIL PROTECTED]> lyskom-elisp-client Otavio Salvador <[EMAIL PROTECTED]> search-citeseer Davide G. M. Salvetti <[EMAIL PROTECTED]> auctex mailcrypt Taketoshi Sano <[EMAIL PROTECTED]> yasgml Stefan Schimanski <[EMAIL PROTECTED]> proofgeneral Jens Peter Secher <[EMAIL PROTECTED]> haxe NOSHIRO Shigeo <[EMAIL PROTECTED]> t-code Roger So <[EMAIL PROTECTED]> im-sdk Manoj Srivastava <[EMAIL PROTECTED]> calc psgml vm Roland Stigge <[EMAIL PROTECTED]> hyperlatex Akira TAGOH <[EMAIL PROTECTED]> wget-el Satoru Takeuchi <[EMAIL PROTECTED]> quilt-el Monty Taylor <[EMAIL PROTECTED]> plywood James Troup <[EMAIL PROTECTED]> gnus Fumitoshi UKAI <[EMAIL PROTECTED]> eldav migemo migemo-perl w3m-el Junichi Uekawa <[EMAIL PROTECTED]> ecasound2.2 Pontus Ullgren <[EMAIL PROTECTED]> php-elisp Tommi Virtanen <[EMAIL PROTECTED]> records Yukiharu YABUKI <[EMAIL PROTECTED]> yc-el Taku YASUI <[EMAIL PROTECTED]> iiimecf sdic James R. Van Zandt <[EMAIL PROTECTED]> emacspeak Alexander Zangerl <[EMAIL PROTECTED]> mmm-mode Michael W. Olson (GNU address) <[EMAIL PROTECTED]> emacs-wiki erc muse-el picca frederic <[EMAIL PROTECTED]> lisaac akira yamada <[EMAIL PROTECTED]> rdtool ruby1.9 Thanks, -- Tatsuya Kinoshita pgp9sRVVUKMJx.pgp Description: PGP signatu
Re: [updated] Mass bug filing: Dependency/file list predictability
On Fri, Jul 20, 2007 at 10:22:52AM +0200, Steinar H. Gunderson wrote: > Hamish Moffatt <[EMAIL PROTECTED]> >kptc (U) >phaseshift (U) >qsstv (U) >ucblogo >verilog The first 4 of these are all extra dependencies on libdnet, which all come from AC_PATH_XTRA in /usr/share/autoconf/autoconf/libs.m4. It doesn't seem right to patch every package individually to fix this. Is there another alternative? Perhaps that macro could be modified so that libdnet must be explicitly enabled; the only package that actually rdepends on libdnet is from the same source package :-| Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
