Re: Changes to Debian Maintainer upload permissions
Hi! On Sat, 2012-09-22 at 10:06:35 +0200, Ansgar Burchardt wrote: > This new interface replaces the old DMUA field. The old field will stop > working on the 24th of November 2012, from then on only packages > explicitly granted upload permission to their DMs using the interface > described here will pass the DM check. Cool! I've now locally queued a patch removing support for the field from dpkg, which will be included in the first 1.17.x version uploaded (to experimental) after the date the field stops being honoured on the archive side. thanks, guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923071432.ga18...@gaara.hadrons.org
Re: nacl and CPU frequency.
On Sat, Sep 22, 2012 at 03:28:50PM +0100, peter green wrote: > In order to build successfully nacl needs to determine the CPU > frequency (the CPU frequency determined at build time is not used in > the final binaries afaict but if it's not determined then the build > will fail as it will consider the implementation broken and if it > can't find any non-broken implementations it won't build). What does it use this information for? With current CPUs, this value is neither fixed over time, nor really meaningful. If you want to have accurate timing, use the monotonic clock. Bastian -- Respect is a rational process -- McCoy, "The Galileo Seven", stardate 2822.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923091948.ga13...@wavehammer.waldi.eu.org
Re: nacl and CPU frequency.
Le dimanche 23 septembre 2012 01:42:01, Ben Hutchings a écrit : > > So the build process is trying to determine which method will work? > Then what if it settles on some method that is available on the build > machine's kernel, but not the target distribution's kernel? I think you > need to either (1) make it defer this to run-time or (2) force the > decision at build-time, and be conservative. If I understood correctly he is ready to patch the build system to use a specific method for this precise reason but is asking which method would work on all Debian system. signature.asc Description: This is a digitally signed message part.
Re: nacl and CPU frequency.
]] "Thomas Preud'homme" > If I understood correctly he is ready to patch the build system to use a > specific method for this precise reason but is asking which method would work > on all Debian system. Detect it at runtime and choose the appropriate method then? (Not that CPU frequency is constant at runtime either, mind.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pq5dqaz8@xoog.err.no
Re: nacl and CPU frequency.
On Sun, 23 Sep 2012, "Thomas Preud'homme" wrote: > Le dimanche 23 septembre 2012 01:42:01, Ben Hutchings a écrit : > > So the build process is trying to determine which method will work? > > Then what if it settles on some method that is available on the build > > machine's kernel, but not the target distribution's kernel? I think you > > need to either (1) make it defer this to run-time or (2) force the > > decision at build-time, and be conservative. > > If I understood correctly he is ready to patch the build system to use a > specific method for this precise reason but is asking which method would > work on all Debian system. How can build-time recognition of CPU features be useful in any way for Debian? We can usually be certain that most systems which run the code will have different CPUs to the system used for building. If hard-coding the number to some reasonable value isn't good enough then code needs to be written to detect it at run-time. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201209232052.27861.russ...@coker.com.au
Packages removing alternatives on upgrade
Many packages remove alternatives on upgrade, only to re-add them later, potentially discarding manual choices of the user. See also bug #71621. -- Jakub Wilk Aaron M. Ucko ncbi-tools-x11 (U) Abou Al Montacir fp-compiler-2.6.0 (U) fp-ide-2.6.0 (U) fp-utils-2.6.0 (U) Adam Borowski chameleon-cursor-theme Alberto Garcia fuse-emulator-gtk fuse-emulator-sdl Albin Tonnerre e17 (U) Alejandro Rios P. op-panel (U) Alexander Sack browser-plugin-gnash (U) Alexander Zangerl gnuserv Andrew Lee (李健秋) lxsession (U) lxterminal (U) Aron Xu fcitx (U) Asias He ibus (U) Barry Hawkins liblucene2-java (U) Bdale Garbee dump Cameron Dale bittornado bittornado-gui Carlos Laviola fp-compiler-2.6.0 fp-ide-2.6.0 fp-utils-2.6.0 Changwoo Ryu imhangul-common (U) nabi (U) qimhangul-qt4 (U) Chris Boyle aewm++ sapphire Chris Lawrence pybliographer Christophe Monniez sleuthkit (U) Ciaran Anscomb evilwm Clint Adams freeciv-client-gtk (U) freeciv-client-sdl (U) freeciv-client-xaw3d (U) Cristian Greco sleuthkit (U) Daiki Ueno ibus (U) Damien Raude-Morvan icedtea-6-plugin (U) icedtea-7-plugin (U) Daniel Baumann traceroute Daniel Baumann lxsession (U) lxterminal (U) Daniel Moerner scheme48 Daniel Schepler xzip David Paleino webkit-image-gtk webkit-image-qt Debian Flash Maintainers browser-plugin-lightspark Debian Flash Team browser-plugin-gnash Debian Forensics sleuthkit Debian freesmartphone.org Team vala-terminal Debian Games Team freeciv-client-gtk freeciv-client-sdl freeciv-client-xaw3d gargoyle-free love nethack-console nethack-x11 yabause-gtk yabause-qt Debian GNOME Maintainers gedit Debian Haskell Group ghc Debian Java Maintainers ecj liblucene2-java Debian Korean L10N imhangul-common nabi qimhangul-qt4 Debian LXDE Maintainers lxsession lxterminal Debian Med Packaging Team ncbi-tools-x11 Debian Pkg-e Team e17 Debian QA Group elvis elvis-console elvis-tools ircii Debian Tcl/Tk Packagers tcl tk Debian VoIP Team op-panel Didier Raboud browser-plugin-lightspark (U) Eduard Bloch icewm icewm-experimental icewm-lite Emilio Pozuelo Monfort valac-0.14 (U) valac-0.16 (U) Erik de Castro Lopo ghc (U) Erik Schanze unrar-free (U) Evgeni Golov yabause-gtk (U) yabause-qt (U) Francesco Paolo Lovergine tcl (U) tk (U) Gabriele Giacone <1o5g4...@gmail.com> browser-plugin-gnash (U) Giuseppe Iuculano tcptraceroute GOTO Masanori lv HIGUCHI Daisuke (VDR dai) uim-xim IME Packaging Team fcitx gcin hime ibus Jan Lübbe e17 (U) Jari Aalto jwm leafpad levee Jeff Breidenbach liblucene2-java (U) Jelmer Vernooij tdb-tools Joachim Breitner ghc (U) vala-terminal (U) Joachim Wiedorn libfox-1.6-dev Joerg Jaspert muddleftpd Jordi Mallach freeciv-client-gtk (U) freeciv-client-sdl (U) freeciv-client-xaw3d (U) Josip Rodin maildrop Josselin Mouette gedit (U) Karl Goetz freeciv-client-gtk (U) freeciv-client-sdl (U) freeciv-client-xaw3d (U) Keita Maehara kinput2-canna kinput2-canna-wnn kinput2-wnn Kenshi Muto im-switch (U) Kilian Krause op-panel (U) Kiwamu Okabe uim-xim (U) Krystian Wlosek z88dk-bin Kurt Roeckx epic4 epic4-script-lice epic5 epic5-script-lice Lennart Weller libtxc-dxtn-s2tc0 LI Daobing ibus (U) Lincoln de Sousa fcmp Loic Minier valac-0.14 (U) valac-0.16 (U) Luca Bruno uzbl Maintainers of Vala packages valac-0.14 valac-0.16 Marc-Andre Lureau valac-0.14 (U) valac-0.16 (U) Marcin Owsiany potool Mark Brown fort77 Martin Zobel-Helas tcptraceroute (U) Matthias Klose bash ecj (U) fastjar Matthias Klose icedtea-6-plugin (U) icedtea-7-plugin (U) Michael Biebl gedit (U) Michael Janssen bittorrent bittorrent-gui Michael Koch liblucene2-java (U) Michael Piefel tkinfo Michal Čihař geeqie Miriam Ruiz browser-plugin-gnash (U) love (U) Nanakos Chrysostomos mpg321 Neil Roeth openjade openjade1.3 Neutron Soutmun xiterm+thai Niko Tyni jzip Nobuhiro Iwamatsu uim-xim (U) Olly Betts libwxbase2.8-dbg (U) libwxbase2.8-dev (U) libwxgtk2.8-dbg (U) libwxgtk2.8-dev (U) python-wxgtk2.8 (U) OpenJDK Team icedtea-6-plugin icedtea-7-plugin Osamu Aoki ibus (U) im-switch maildrop (U) Paweł Więcek pgpgpg Pedro Ribeiro poedit Peter Michael Green fp-compiler-2.6.0 (U) fp-ide-2.6.0 (U) fp-utils-2.6.0 (U) Philipp Kaluza vala-terminal (U) Piotr Roszatycki z88dk-bin (U) Rene Engelhard liblucene2-java (U) Rolf Leggewie scim Ron Lee libwxbase2.8-dbg (U) libwxbase2.8-dev (U)
Re: Packages removing alternatives on upgrade
Le dimanche 23 septembre 2012 à 13:49 +0200, Jakub Wilk a écrit : > Many packages remove alternatives on upgrade, only to re-add them later, > potentially discarding manual choices of the user. Thanks for the report. > Josselin Mouette >gedit (U) I’ve fixed it in the SVN. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1348401369.2606.0.camel@tomoyo
Re: Changes to Debian Maintainer upload permissions
On 12978 March 1977, Joachim Breitner wrote: > Would it be possible to extend the syntax to specify lists of packages > not by name, but by Maintainer, e.g. pkg-haskell-maintainers@l.a.d.o? Not with the current setup. We have a m:n relation between DMs and source packages. It's an interesting idea though, but then also not really what DM is about. The DM flag (and in future ACL) shows that one trusts that one DM to do a good job on that one package. Extending it like "this DM may upload all packages of [whateverbiglist]" is just wrong. > (Of course this is just convenience and can already be achieved by a > small script that generates the list of packages.) Yeah, but please don't. Sillyness like "all of our team packages are always for all DMs of us" is really working against the system, IMO. If you want people to have upload rights for such large sets, make them DD. DM is for people interested in small(er) style maintenance. -- bye, Joerg <_DeadBull_> ohne speicher, tastatur, mouse, pladde, monitor, also nur die Hardware... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vcf4u9f8@gkar.ganneff.de
Re: Changes to Debian Maintainer upload permissions
Hi, Am Sonntag, den 23.09.2012, 15:59 +0200 schrieb Joerg Jaspert: > The DM flag (and in future ACL) shows that one trusts that one DM to do > a good job on that one package. Extending it like "this DM may upload > all packages of [whateverbiglist]" is just wrong. > > > (Of course this is just convenience and can already be achieved by a > > small script that generates the list of packages.) > > Yeah, but please don't. Sillyness like "all of our team packages are > always for all DMs of us" is really working against the system, IMO. > If you want people to have upload rights for such large sets, make them > DD. DM is for people interested in small(er) style maintenance. I wouldn’t say it is plain wrong; there are certainly exceptions. All (library )packages by the DHG have identical packaging issues – if someone is able to do a good job on one of them, he is able to do a good job of all of them. Also, the real time-consuming work for us is when we need to upload all >450 packages with no source change, or a trivial one. I am certainly looking forward to distribute the load not only on the DDs but also on the DMs. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Packages removing alternatives on upgrade
> Jakub Wilk writes: [Cross-posting to packages@qa, for elvis is maintained by the QA group.] > Many packages remove alternatives on upgrade, only to re-add them > later, potentially discarding manual choices of the user. > See also bug #71621. […] > Debian QA Group >elvis >elvis-console >elvis-tools >ircii […] BTW, do I understand it correctly that it's just a matter of dropping the ‘upgrade’ case from .prerm? (Possible patch MIME'd.) TIA. -- FSF associate member #7257 --- debian/elvis-console.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis-console.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) for app in editor ex input vi view; do update-alternatives --quiet --remove "$app" /usr/bin/elvis done --- debian/elvis.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) for app in editor ex input vi view; do update-alternatives --quiet --remove "$app" /usr/bin/elvisnox done --- debian/elvis-tools.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis-tools.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) update-alternatives --quiet --remove ctags /usr/bin/elvtags ;; failed-upgrade)
Re: Changes to Debian Maintainer upload permissions
On 09/23/2012 11:49 PM, Joachim Breitner wrote: Also, the real time-consuming work for us is when we need to upload all>450 packages with no source change, or a trivial one. Someone assigned with such task as modifying (even trivially) and uploading 450 packages should definitively be(come) a DD. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505f384b.90...@debian.org
Re: Changes to Debian Maintainer upload permissions
Hi, Am Montag, den 24.09.2012, 00:26 +0800 schrieb Thomas Goirand: > On 09/23/2012 11:49 PM, Joachim Breitner wrote: > > Also, the real time-consuming work for us is when we > > need to upload all>450 packages with no source change, or a trivial > > one. > Someone assigned with such task as modifying (even trivially) > and uploading 450 packages should definitively be(come) a DD. I am not sure. Especially if the modifying is actually done before, in the repo, reviewed by the team, maybe semi-automated across the packages and all they are doing then is to manually build the packages in the right order and upload them – I don’t see why a DM should be less entitled to do so, or why we would want to have only DDs spend their time on this tedious task. (BTW, source only uploads anyone? Then I can easily do the uploads on my own and need neither the DDs nor the DMs in my team to do what computers can do better.) That said, I am of course happy about every DHG-member that becomes a DD. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: mass bug filing about packages manipulating/deleting shipped files
I demand that Andreas Beckmann may or may not have written... [snip] > xine-ui_0.99.7-1 > /var/lib/xine/xine.desktop > These seem to be some state/registry/... files that are updated during > postinst. That and gxine.desktop (at least) are updated then because the list of supported MIME types may vary depending on which xine-lib packages are installed. > What should we do with these? Unfortunately I didn't find a policy > reference that forbids this ... If you have better ideas concerning these, I'm listening... -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Steer clear of incorrect forms of verbs that have snuck in the language. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52d93e9a64%lists...@moreofthesa.me.uk
Re: mass bug filing about packages manipulating/deleting shipped files
On 23.09.2012 19:21, Darren Salt wrote: > I demand that Andreas Beckmann may or may not have written... > > [snip] >> xine-ui_0.99.7-1 >> /var/lib/xine/xine.desktop > >> These seem to be some state/registry/... files that are updated during >> postinst. > > That and gxine.desktop (at least) are updated then because the list of > supported MIME types may vary depending on which xine-lib packages are > installed. > >> What should we do with these? Unfortunately I didn't find a policy >> reference that forbids this ... > > If you have better ideas concerning these, I'm listening... you could let the xine-lib packages install corresponding desktop files for the mime-types they support. okular (document viewer) has a similar problem. Depending on which features you enable during configure the list of supported mime types varies. The way okular solves this is to install separate desktop files [1]. If you enable support for format x, it installs a corresponding desktop file. A similar approach should work for xine-lib. HTH, Michael [1] # ls /usr/share/applicatins/kde4/okularApplication_* okularApplication_comicbook.desktop okularApplication_ghostview.desktop okularApplication_plucker.desktop okularApplication_dvi.desktopokularApplication_kimgio.desktop okularApplication_xps.desktop okularApplication_fax.desktopokularApplication_ooo.desktop okularApplication_fb.desktop okularApplication_pdf.desktop -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: packages with E: md5sum-mismatch in the archive
On 2012-09-20 21:03, Niels Thykier wrote: > On 2012-09-20 18:52, Andreas Beckmann wrote: >> On 2012-09-18 09:30, Andreas Beckmann wrote: >>> Just to give a short impression what we can find here: >> >>> guile-1.6-dev_1.6.8-10.1 >>> /usr/lib/libguile-ltdl.la >>> /usr/lib/libguile.la >>> /usr/lib/libguile-srfi-srfi-13-14-v-1.la >>> /usr/lib/libguile-srfi-srfi-4-v-1.la >>> /usr/lib/libguilereadline-v-12.la >> >> [...] >> >> Can someone do a lintian check for just this tag on the whole archive, >> all architectures, all releases? That's just *.deb on a full mirror :-) >> And ports should be checked, too. >> >> Andreas >> >> [...] >> >> > > I am doing a lintian run for amd64 + i386 on stable for starters > (limited to md5sum-mismatch). I think that (plus the normal sid runs) > should cover most issues. > > ~Niels > > Full of stable amd64 + i386 is done. Only cm-super appears in the log and it overrides all the tags. By the looks of it, it is the same as in sid, so ... ~Niels -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/505f4b5b.7080...@thykier.net
Re: status of eligibility of dug lists on lists.debian.org
On Tue, Sep 18, 2012 at 11:43:40PM -0400, Antoine Beaupré wrote:
> However, after digging through numerous documentation pages[2], it is
> now unclear to me that there is a concensus over the user of
> lists.debian.org for such local groups, even though the wiki page says
> otherwise. For example, the dug-muc (munich) request has been
> rejected[3] and the dug-nyc request seems to be on hold, mentionning
> that the proper place is on teams.debian.net[4].
Let's separate two aspects that got intermixed in the bug report you
mention.
There's been a "heated debate" between two persons about whether a
specific group ("debian muc") has decided to migrate lists to lists.d.o
or not. The tones reached in the debate are not particularly nice, and
that's something I prefer not to read in Debian bug logs. But hey,
people occasionally fight and get mad at each other, for all sorts of
reasons. Let's move on that and hope debian muc could calmly decide
where to best host their mailing lists.
But from that, it does not descend that there is no consensus on the
usage of lists.d.o for hosting local group lists. I've a flaky
connection ATM and can't find the reference, but listmasters have
decided in the past that they're fine hosting such lists, and the
*-dug-* namespace exists for precisely that purpose. Executive bottom
line: local groups lists are fine on lists.d.o.
A related matter is that of local group granularity and, as a
consequence, the "structure" of the *-dug-* namespace (is it country
based? province? city?). Listmasters have decided to implement a country
based scheme, which is why Alexander has tagged as "wontfix" the request
specific to the Munich area, even after Martin closed the bug.
I've reviewed over time the local group structure of other large Free
Software projects, and the country-based granularity is a popular one;
similarly popular is the "exception" of considering USA states as
"countries", due to the typically high population density, Free Software
penetration there, and the very large territory that would result by
considering USA as a single country (not really "local" anymore for the
common purpose of organizing F2F events).
I think it *would* make sense to consider similar exceptions also for
other cases, but it need to be done in a systematic way. Listmasters
could have people voting for group creation, as it happened back in the
usenet days (and as I think it happens for other lists). They'd also
need to have a sane naming scheme; country-vs-city naming risk becoming
pretty nasty otherwise. This is something which is up to listmasters to
decide (as they'd do the related list maintenance work), but it is
simply a matter of exceptions to a default granularity rule that already
exists. It is by no means about "hey, we don't want local group lists on
lists.d.o".
Cheers.
PS replying where you posted, but -project would've probably been a
better list for this discussion...
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
signature.asc
Description: Digital signature
Bug#688586: ITP: Diagnostic Log and Trace (DLT) -- Diagnostic Log and Trace is a collection of logging and tracing protocols commonly found in an infotainment ECU as standardized by Autosar.
Package: wnpp Severity: wishlist Owner: "Jeremiah C. Foster" * Package name: Diagnostic Log and Trace (DLT) Version : 2.7.0 Upstream Author : Alexander Wenzel alexander.aw.wen...@bmw.de * URL : http://www.genivi.org/projects * License : Mozilla Public License v2.0 Programming Lang: C Description : Diagnostic Log and Trace is a collection of logging and tracing protocols commonly found in an infotainment ECU as standardized by Autosar. This component provides a standardised log and trace interface, based on the standardised protocol specified in the AUTOSAR standard 4.0 DLT. This component can be used by GENIVI components and other applications as logging facility providing - the DLT shared library - the DLT daemon - the DLT daemon adaptors - the DLT client console utilities - the DLT test applications The DLT daemon is the central component in GENIVI, which gathers all logs and traces from the DLT user applications. The logs and traces are stored optionally directly in a file in the ECU. The DLT daemon forwards all logs and traces to a connected DLT client. The DLT client can send control messages to the daemon, e.g. to set individual log levels of applications and contexts or get the list of applications and contexts registered in the DLT daemon. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923213328.27031.55169.reportbug@debian
Re: nacl and CPU frequency.
On Sat, Sep 22, 2012 at 05:29:45PM +0100, peter green wrote: > I therefore conclude that if it's not returning elapsed times in true CPU > cycles it probablly doesn't matter much if the supposed CPU speed and the > real CPU speed are not exactly the same. > > As such unless someone objects I plan to patch the code to fallback to > using bogomips as a "psuedo CPU speed" if true CPU speed cannot be > determined. procps has been struggling with this for years, though ita mainly around the CPU ticks versus real seconds. If you are really bored, have a look at some old procps bugs where this sort of thing has broken. We've narrowed it down to a small handful of checks. The real value is probably unknown for some devices so we just set it to a fixed value. The point is, trying to guess this sort of stuff will probably give you the wrong number so a "pseduo CPU speed" is probably as bad as anything else you can come up with, so find something simple. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923225625.ga17...@enc.com.au
Re: Bug#687103: ITP: maps -- OpenStreetMap client for the GNOME Desktop
On Mon, Sep 10, 2012 at 10:28:16AM +0100, Jon Dowland wrote: > On Mon, Sep 10, 2012 at 06:45:42AM +0200, martin f krafft wrote: > > also sprach Luca Capello [2012.09.09.2029 +0200]: > > > Or, if this is tightened to OSM, 'gnome-osm-maps'. > > > > except the 'm' on "osm" is already a "map", so maybe osm-client. > > I like dropping 'gnome', and not doubling-up map, but osm may not > be clear enough to those who aren't intimately involved, how about > openstreetmap-client? If it pulls in half of GNOME when you install it, its nice to have the name "gnome" in there somewhere. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120923230831.GX8568@tal
