Re: Bits from Testing Security team
On Sat, 28 Jun 2008 08:45:54 pm Holger Levsen wrote: > Hi Testing Security team, > > thanks for the announce-mail and your work! > > On Wednesday 25 June 2008 11:08, Nico Golde wrote: > > General security support for testing > > > > [...] > > > kernel. Also, we would like to state that packages that are not > > security supported for stable are likewise unsupported for > > testing. This list includes all packages in contrib and non-free, as > > well as the ones that are marked unsupported (for example, > > kfreebsd). The maintainers are solely responsible for security and > > there won't be any DTSAs for such packages. > > Where / how are packages marked as unsupported? We just started the work on that together with Enrico. So far, we have a file in svn called package-tags and it currently has the following content: # In this file we keep the debtags for packages in "main" # where special conditions apply [etch] kfreebsd-5 (FreeBSD not yet supported) [lenny] kfreebsd-6 (FreeBSD not yet supported) [lenny] kfreebsd-7 (FreeBSD not yet supported) Please note that atm all contrib/non-free packages are unsupported by default. Cheers Steffen signature.asc Description: This is a digitally signed message part.
Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
Quoting Charles Plessy ([EMAIL PROTECTED]): > >> Maybe "Processing triggers" could be replaced by a 2-3 word summary of > >> what the trigger is really doing? > > > What about "Processing delayed configuration"? > > Well, I was originally thinking about someting specific for each > trigger, but your proposition is probably sufficient and simpler to > implement. We had the same problem when translating to French. A "trigger" is indeed pretty tricky to translate. The English word gives a good feeling of "something that sets an action to be processed later" so we settled on the french verb "déclencher" and we're using "déclenchements" (quite word-for-word translation). But I indeed feel that few users have a good idea of what this might be and the same probably stands for "triggers" in English (with the extra fact that many users of English strings for dpkg are actually non native speakers). I like "Processing delayed configuration". This is probably slightly less precise but really clear of what this thing "Joe User will never know about" is. We could use "delayed configuration" instead of "triggers" in messages meant to be displayed to users while we could keep "triggers" in internal messages. Before I mention this in the dpkg development list, are there any other comments about that wording ? signature.asc Description: Digital signature
Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
On Mon, 2008-06-30 at 07:42 +0200, Christian Perrier wrote: > Quoting Charles Plessy ([EMAIL PROTECTED]): > > >> Maybe "Processing triggers" could be replaced by a 2-3 word summary of > > >> what the trigger is really doing? > > > > > What about "Processing delayed configuration"? s/delayed/deferred/ ? or maybe 'postponed' ? "To defer is to decide to do something later on: to defer making a payment. To delay is sometimes equivalent to defer, but usually it is to act in a dilatory manner and thus lay something aside: to delay one's departure. To postpone a thing is to put it off to (usually) some particular time in the future, with the intention of beginning or resuming it then: to postpone an election." Of all of those, postponed could be closest: a trigger action is rescheduled with the definite intention of beginning at that time. To get across the idea that "the action is postponed in order that similar actions are run together to reduce overall time": "Processing groups of actions postponed during the initial setup" or "Processing groups of similar actions postponed during the initial setup" > I like "Processing delayed configuration". This is probably slightly > less precise but really clear of what this thing "Joe User will never > know about" is. delayed from when? I think it is better to extend the message and be more verbose. I also think that some indication of *why* things were delayed would solve the problem. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
Le 28 juin 08 à 04:15, Charles Plessy a écrit : Le Fri, Jun 27, 2008 at 10:31:54AM +0200, Franklin PIAT a écrit : sid:~# time dpkg -i /var/cache/apt/archives/manpages_3.00-1_all.deb Selecting previously deselected package manpages. (Reading database ... 26933 files and directories currently installed.) Unpacking manpages (from .../manpages_3.00-1_all.deb) ... Setting up manpages (3.00-1) ... Processing triggers for man-db ... [...] Maybe "Processing triggers" could be replaced by a 2-3 word summary of what the trigger is really doing? I don't know what the best practice is, but in "my" trigger action (update-yorickdoc), I print one sentence, that would come right after the "Processing triggers for yorick-doc" line: Building yorick documentation in So the user knows exactly what happens. In addition, there is an option in a conffile to deactivate this automatic re-building (in /etc/yorick-doc). If automatic rebuilding is opted-out, you still get the "Processing triggers" message, and one line saying that nothing will be done. So you just loose a very short time while a no-op is being triggered. Best regards, Thibaut. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Come join me on Mocazo Club...
Mocazo Club: ramesh avula has invited you to join Mocazo Club Hi Mocazo Club a place for every Indian residing anywhere on this planet, more so if he owns a Mobile Phone :-). See you at http://club.mocazo.com Check out Mocazo Club: http://club.mocazo.com/?xgi=hFknn9O If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser Members already on Mocazo Club KRISHNA, vijaykumar, dharaksandeep, nithin, Mocazo Upload About Mocazo Club... Welcome to the Mocazo Club! a place for everyone and more so if he/she owns a Mobile Phone:-) Check out Mocazo ki Shaan. 169 members 240 photos 77 music tracks 93 videos To control which emails you receive on the corner, or to opt-out, go to: http://club.mocazo.com/profiles/profile/emailSettings
Come join me on Mocazo Club...
Mocazo Club: ramesh avula has invited you to join Mocazo Club Hi Mocazo Club a place for every Indian residing anywhere on this planet, more so if he owns a Mobile Phone :-). See you at http://club.mocazo.com Check out Mocazo Club: http://club.mocazo.com/?xgi=hFknn9O If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser Members already on Mocazo Club KRISHNA, vijaykumar, dharaksandeep, nithin, Mocazo Upload About Mocazo Club... Welcome to the Mocazo Club! a place for everyone and more so if he/she owns a Mobile Phone:-) Check out Mocazo ki Shaan. 169 members 240 photos 77 music tracks 93 videos To control which emails you receive on the corner, or to opt-out, go to: http://club.mocazo.com/profiles/profile/emailSettings
Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
In article <[EMAIL PROTECTED]> you wrote: > delayed from when? I think it is better to extend the message and be > more verbose. I also think that some indication of *why* things were > delayed would solve the problem. I must admit i dont know how those triggers work, but I asume it is "Remebering to process xxx once at end of installation"? (In that way defering is better than postponing) However the question is, if the message is only telling us, that it is not doing anything, why not just skipping it? Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Come join me on Mocazo Club...
Mocazo Club: ramesh avula has invited you to join Mocazo Club Come join me on Mocazo Club! Thanks, - ramesh avula Check out Mocazo Club: http://club.mocazo.com/?xgi=hFknn9O If your email program doesn't recognize the web address above as an active link, please copy and paste it into your web browser Members already on Mocazo Club manu, KRISHNA, vijaykumar, dharaksandeep, nithin About Mocazo Club... Welcome to the Mocazo Club! a place for everyone and more so if he/she owns a Mobile Phone:-) Check out Mocazo ki Shaan. 170 members 240 photos 77 music tracks 93 videos To control which emails you receive on the corner, or to opt-out, go to: http://club.mocazo.com/profiles/profile/emailSettings
Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
Le 30 juin 08 à 11:56, Bernd Eckenfels a écrit : In article <[EMAIL PROTECTED]> you wrote: delayed from when? I think it is better to extend the message and be more verbose. I also think that some indication of *why* things were delayed would solve the problem. I must admit i dont know how those triggers work, but I asume it is "Remebering to process xxx once at end of installation"? (In that way defering is better than postponing) However the question is, if the message is only telling us, that it is not doing anything, why not just skipping it? No, it tells us that it is doing stuff _now_, that has been scheduled earlier. Since those tasks may take a long time (that's why we want to run them only once for several packages), you definitely need a message, but it would be nice if this message could be customized by the package or point perhaps to some documentation about these triggers. Regards, T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Mixing dbconfig and gconf
Partly an upstream query, partly a Debian packaging / lintian query: I've taken on development of a database-driven GNOME ORM IDE upstream[0], written in C, which will have a system-wide database to provide support for writing new applications using the IDE, those apps then work with a compiled interpreter (a separate package in Debian) and user-specified databases (and other datasources) via a variety of backends using files that are in userspace. i.e. the system-wide database is only needed for developers using the new IDE provided by the package, deployments of applications written using the IDE need their own config (but could use the main app as an example) and simply depend on the interpreter package. Connections to the various data sources can be via mergeant, libgda3 and other similar layers. The IDE produces an XML file containing the ORM mapping from the database to Gtk using Glade - passing that XML to the interpreter loads the Glade interface, populates the GtkWidgets with live data from the data source and runs the signals required to get the interface to do something with the data. (It could work with Qt if someone writes the mapping to something equivalent to Glade for KDE.) (ORM as in Object Relational Mapping) The system-wide database will also support the examples package and thereby the yelp manual and user documentation by providing test data that is common to all installations of the IDE. The actual database client chosen for this system-wide database is up to the user (although currently I've only been testing with PostgreSQL, I'll need MySQL and SQLite to be supported before release). It's early days and there won't be any real release until after Lenny (partly because it will use libqof2 which itself won't be released until after Lenny). Therefore, I thought I'd use dbconfig-common to provide a debconf frontend to allow the client to be chosen at installation time, setup a database name and password (where needed) and support possibly remote databases too (possibly not ideal but I can disable that later, maybe). I can get the data out of dbconfig via the tools supported but I need the IDE to get that data in a non-Debian-specific way when it is first run. (The IDE itself is not Debian native, despite being hosted at alioth.) Rather than reinventing dbconfig by writing an entire wizard in Gtk, (and as the data consists of only 7 strings), I thought I'd just parse the dbconfig output in postinst and pass those values directly to gconftool-2, *after* the debhelper parts of the postinst have actually obtained the relevant values from the user. Other distros can then use whatever tools they already have for similar tasks to dbconfig. When the IDE loads, it can just look in gconf and all is well. (Other IDE preferences can be added to gconf later via support in the IDE itself.) It works (so far) but lintian gives a warning: W: estron-gnome: gconftool-used-in-maintainer-script postinst:45 N: N: This script apparently runs gconftool or gconftool-2. It should N: probably be calling gconf-schemas or update-gconf-defaults instead. N: W: estron-gnome: gconftool-used-in-maintainer-script postinst:48 W: estron-gnome: gconftool-used-in-maintainer-script postinst:51 W: estron-gnome: gconftool-used-in-maintainer-script postinst:54 W: estron-gnome: gconftool-used-in-maintainer-script postinst:57 W: estron-gnome: gconftool-used-in-maintainer-script postinst:60 W: estron-gnome: gconftool-used-in-maintainer-script postinst:63 Well, the postinst does call gconf-schemas via dh_gconf to put the gconf schemas into place, but the 'defaults' aren't known before dbconfig is run so I can't put the defaults into the package itself. Hence the postinst calls dbconfig, then all the debhelper routines and finally, inserts the dbconfig data into the gconf structure created a moment before by debhelper, by calling gconftool-2 with the data from dbconfig. (postrm and prerm handling is default debhelper and dbconfig so remove and purge are handled cleanly.) #!/bin/sh set -e . /usr/share/debconf/confmodule . /usr/share/dbconfig-common/dpkg/postinst.pgsql dbc_pgsql_createdb_encoding="UTF8" dbc_go estron-gnome $@ #DEBHELPER# # pass the dbconfig data to gconf DBUSER=`dbconfig-generate-include -f sh -u /etc/dbconfig-common/estron-gnome.conf | grep dbuser | cut -d'=' -f2` if [ ! -z "$DBUSER" ]; then gconftool-2 --type string --set /apps/estron-gnome/dbuser $DBUSER fi ... The question is: Is this a sane use of dbconfig and gconf? Do I really need to write a Gtk wizard instead? I'd still like to use dbconfig, so I would still end up using both dbconfig (in Debian) and gconf (upstream) *as well as the wizard* which would have to know how to get Debian-specific config data instead of asking the user again so it would need to support some kind of command-line configuration option to say "got config already in file blah". Seems like a lot of work to me. I get the impression dbconfig is geared mo
Bug#488651: ITP: ha -- Archiver for .ha files
Package: wnpp Severity: wishlist Owner: Mikhail Gusarov <[EMAIL PROTECTED]> * Package name: ha Version : 0.999beta Upstream Author : Harri Hirvola <[EMAIL PROTECTED]> * URL : ftp://sunsite.unc.edu/pub/Linux/utils/compress/ * License : GPLv2 or later Programming Lang: C Description : Archiver for .ha files HA is an file archiver using HSC compression method. Mainly useful for decompressing existing .ha archives from DOS era. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (750, 'testing'), (700, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-ovz4 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=ru_RU.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]
Bug#488653: ITP: tcl8.6 -- Tcl (the Tool Command Language) v8.6
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tcl8.6 Version : 8.6a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tcl (the Tool Command Language) v8.6 Tcl is a powerful, easy-to-use, embeddable, cross-platform interpreted scripting language. Version 8.6 is in alpha stage yet, so I intend to upload it to experimental. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488655: ITP: tk8.6 -- Tk toolkit for Tcl and X11, v8.6
Package: wnpp Severity: wishlist Owner: Sergei Golovan <[EMAIL PROTECTED]> * Package name: tk8.6 Version : 8.6a1 Upstream Author : Tcl Core Team * URL : http://www.tcl.tk/ * License : BSD Programming Lang: C, Tcl Description : Tk toolkit for Tcl and X11, v8.6 Tk is a cross-platform graphical toolkit which provides the Motif look-and-feel and is implemented using the Tcl scripting language. Version 8.6 is in alpha stage yet, so I'm planning to upload this package to experimental. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=ru_RU.CP1251, LC_CTYPE=ru_RU.CP1251 (charmap=CP1251) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488658: ITP: said -- Integrated administrative system for decentralized public institutions
Package: wnpp Severity: wishlist Owner: Alexander Olivares <[EMAIL PROTECTED]> * Package name: said Version : 0.2 Upstream Author : CENDITEL <[EMAIL PROTECTED]> * URL : http://said.cenditel.gob.ve/ * License : GPL Programming Lang: PHP Description : Integrated administrative system for decentralized public institutions The automation of management in government institutions is now one of the most successful strategies, both for the modernization of public affairs for the construction of citizenship. The implementation of a modernizing process in public administration requires the production, automation and dissemination of knowledge, information and data in a timely, relevant and complete, to forecast the institutional requirements and needs of the population. Introducing new technologies in the process of governance has major benefits: organize services in an efficient form, produce and communicate messages relevant to the communities and assess the improvement of living conditions attributable to government intervention. Hence the need to implement information technology (IT) and telecommunication of proven effectiveness, with the aim of using information and knowledge to transform the social fact. Thus, emerges as the Digital Government Project: Integrated administrative system for decentralized public institutions - SAID. This software development is based on the model of free software, this being one of the flagship products of FSL (Free Software Factory). CENDITEL assume this project in the framework of strengthening the core of endogenous development in information and communication technology. This node is composed of a team of developers whose purpose is to analyze and develop information systems under web platform for government institutions at regional and national levels. This initiative emerges in the second quarter of 2004 as part of several projects that are directed towards promoting the development of quality software in the region. SAID automates the following processes: * Register of recipients and providers * Budget formulation and budget execution * Purchases (Requisitions, Quotes, Minutes, Purchase/Service Orders and Refunds) * Assets and materials storage * Banks and accounting * Personnel management * Payable accounts * Accounts catalogs (budgetary classification, patrimonial accounts converter) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-686 Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dpkg triggers and user experience, aka "How do I disable those triggers" side effect.
On Monday 30 June 2008 01:42, Christian Perrier wrote: > Quoting Charles Plessy ([EMAIL PROTECTED]): > > >> Maybe "Processing triggers" could be replaced by a 2-3 word summary of > > >> what the trigger is really doing? > > > > > > What about "Processing delayed configuration"? > > > > Well, I was originally thinking about someting specific for each > > trigger, but your proposition is probably sufficient and simpler to > > implement. > > We had the same problem when translating to French. > > A "trigger" is indeed pretty tricky to translate. The English word > gives a good feeling of "something that sets an action to be processed > later" so we settled on the french verb "déclencher" and we're using > "déclenchements" (quite word-for-word translation). > > But I indeed feel that few users have a good idea of what this might > be and the same probably stands for "triggers" in English (with the > extra fact that many users of English strings for dpkg are actually > non native speakers). > > I like "Processing delayed configuration". This is probably slightly > less precise but really clear of what this thing "Joe User will never > know about" is. > > We could use "delayed configuration" instead of "triggers" in messages > meant to be displayed to users while we could keep "triggers" in > internal messages. > > Before I mention this in the dpkg development list, are there any > other comments about that wording ? From a "Joe User" perspective, I think delay rather misses the point. The reason for triggers is not to do stuff later, it's to consolidate processing so actions don't need to be done multiple times. Delay is the mechanism chosen for doing this. I think it you substitute delayed with consolidated it, at least in English, is accurate and carries the correct connotation that a user would more likely understand. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mixing dbconfig and gconf
On Mon, Jun 30, 2008, Neil Williams wrote: > Is this a sane use of dbconfig and gconf? I might misunderstand what you're doing, but I think you're setting up GConf default systme-wide. Usage of GConf for system wide configuration (of default databases) is a bit weird, but it's valid, as long as you only set system wide things such as system gconf defaults or system gconf mandatory settings. Perhaps one way to do this is to seed a /usr/share/gconf/defaults/foo file and run update-gconf-defaults after that. I wouldn't recommend running gconftool-2 directly though, unless you would do so in a very controlled location of the gconf path which /etc instead really. > Do I really need to write a Gtk wizard instead? I don't think db configuration needs to happen system wide; I'd rather expect each user to have per project database settings so it would seem to me it's that a real UI to configure such stuff per-user and per-project would be useful anyway. > I'd still like to use dbconfig, so I would still end up using both > dbconfig (in Debian) and gconf (upstream) *as well as the wizard* which > would have to know how to get Debian-specific config data instead of > asking the user again so it would need to support some kind of > command-line configuration option to say "got config already in file > blah". Seems like a lot of work to me. > > I get the impression dbconfig is geared more towards Web2.0 type stuff > rather than compiled programs. Not quite sure why you target using dbconfig; I had the impression it was mostly aimed at setting up packages, not for per-user data. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488664: ITP: prelude-correlator -- Hybrid Intrusion Detection System [ Correlator ]
Package: wnpp Severity: wishlist Owner: Pierre Chifflier <[EMAIL PROTECTED]> * Package name: prelude-correlator Version : 0.9.0~beta1b Upstream Author : Yoann Vandoorselaere <[EMAIL PROTECTED]> * URL : http://www.prelude-ids.com * License : GPLv2 Programming Lang: C, Lua Description : Hybrid Intrusion Detection System [ Correlator ] Prelude is a general-purpose hybrid intrusion detection system. . This package provides the Prelude Correlator, which is a powerful correlation engine using Lua to write correlation rules. . The features currently include: * Rapid identification of important security events, enabling the analyst to assign task priorities * Alert correlation originally from heterogeneous sensors deployed on the whole infrastructure * Real-time analysis of events received by the Prelude Manager -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mixing dbconfig and gconf
On Mon, 2008-06-30 at 15:39 +0200, Loïc Minier wrote: > On Mon, Jun 30, 2008, Neil Williams wrote: > > Is this a sane use of dbconfig and gconf? > > I might misunderstand what you're doing, but I think you're setting up > GConf default systme-wide. Only for certain settings related to installed package selection. Much like the system user for MySQL and PostgreSQL installations - in effect, it is used to tell the IDE which backends are installed and the configuration for each. Rather than ask the admin every time a new backend is installed, each backend can use the one dbconfig config. The IDE can then offer those amongst other userspace backend configurations. Think of it a bit like the reserved tables set up by MySQL and PostgreSQL - the dbconfig data creates tables for estron-gnome that are roughly equivalent to the internal tables used by the DBRM itself. The applications written using the IDE then use their own tables, much as any package would when using MySQL or PostgreSQL directly. > Usage of GConf for system wide > configuration (of default databases) is a bit weird, but it's valid, as > long as you only set system wide things such as system gconf defaults > or system gconf mandatory settings. Perhaps one way to do this is to > seed a /usr/share/gconf/defaults/foo file and run update-gconf-defaults > after that. My problem is that the first time the IDE runs, it will need to have this data available - hence the alternative of a Gtk wizard. > I wouldn't recommend running gconftool-2 directly though, > unless you would do so in a very controlled location of the gconf path > which /etc instead really. I don't follow - currently, the schema goes into: /usr/share/gconf/schemas/estron-gnome.schemas What do you mean about a gconf path from /etc ? > > Do I really need to write a Gtk wizard instead? > > I don't think db configuration needs to happen system wide; I'd rather > expect each user to have per project database settings so it would seem > to me it's that a real UI to configure such stuff per-user and > per-project would be useful anyway. Multi-level - each "project" defines the datasource configuration and can use any of the available methods. The gconf data only relates to how the IDE offers optional backends. Each backend is a bit like a plugin but each can have installation-specific config. Once the application is developed within the IDE, it can be reconfigured for another backend or another configuration, allowing site-specific configuration. e.g. an app written using PostgreSQL on one machine can be reconfigured to work with a SQLite backend on a slower machine (and can support data export -> import across backends too). At each stage, the application config is separate from the system-wide IDE config going into gconf. > > I'd still like to use dbconfig, so I would still end up using both > > dbconfig (in Debian) and gconf (upstream) *as well as the wizard* which > > would have to know how to get Debian-specific config data instead of > > asking the user again so it would need to support some kind of > > command-line configuration option to say "got config already in file > > blah". Seems like a lot of work to me. > > > > I get the impression dbconfig is geared more towards Web2.0 type stuff > > rather than compiled programs. > > Not quite sure why you target using dbconfig; I had the impression it > was mostly aimed at setting up packages, not for per-user data. But that is how I'm using it - dbconfig is used to set up the IDE package on a system-wide basis. The IDE then allows the development of other applications that can choose from a variety of data connections, including some that are system-wide, some that are userspace and some that are remote. The applications can have a *different* system-wide config to the IDE because these can be packaged as individual packages themselves, just depending on the interpreter. estron-gnome: IDE Offers a selection of estron backends, some of which need configuration. Any backend can be installed as long as there is at least one. It is this stage that needs the dbconfig/gconf config so that the IDE can offer the backend to any project being developed - including the ability to create a separate config for each project, hence the need for a super-user, system-wide, config that has CREATE privileges. estron: interpreter Runs the IDE (which itself is written in estron) and all estron applications. It is the only dependency needed by stand-alone estron applications. backends: sys-admin able to select whichever backend is most suitable for that box. Available to the interpreter and thence to the IDE. There is no user-specific config, as such. There is project-specific config, this is then carried over into the standalone application, embedded within the estron file itself. Someone else with the IDE can then tweak the application and use a different data source. Some applications will use personal p
Re: Please focus on one generic spell checker in Debian (Was: Bug#487732: O: ispell -- International Ispell (an interactive spelling corrector))
* Hendrik Sattler <[EMAIL PROTECTED]> [080629 18:15]: > Am Mittwoch, 25. Juni 2008 21:53:24 schrieb Agustin Martin: > > Each spellchecker has currently some special features. Fortunately, the > > only thing where ispell is stronger than the other spellcheckers (support > > for pseudocharsets like 'a, "a, \'a, ... ) is already included in aspell > > development version, so at that time we can drop ispell without any loss > > of features. Not sure about hunspell here. > > What tools are using such pseudo characters, probably because they do not > support 8bit character sets? Can't they be fixed to do so? > AFAIK, even latex knows the existence of the 8th bit, nowadays. Just because some tool support 8bit characters, that does not mean that using 8 bit characters is good. Especially for latex 1) Choosing encoding issues: Just when almost anyone used latin1 or some bastardisation of that everyone thought it might be safe now to use that, then utf-8 came. 2) Compatibility: there are many old things around still to be used. When modifying some document changing all special characters just to spell check them is not nice. Also when combining many files, having different 8bit encodings is a larger pain. 3) Stability There is still suprisingly many things that can break with 8bit characters. Many of the elementary protocols (like smtp) just do not support it. So one danger more that the additional encoding/decoding will fail somewhere. 4) Easy of use: When using German umlauts on an keyboard without them, using 8 bit characters means having one more keypress (the Multi_Key) for every umlaut (as the multi-key sequences (at least those I can remember) are usually multi-key + babel encoding, guess why). Hochachtungsvoll, Bernhard R. Link -- "Never contain programs so few bugs, as when no debugging tools are available!" Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mixing dbconfig and gconf
hi neil, On Monday 30 June 2008 05:49:25 pm Neil Williams wrote: i have serious trouble grokking what exactly you are doing, but should just say that if you are interested in adding "missing features" etc to dbconfig-common then the door is open at [EMAIL PROTECTED] :) sean signature.asc Description: This is a digitally signed message part.
Re: Mixing dbconfig and gconf
On Mon, Jun 30, 2008, Neil Williams wrote: > Only for certain settings related to installed package selection. Much > like the system user for MySQL and PostgreSQL installations - in effect, > it is used to tell the IDE which backends are installed and the > configuration for each. Rather than ask the admin every time a new > backend is installed, each backend can use the one dbconfig config. Ok, then one problem with it is that as soon as the user will have gconf settings in place different from the default, any updates to the default wont be visible anymore. It all depends how you layer your settings and all, but it's quite likely that either you hide the settings or don't make use of GConf at all. Say you install mysql, launch the IDE, configure a DB, install postgresql, remove mysql, launch the IDE, want to configure a new DB: you don't see the new settings. Not quite sure you want GConf for such data passing though. > > I wouldn't recommend running gconftool-2 directly though, > > unless you would do so in a very controlled location of the gconf path > > which /etc instead really. > > I don't follow - currently, the schema goes into: > /usr/share/gconf/schemas/estron-gnome.schemas > > What do you mean about a gconf path from /etc ? Hmm so you change the schema itself, means it's not static data anymore; I'd rather recommend using the gconf-defaults mechanism we have in place which provides a nicer override mechanism -- if you're changing only the defaults that is. > There is no user-specific config (That seems quite far from the GConf use case) -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mixing dbconfig and gconf
On Mon, 2008-06-30 at 21:39 +0200, Loïc Minier wrote: > On Mon, Jun 30, 2008, Neil Williams wrote: > Ok, then one problem with it is that as soon as the user will have > gconf settings in place different from the default, any updates to the > default wont be visible anymore. It all depends how you layer your > settings and all, but it's quite likely that either you hide the > settings or don't make use of GConf at all. OK, I think I'm going to go with it only during immediate problem-solving whilst fixing other stuff and find a better solution that does not involve gconf once I've got other stuff fixed. > Say you install mysql, launch the IDE, configure a DB, install > postgresql, remove mysql, launch the IDE, want to configure a new DB: > you don't see the new settings. > > Not quite sure you want GConf for such data passing though. I'm beginning to agree - GConf probably isn't the right choice. I'll find another cross-distribution settings mechanism - maybe see about allowing the dbconfig file to be included in an "upstream" file using the named.conf.local type mechanism. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Temporary work-around (for modprobe spamming syslog; request for another opinion)
On Mon, Jun 30, 2008 at 01:35:21AM +0300, Sami Liedes wrote: > Of course I might be mistaken and there is a better solution, one that > does not involve modifying or configuring every application, > recompiling the kernel, or doing extreme things like deleting the > module. It has been suggested to me in a private email in response to my query in this list that adding the line install ipv6 /bin/true to /etc/modprobe.d/local is a temporary workaround for this bug. Still, *this* is a hack, while I haven't still heard a reason why using the blacklist command to (gasp!) blacklist a module would be one. By quick googling, it's apparently also what some other distributions (Ubuntu) do by default (see [1], which is actually the same bug as this, caused by the very same Debian-specific patch), so I assume it cannot really cause too big breakage. Marco, would it be too much asked that you explain in a short sentence or two what logging a message every time someone tries to load a blacklisted module is good for? You must have had some reason to (write and) apply that patch, I assume. To me it seems that not loading a blacklisted module is perfectly normal system behavior, and so definitely is applications probing for optional kernel features. To me it seems that this Debian-specific change only serves to make the system less maintainable by drowning the admin in useless information (100 log messages per minute in some cases!), but I'd be glad to hear why I'm wrong. Sami [1] https://bugs.launchpad.net/ubuntu/+source/module-init-tools/+bug/66423 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mixing dbconfig and gconf
Le lundi 30 juin 2008 à 12:53 +0100, Neil Williams a écrit : > It works (so far) but lintian gives a warning: > W: estron-gnome: gconftool-used-in-maintainer-script postinst:45 > N: > N: This script apparently runs gconftool or gconftool-2. It should > N: probably be calling gconf-schemas or update-gconf-defaults instead. > Well, the postinst does call gconf-schemas via dh_gconf to put the gconf > schemas into place, but the 'defaults' aren't known before dbconfig is > run so I can't put the defaults into the package itself. Hence the > postinst calls dbconfig, then all the debhelper routines and finally, > inserts the dbconfig data into the gconf structure created a moment > before by debhelper, by calling gconftool-2 with the data from dbconfig. This is an interesting use. The GConf Debian packaging was not directly meant for such things, but it is easy to use it this way. Just ship a /usr/share/gconf/defaults/10_estron-gnome symbolic link to somewhere in /etc. In the postinst, generate the file in /etc before #DEBHELPER# and you should be fine (dh_gconf should add a call to update-gconf-defaults). You should not call gconftool directly, since it modifies the system-wide defaults, in which you have no easy way to tell whether the sysadmin has already modified the values. This is why gconftool should remain the sysadmin’s tool and not used by packagers. I don’t think it is wrong to use GConf for such things; just the opposite, as GConf was precisely designed for layered configuration. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Thua quy vi!
ÐÏࡱá X-Mailer: Microsoft Outlook Express 6.00.2800.1106 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488753: ITP: libapache2-mod-passenger -- Rails and Rack module for Apache2
Package: wnpp Severity: wishlist Owner: Filipe Lautert <[EMAIL PROTECTED]> * Package name: libapache2-mod-passenger Version : 2.0.1 Upstream Author : Phusion <[EMAIL PROTECTED]> * URL : http://www.modrails.com * License : GPL Programming Lang: C++ Description : Rails and Rack module for Apache2 Phusion Passenger — a.k.a. mod_rails — makes deployment of applications built on Ruby on Rails web framework a breeze. Passenger is an Apache2 module and it's ability to automatically manage Rails server processes lowers system administration, while retaining stability/robustness and performance. There is a guy (Neil Wilson) who already started to package passenger to Ubuntu. I'll contact him and see what we can do to have this package in Debian/Ubuntu. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.23.17-linode43 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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]
