Bug#445780: 'enter' handled incorrectly?
I initially get a loginscreen and can login and work normally untill 'enter' is hit, doesn't seem to matter where or when I hit it: any enter causes a segfault. -- Cheers, cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part.
Bug#407746: [URGENT] Please update debconf PO translation for the package libpam-ldap 180-1.7
On Friday 09 March 2007, Steve Langasek wrote: > Can I ask why a number of sentences in the English text that were phrased > as requests have been turned into questions in the translation? sure, basically that's the result of a discussion on debian-l10n-dutch back in september 2003. Brief overview of the consensus in that discussion is that: - the literal translation of the "Please select/enter ..." (which we started with) has to formal a connotation for most people, making it sound weird when written (at least in most places, that's less so in the middle of a paragraph). - Leaving out the please in the translation is also undesirable as that makes it an imperative, where it's a polite request/gentle direction (when speaking you'd add inflection to make that clear, but that is obviously not possible in writing) -> the best solution in most cases seems to be to make it a question form I'm curious, and a bit puzzled though. gcide defines request as: 1. The act of asking for anything desired; expression of desire or demand; solicitation; prayer; petition; entreaty. [1913 Webster] so I would expect going from request -> question would be a style issue mostly, but since you asked about it I'm guessing there's some subtle difference to a native speaker? -- Cheers, cobaco (aka Bart Cornelis) pgpDinhYJjP3h.pgp Description: PGP signature
Bug#407746: [URGENT] Please update debconf PO translation for the package libpam-ldap 180-1.7
On Friday 09 March 2007, Christian Perrier wrote: > A NMU by Steve Langasek is being prepared. Steve and I merged in the > debconf templates of libnss-ldap to this package. This is indeed a small > regression for your language but that will greatly enhance the wording of > debconf templates. > > Please consider updating this translation pretty quickly. The upload will > fix an RC bug and therefore cannot wait. This notice is here to give you > a chance to fix it. I think that taking over the translation in such case > is fine. > > Please respect the Reply-To: field and send your updated translation to > [EMAIL PROTECTED] > > The deadline for receiving the updated translation is March 10th > 23:59UTC. After this deadline, please send your translation to a NEW bug > report. updated Dutch translation attached, note that this translation starts from the reviewed libnss-ldap translation submitted in #413878, so the upload merging the templates should close that bug also (or do both packages have their own copy? -- Cheers, cobaco (aka Bart Cornelis) nl.po Description: application/gettext pgpxeZl104Izc.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Saturday 28 May 2005 22:25, Jonas Smedegaard wrote: > On 28-05-2005 21:45, cobaco (aka Bart Cornelis) wrote: > > I'm currently working on a conversion script (not part of > > maintainer-scripts), that'll migrate path approach to desktop-profiles > > You don't like my cfengine script? I wrote it specifically for you! it's not that I don't like it, but that I don't think a cfengine script is the right approach (sorry): - I don't think you can assume that all (gnome) users of desktop-profiles have cfengine installed -> using it to generate the necessary changes is definately suboptimal - the cfengine script doesn't move over management of non-default configuration sources to desktop-profiles, which means if you have any such beasts, you'll either be juggling 2 ways of managing configuration sources, or have to generate the necessary metadata manually. The conversion script will generate the necesaary metadat automatically > I am interested in what you are cooking - maybe I can help spot possible > problems, or maybe I can even learn from it :-) sure, many eyes make all bugs shallow and all that :-) current state of the conversion script can be seen at http://svn.debian.org/wsvn/debian-edu/trunk/src/desktop-profiles/path2desktop-profiles-metadata -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpcvGhk14Pp2.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
I'm currently working on a conversion script (not part of maintainer-scripts), that'll migrate path approach to desktop-profiles I'm currently unsure about wether to provide a hook through which the admin can start that script from within the package installation or not. This bug seams to imply "don't do that, it's *BAD*", I just don't see why that would be so (see below) On Saturday 28 May 2005 19:22, Peter Palfrader wrote: > On Sun, 22 May 2005, Jonas Smedegaard wrote: > > Please elaborate on Debian Policy section 10.7.4, paragraph 2: > > The maintainer scripts must not alter a `conffile' of _any_ package, > > including the one the scripts belong to. > Also, the sarge rc policy outlines it in even more detail: > Since that .../path file is a conffile it should be pretty clear that > even asking the admin and then doing it is not acceptable. I don't see it as the maintainer script modifying the path file, but as the admin doing so (with a tool provided by the maintainer script) Assuming the script I spoke of above: I don't see any fundamental difference between the admin running the conversion script on a second terminal or after the installation, and the admin starting the script through a hook in the installation: - in either case it's the conscious decision of the admin to start the conversion script. - it's just the means through which the admin starts the script that's different, the hook making it sligtly easier for the admin -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp72y48fJMFA.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Friday 20 May 2005 12:28, Jonas Smedegaard wrote: > On 20-05-2005 10:46, cobaco (aka Bart Cornelis) wrote: > > On Friday 20 May 2005 09:42, Jonas Smedegaard wrote: > > was planning on contacting the gconf2 maintainer already (I'll probably > > get around to that this weekend), I don't expect that debconf-question > > to be a long-lived thing. just got around to composing that mail, see bug 310065 for followup -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpqoVHgIWSyp.pgp Description: PGP signature
Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Friday 20 May 2005 12:28, Jonas Smedegaard wrote: > On 20-05-2005 10:46, cobaco (aka Bart Cornelis) wrote: > > On Friday 20 May 2005 09:42, Jonas Smedegaard wrote: > >> c) Provide your hack only as a "tweak" > > that's the current situation I think, no? > No. Your hack replaces the file, ignoring any and all local changes. my hack does nothing in itself, the gconf path file is not being changed behind the admin's back, or on the packages initiative. _The_admin_is_the_acting_party_ the debconf question is just a convenient means for the admin to act (in the simple case where there are no local changes, and just replacing is ok) As far as replacing the local changes, there normally shouldn't be any (as the sysadmin is supposed to define any of his sources into one of the following 2 path files (which don't exist, but will be looked for, by default) include /etc/gconf/2/local-mandatory.path include /etc/gconf/2/local-defaults.path There might still be changes off course but this should be rare (and I'd expect the admin of the box to not replace the file in that instance) Also desktop-profiles basically provides an alternative way to manage (amongst others) gconf configuration sources. If you choose to use it, I'd expect you to move managing of any extra sources you have over to the desktop-profiles also. -> I guess this really needs a conversion script (definately doable, i'll have to look at that) -> I should probably add something about this in the debconf note (if that stays) to make that clearer > Also, your hack is tied to the packaging scripts, so is only invoked by > running dpkg-reconfigure and interacting with debconf. I don't see how that's a problem in itself: - in order to use desktop-profiles to manage gconf configuration sources the default path file needs to be changed (simple fact) - The above is not done by default, but there is a means provided that the admin can use to do so (in the case that simply replacing the file is enough) - The above means has a hook in the installation through which the admin can start it (NOTE: starting that means is an action by the admin, not the package) - Exactly what the actual mechanism is, I don't see as being relevant, as long as it does what it needs (though obviously some mechanisms may be better then others, and that's open to discussion) You're interpretation of policy would imply that simply providing a hook with which the admin can change something during installation, or when running dpkg-reconfigure is against policy (and thus implicitly somehow bad), If that's the case it definately shouldn't be IMO, as invoking the hook is an admin action, which is allowed to change config files (or am I missing something, I don't see how this is fundamentally different from providing a cfengine script for the admin to run) > A self-contained and (to my belief) idempotent tweeak is now provided > here: > http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/tweaks/oldtweaks/oldtweak >s/gconf/?cvsroot=tweaks > > I suggest including the above script below /usr/lib/desktop-profiles/bin hm, this tweak uses cfengine, I don't think you can assume in general that cfengine will be installed (for CDD's possibly, but otherwise?) also the include /var/cache/desktop-profiles/$(USER)_mandatory.path should _replace_ the 2 lines xml:readonly:/etc/gconf/gconf.xml.mandator include /etc/gconf/2/local-mandatory.path not be appended after them: Those 2 sources are known to desktop-profiles by default, and thus will be managed by it (they will be included twice if they're also included in the system wide path file, which doesn't hurt in itself, though it does make things more complicated as you then need to be aware of both mechanisms) idem with the include /var/cache/desktop-profiles/$(USER)_defaults.path line, that should replace the 2 lines include /etc/gconf/2/local-defaults.path xml:readonly:/etc/gconf/gconf.xml.defaults for the same reason > and mention its existense in your README.Debian. README.Debian is the > first place to look for Debian-specific info - not the manpage and not a > debconf-note (which is by nature optional). ack, added note to readme > I recommend *not* putting it below > /usr/share/doc/desktop-profiles/examples as that is discouraged as a > location relied upon by other packages and the local admin (forgot where > but mentioned in Debian Policy somewhere). it isn't _relied_ on be anything, the admin is perfectly fine ignoring it altogether, and/or writing his own path file. In the latter case he should include the 2 directives include /var/cache/desktop-profiles/$(USER)_mandatory.path include /var/cache/desktop-profiles/$(USER)_defaul
Bug#309871: desktop-profiles: Messes with conffiles of other packages
On Friday 20 May 2005 09:42, Jonas Smedegaard wrote: > Package: desktop-profiles > Version: 1.4.5 > Severity: serious > Justification: Policy 10.7.4 > > The file /etc/gconf2/path is a conffile owned by the package gconf2. That file is left alone by default on installation of desktop-profiles. The (first-time) installation tells the user that: 1) gconf profiles won't work with the current default path file 2) tells the user that a default path file that will work is available in /usr/share/doc/desktop-profiles/examples/path 3) asks the admin (with a default answer of _no_) if he wants to replace the default path file to be replaced. -> by default the package won't mess with any other packages conffiles -> only if the _admin_ decides to change the default path file, this will be done, i.e. it is a direct result of admin action. => AIUI this is ok, specifically policy 10.7.3 has the following: These scripts must be idempotent (i.e., must work correctly if dpkg needs to re-run them due to errors during installation or removal), must cope with all the variety of ways dpkg can call maintainer scripts, must not overwrite or otherwise mangle the user's configuration without asking, must not ask unnecessary questions (particularly during upgrades), and otherwise be good citizens. key part here in this case is the "must not overwrite or otherwise mangle the user's configuration _without_asking_" desktop-profiles confirmes with that (no configuration changes will be done without the admin of the box explicitly telling us to do so) > Postinst of desktop-profiles offers through debconf to mess with that > file. That is a violation of Debian Policy section 10.7.4. as explained above I read policy 10.7.3 as allowing the offer (as long as it defaults to no, which it does). It just offers a convienence to the admin, _if_ he decides to change the default path file, he can now do it by selecting yes, instead of having to drop to a commandline and cp a file. In either case it's still the _explicit_action_ of the admin that's overwriting the default gconf path file, it's just the means by which he does so that's different. > I see no other policy-compliant approaches to fixing this than either > a) Convince the gconf2 maintainer to adopt your hack was planning on contacting the gconf2 maintainer already (I'll probably get around to that this weekend), I don't expect that debconf-question to be a long-lived thing. > c) Provide your hack only as a "tweak" that's the current situation I think, no? > By "tweak" I mean write a self-contained script, include it with your > package, and make a note to the local admin in README.Debian about its > existence. that's done, in addition when I tell the admin about the tweak* he has the _option_ (again defaulting to no) to have the tweak activated now, when this happens it's because the admin explicitly acted to have it happen. * in a debconf note, and in the manpage, not the readme, but that's ok no? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpIKIzJ8xeVx.pgp Description: PGP signature
Bug#307098: KDE 3.4 conflics with Gnome 2.10
On Wednesday 11 May 2005 19:53, Adeodato Simó wrote: > * cobaco (aka Bart Cornelis) [Wed, 11 May 2005 19:33:07 +0200]: > Hey cobaco! :) hola (see I learned some Spanish :) /me really missing the good wether from Valencia as it's raining here ;-( > > -> having this shared file owned by _any_one_ of the desktops is bound > > to lead to endless bickering and flamewars (not to mention that it will > > effectively force everyone to install the core of that desktop), > > Yup, Christopher has already moved the file in svn, good to hear :) > and I'm really hoping that the GNOME packagers will move theirs too. has anyone talked to them about it yet? > > the right place to put this is probably the menu-xdg package, as that's > > the package that's supposed to deal with the freedesktop menu standard > > in Debian AIUI hm, just realized that this is a specific case of a more general problem we'll have more and more in the future: 1) freedesktop standarizes certain stuff 2) different desktops come with different defaults settings for the standarized stuff 3) defaults from different desktops now conflict when installed on the same machine luckily freedesktop base spec allows for different configuration sets besides (or on top of) each other (see below) > This probably needs being pushed upstream, right? I see 2 (theoretically) possible ways of pushing this upstream: 1) take defaults away from the domain of desktops into the hands of some neutral 3th party (I really don't think that is gonna fly) 2) have upstream provide an xdg base-dir with their view on good default settings (as far as standarized stuff goes) in some place different then /etc/xdg and leave it up to the distribution/the admin(or distributor) to activate any and/or all available config sets -> Debian doesn't need to wait for upstream to do 2 above (just move anything upstream $DE places under /etc/xdg into /usr/share/$DE/xdg-default-config or somesuch during packaging) needs to wait for desktop-profiles to go into Debian first though without it there is no good standard way for the admin to control which set(s) of defaults gets activated (in what order) [1] see Sergio's blog at http://mixinet.net/stoblog/debian/20050510-cdd-dev-camp for an overview of what happened [2] see http://developer.skolelinux.no/~cobaco/desktop-profiles (you have to plug your own package whenever possible right? :), should enter Debian soon now -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpki6wZgTBMW.pgp Description: PGP signature
