Gabor Gombas writes:
> This one is nothing special - some commands behaving differently based
> on argv[0] is a traditional Unix thing. "(exec -a klist klist.heimdal)"
> should work.
Sorry, not 100% sure what you are trying to say here.
Are you suggesting that
https://bugs.debian.org/cgi-bin/bu
Gabor Gombas writes:
> Exactly - that's why making the KDC package Conflicts: with the other
> implementation would be a quick fix. There aren't many KDC
> implementations, and I think Shishi does not use kadmin (I'm not sure, I
> never used it), so maintaining such Conflicts: does not sound like
On Mon, Feb 10, 2025 at 09:59:26AM -0800, Russ Allbery wrote:
> As someone who used to have to regularly deal with multi-implementation
> Kerberos setups, I can confirm that there is a real need to be able to
> install the Heimdal clients and the MIT clients (including kadmin) at the
> same time.
Le 10/02/2025 à 18:59, Russ Allbery a écrit :
It's unfortunate that the commands have the same names in both Kerberos
distributions, although it's understandable from a user UI perspective.
I don't have a good solution. Either using alternatives or not using
alternatives ru
Gabor Gombas writes:
> On Mon, Feb 10, 2025 at 08:59:47AM +1100, Brian May wrote:
>> Is it appropriate to use update-alternatives for kadmin that is supplied
>> with {Heimdal,MIT} Kerberos?
> ... in the real world, KDCs tend to be heavily locked down machines with
> not muc
cts: with heimdal-clients. Oh I
see, this latter Conflicts: became versioned. Which is generally good,
except...
> Is it appropriate to use update-alternatives for kadmin that is supplied
> with {Heimdal,MIT} Kerberos?
... in the real world, KDCs tend to be heavily locked down machines wit
Hello,
Can I please have some thoughts on #1070031?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070031
Is it appropriate to use update-alternatives for kadmin that is supplied
with {Heimdal,MIT} Kerberos?
I am thinking they do very different things but maybe not. i.e. one
updates files
Package: wnpp
Severity: wishlist
Owner: Josh Santos
X-Debbugs-Cc: debian-devel@lists.debian.org, josh@santos.cloud
* Package name: python-aiohttp-fast-zlib
Version : 0.1.1
Upstream Contact: J. Nick Koston
* URL : https://github.com/bdraco/aiohttp-fast-zlib
* License
Hi,
More metapackages will make transitions harder though, I believe we want
to avoid that.
In what way would transitions become harder?
The alternatives system has "manual" and "automatic" modes for each
group, these would probably correspond to "manually insta
On Thu, 28 Dec 2023 at 03:01, Simon Richter wrote:
>
> Hi,
>
> On 12/28/23 04:28, Luca Boccassi wrote:
>
> > if you want to activate a new alternative, you have to download a new
> > package that provides it anyway, so there's no difference. Subsequent
> > switches will use the cached package, and
Hi,
On 12/28/23 04:28, Luca Boccassi wrote:
if you want to activate a new alternative, you have to download a new
package that provides it anyway, so there's no difference. Subsequent
switches will use the cached package, and if you have issues
downloading a 3 kilobytes metapackage then just en
Metapackage approach is not the same for many reasons.
First, I have seen Debian installations which doesn’t have internet access, but
setup with many alternatives of the same application (e.g.: Java).
Moreover, apt automatically purges its cache after a successful transaction.
As I said
nupg. Users (and scripts) are still free to install the
>
> And if you want to change it, you have to download and install a new
> package (and remove another) instead of using a local command
> (update-alternatives) that doesn’t need an internet connection?
if you want to activate a new
* 2023-12-25 13:26:40+0100, ans...@43-1.org wrote:
> On Mon, 2023-12-25 at 09:29 +0200, Teemu Likonen wrote:
>> I hope not. For example, as a user it is nice to execute a single
>> command (update-alternatives) to get a high priority alternative for
>> "editor". I
On Mon, 2023-12-25 at 09:29 +0200, Teemu Likonen wrote:
> * 2023-12-23 15:34:49+0100, Gioele Barabucci wrote:
> > While we are on the topic of alternatives, I hope to see the
> > maintscript-based /etc/alternatives paradigm deprecated in favor of
> > the package-based X-is-X p
* 2023-12-23 15:34:49+0100, Gioele Barabucci wrote:
> While we are on the topic of alternatives, I hope to see the
> maintscript-based /etc/alternatives paradigm deprecated in favor of
> the package-based X-is-X paradigm introduced by `python-is-python3`.
I hope not. For example, as a u
However, shoehorning X-is-X to apt for replacing alternatives is a very
unoptimal (and even backwards) approach, because it’s not only for simple
applications. Some of the daily alternatives I see are:
- x-www-Browser
- java (and the whole toolchain)
- editor
- vi
- pager
… The list goes on and
, you have to download and install a new
package (and remove another) instead of using a local command
(update-alternatives) that doesn’t need an internet connection?
Sorry, this is bullshit. -100.
Stephan
--
|If your life was a horse, you'd have to shoot it.|
On 24/12/23 08:54, Alastair McKinstry wrote:
While we are on the topic of alternatives, I hope to see the
maintscript-based /etc/alternatives paradigm deprecated in favor of
the package-based X-is-X paradigm introduced by `python-is-python3`.
They have different use-cases. alternatives
On 23/12/2023 14:34, Gioele Barabucci wrote:
On 22/12/23 00:40, Daniel Kahn Gillmor wrote:
If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point t
On Sat, 23 Dec 2023 at 18:43, Gioele Barabucci wrote:
>
> On 22/12/23 00:40, Daniel Kahn Gillmor wrote:
> > If you're asking about using /etc/alternatives or something like that to
> > provide some sort of generic swapping capability, or a dpkg Provides:,
> > s
On 17086 March 1977, Gioele Barabucci wrote:
While we are on the topic of alternatives, I hope to see the
maintscript-based /etc/alternatives paradigm deprecated in favor of
the
package-based X-is-X paradigm introduced by `python-is-python3`.
In this scenario gnupg will ship gpg as /usr/bin
On 22/12/23 00:40, Daniel Kahn Gillmor wrote:
If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point toward the
"chameleon", i would w
Josh Triplett writes:
> Ignoring the server-provided MIME type and doing content-sniffing is a
> historical bug that browsers such as IE have had, and that has caused
> *many* problems (including security problems).
> [...]
Lots of good points.
I had thankfully forgotten about how IE had its ow
On Mon, Dec 28, 2020 at 01:22:16AM +, Holger Levsen wrote:
> I agree, an "open" program should ask to the server what the media type of the
> URL is, and pass it to the default program able to handle it.
I also wish it were that simple.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ hol
Stig Sandbeck Mathisen wrote:
>>> Le Sat, Oct 10, 2020 at 04:27:17AM +0900, Charles Plessy a écrit :
Since `eog http://example.com/image.png` will open the image,
shouldn't an "open" program ask to the server what the media type
of the URL is, and pass it to the default program able
Charles Plessy writes:
> I went ahead and uploaded to Sid mime-support version 3.68, which
> provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap
> using the alternatives system, at a priority of 30. I welcome other
> alternatives.
This is good news. Thank you. :
Dear Charles,
thanks for driving this.
On Mon, Dec 28, 2020 at 08:15:45AM +0900, Charles Plessy wrote:
> I went ahead and uploaded to Sid mime-support version 3.68, which
> provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap using
> the alternatives system, at a priority
[Please CC me, I am not subscribed]
Dear all,
I went ahead and uploaded to Sid mime-support version 3.68, which
provides /usr/bin/open as a symbolic link to /usr/bin/run-mailcap using
the alternatives system, at a priority of 30. I welcome other
alternatives.
I also changed the behaviour of
Your message dated Tue, 28 Jul 2020 15:49:32 +0200
with message-id <3c01488b7eb950a27837934382bd1bab3b58096a.ca...@43-1.org>
and subject line Re: project: Should have alternatives for graphical su and
sudo (x-su, x-sudo?)
has caused the Debian Bug report #512717,
regarding project: Shoul
Package: wnpp
Severity: wishlist
Owner: Thomas Goirand
* Package name: puppet-module-voxpupuli-alternatives
Version : 3.0.0
Upstream Author : Voxpupuli
* URL : https://github.com/voxpupuli/puppet-alternatives
* License : Apache-2.0
Programming Lang: Python
On 2019-07-20 07:58, Johannes Schauer wrote:
> No it does not block this. The sbuild configuration variable
> $resolve_alternatives or the command line option --resolve-alternatives allows
> one to enable or disable that sbuild only uses the first alternative.
>
> As Gregor also
_ be blocking
> a nice way to cope with libraries that are not available
> on all architectures.
No it does not block this. The sbuild configuration variable
$resolve_alternatives or the command line option --resolve-alternatives allows
one to enable or disable that sbuild only uses the first alt
Package: sbuild
Previous-Subject: Re: seccomp woes
Original-To: debian-devel@lists.debian.org
On Fri, Jul 19, 2019 at 11:28:36PM -0300, gregor herrmann wrote:
> On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote:
>
> > * Centralize the list of supported archs in the seccomp packages. By
Hi Guus,
On Mon, Feb 04, 2019 at 07:55:41AM +0100, Guus Sliepen wrote:
> > libblis.so.2 libblis2 #MINVER#
>
> If the ABI and API are the same for all variants, a much better
> solutions seems to me to have a single libblis2 that can switch at
> runtime between the different variants, perhaps usi
On Mon, Feb 04, 2019 at 06:07:55AM +, Mo Zhou wrote:
> My updated version, all variants are co-installable now:
>
> Package: libblis2-openmp, Provides: libblas.so.3, libblis.so.2
> Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
> Package: libblis2-serial, Provides: libbl
Hi Ian and Thibaut,
Inspired by Thibaut's comment, I worked out a good solution for
the co-installation problem, which only results in a single layer
of alternatives.
Thibaut's proposed layout:
> Package: libblis2-openmp, Provides: libblas.so.3, libblis.so.2
> Package:
Mo Zhou writes ("Is multiple-layers of alternatives a good thing to users?"):
> A user suggested[1] that the 6 variants[2] of BLIS should be
> co-installable. However, making them co-installable would result in
> multiple layers of alternatives in the update-alternatives system
Hi devel,
A user suggested[1] that the 6 variants[2] of BLIS should be
co-installable. However, making them co-installable would result in
multiple layers of alternatives in the update-alternatives system and
will possibly confuse users, as discussed in [3]. I wrote this mail
in case anyone has a
Hello,
On Mon 24 Dec 2018 at 05:37pm -0300, Felipe Sateler wrote:
> I (not speaking for the whole team), have no objection to this patch.
> However, it was pointed out to me that virtual packages require policy
> updates[1], first starting as a debian-devel discussion. So I'm starting
> this now
]] Felipe Sateler
Two minor typos.
> The proposed virtual packages are:
>
> logind: a org.freedesktop.login1 D-Bus API implementation
«an org…»
> default-logind: should be provided by the distributions default logind
> provider (currently pam-systemd)
distribution's.
Otherwise, this looks
On Mon, Dec 24, 2018 at 05:37:56PM -0300, Felipe Sateler wrote:
> On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski wrote:
> > Could you please either take this patch or propose a different approach?
> > I have received no feedback other than a brief unconclusive remark on IRC.
>
> Sorry for the radi
Hi,
On Sat, Dec 22, 2018 at 5:33 PM Adam Borowski wrote:
> Hi!
> Could you please either take this patch or propose a different approach?
> I have received no feedback other than a brief unconclusive remark on IRC.
>
Sorry for the radio silence. Let's try to remedy that.
> The clock for Buste
]] Daniel Pocock
> Even if DSA didn't grant access to the instance you run now, would it be
> considered easier for you to support extra, identical instances of RT
> rather than supporting Kanboard or alternatives?
That depends on what the alternatives are, but I think that&#x
and sign up for queues and such.
>
> (Speaking with a DSA hat, but not for all of DSA as we have yet to
> discuss it.)
>
Even if DSA didn't grant access to the instance you run now, would it be
considered easier for you to support extra, identical instances of RT
rather than supporting Kanboard or alternatives?
Regards,
Daniel
]] Daniel Pocock
> Another possibility: DSA already run RT and there is a Kanban
> extension[3] for it.
I doubt we're interested in making the RT setup generally available for
people to create and sign up for queues and such.
(Speaking with a DSA hat, but not for all of DSA as we have yet to
di
(please reply on debian-devel unless your reply is very specific to one
of the other teams)
Hi all,
I wanted to share this discussion with the wider community as Kanboard
has appeared in two different teams (DebConf and Outreach) and it also
relates to (or potentially duplicates) the functionalit
On Sunday, February 05, 2017 10:05:13 AM Pirate Praveen wrote:
> On ഞായര് 05 ഫെബ്രുവരി 2017 04:07 രാവിലെ, Jonathan Dowland wrote:
> > I'm getting deja vu, this has all been discussed already on -devel in
> > recent months, please check the archives for further details, I'm fairly
> > sure people a
On ഞായര് 05 ഫെബ്രുവരി 2017 04:07 രാവിലെ, Jonathan Dowland wrote:
> I'm getting deja vu, this has all been discussed already on -devel in
> recent months, please check the archives for further details, I'm fairly
> sure people are already working on this (Pirate Praveen was at least).
Just for the
On Sat, Feb 04, 2017 at 02:14:20PM +0100, Stig Sandbeck Mathisen wrote:
> I've noted the presence of gogs (https://gogs.io/) and pagure
> (https://pagure.io/pagure), which look to be completely free projects,
> but haven't tried any of them yet. https://rocketgit.com/op/doc/compare
> has a compari
http://astralinux.com/ofl.html
* License : OFL 1.1
Description : metric-compatible Times New Roman and Arial alternatives
PT Astra Serif and PT Astra Sans are metric-compatible replacements
for Times New Roman and Arial fonts. PT Astra family of fonts have
been developed by ParaType
reassign 754813 libc6
reassign 757941 libc6
forcemerge 754813 757941
severity 754813 important
retitle 754813 libc6 version 2.19 breaks NSS loading for static binaries
forwarded 754813 https://sourceware.org/bugzilla/show_bug.cgi?id=17250
tag 754813 + upstream
thanks
On Tue, Oct 07, 2014 at 09:58:
Hi,
Julian Taylor:
> this is already the case with regular static linking, you don't need LTO
> to remove unused code, the compiler only uses those objects from that
> archive that are required to resolve all symbols.
>
… remove _some_ unused code. Lots of code the linker pulls in from gcc will
n
On 07.10.2014 08:07, Paul Wise wrote:
> On Tue, Oct 7, 2014 at 1:58 PM, Michael Tokarev wrote:
>
>> apps becomes huge in size
>
> I wonder if LTO would help with the size issues, theoretically all the
> code from the static glibc that isn't used by busybox-static would be
> stripped out of the re
On Tue, Oct 7, 2014 at 1:58 PM, Michael Tokarev wrote:
> apps becomes huge in size
I wonder if LTO would help with the size issues, theoretically all the
code from the static glibc that isn't used by busybox-static would be
stripped out of the resulting binaries.
--
bye,
pabs
https://wiki.debi
07.10.2014 08:34, Steve Langasek wrote:
[]
>>> Was the removal of gethostby* APIs from the static glibc intentional?
>
>> Yes. It's the nsswitch problem. The behavior of those APIs is controlled
>> by the nsswitch mechanism (specifically the hosts configuration), which is
>> inherently dynamic a
reassign 757941 src:glibc
affects 757941 busybox-static
thanks
On Mon, Oct 06, 2014 at 07:32:17PM -0700, Russ Allbery wrote:
> Paul Wise writes:
> > On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:
> >> But with jessie, for one, all network name resolution (gethostby* etc
> >> APIs) don't
Paul Wise writes:
> On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:
>> But with jessie, for one, all network name resolution (gethostby* etc
>> APIs) don't work anymore, because glibc does not provide them instatic
>> libraries. So usual network utilities in busybox does not anymore,
>>
On Mon, Oct 6, 2014 at 11:27 PM, Michael Tokarev wrote:
> But with jessie, for one, all network name resolution (gethostby* etc APIs)
> don't work anymore, because glibc does not provide them instatic libraries.
> So usual network utilities in busybox does not anymore, they just return
> `host not
thinking about alternatives for glibc in this context. For busybox
it should be easy on one hand, because it does not depend/use anything else,
just libc and busybox itself; but difficult on another because busybox
uses a wide range of libc functions (especially low-level kernel interfaces).
So, I tried u
Sylvestre Ledru debian.org> writes:
> > Build systems that ignore those environment variables are broken and
> > need to be fixed.
> >
> Yes, but we have plenty of packages not honoring CC, CXX or CLFAGS.
Yes, but I have a GCC patch (in MirBSD) that can make such builds
fail, by adding a non-sta
On 22/06/2014 11:47, Christian Hofstaedtler wrote:
> update-alternatives gives the user a choice,
My remark is not directly related to this problem (perhaps, in fact)
but update-alternatives does *not* give the user a choice.
It give the *admin* a choice.
You must be root to run upd
lly, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
> snapshot).
>
> I saw various complains from users (example:
> https://bugs.launchpad.net/bugs/991493 ) to switch to the
> update-alternatives mechanism. This would allow a quick and global
> switch fr
On 21/06/2014 19:19, Paul Wise wrote:
> On Sun, Jun 22, 2014 at 12:46 AM, Sylvestre Ledru wrote:
>
>> Any opinions on the subject?
> There is already the CC (and CXX etc) environment variable to select
> the compiler, they should use that.
I am not talking about Clang but LLVM here. LLVM itself shi
On Sun, Jun 22, 2014 at 12:46 AM, Sylvestre Ledru wrote:
> Any opinions on the subject?
There is already the CC (and CXX etc) environment variable to select
the compiler, they should use that.
Build systems that ignore those environment variables are broken and
need to be fixed.
--
bye,
pabs
> Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
> snapshot).
>
> I saw various complains from users (example:
> https://bugs.launchpad.net/bugs/991493 ) to switch to the
> update-alternatives mechanism. This would allow a quick and global
> swit
, 3.3, 3.4 &
snapshot).
I saw various complains from users (example:
https://bugs.launchpad.net/bugs/991493 ) to switch to the
update-alternatives mechanism. This would allow a quick and global
switch from a LLVM version to another.
I must admit that I am not sure what to do here.
I see value
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : module providing (s)printf alternatives
String::Print inserts values into (translated) strings. It provides printf()
and sprintf() alternatives via both an object oriented and a functional
interface.
signature.asc
Ivan Shmakov writes:
> ? How is the ‘if’ statement above different to, say:
> case "$1" in
> (remove)
> update-alternatives --remove
> ;;
> esac
It's not; what it *is* different from is the more common case
construction, which
>>>>> Russ Allbery writes:
[…]
> It's an improvement. Guillem makes a good argument that you should
> drop deconfigure as well, which means that:
> if [ "$1" = "remove" ] ; then
> update-alternatives --remove
> fi
> is pro
~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)
>> up
On 09/23/2012 08:40 AM, Ivan Shmakov wrote:
>>>>>> 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, potenti
>>>>> 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.
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 i
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
On 2012-02-23 21:59, Jakub Wilk wrote:
> * Andreas Beckmann , 2012-02-23, 21:49:
>> I'm planning to file bugs against all packages that currently leave
>> alternatives on the system after they were removed. Forgetting to
>> remove alternatives usually leaves dangling
* Andreas Beckmann , 2012-02-23, 21:49:
I'm planning to file bugs against all packages that currently leave
alternatives on the system after they were removed. Forgetting to
remove alternatives usually leaves dangling symlinks on the system and
in most cases these are dangling symlinks in
Hi,
I'm planning to file bugs against all packages that currently leave
alternatives on the system after they were removed. Forgetting to remove
alternatives usually leaves dangling symlinks on the system and in most
cases these are dangling symlinks in /usr/bin
At the moment there a
> This is not to say we couldn't remove it on startup though.
You should not remove /lib/init/rw on the next reboot. If the
upgrade stops due to an error then the system might be rebooted
before the upgrade is continued. /lib/init/rw needs to remain
present until all packages using it have bee
On Sun, Apr 17, 2011 at 07:44:55AM +0200, Goswin von Brederlow wrote:
> Edward Allcutt writes:
>
> > On Sat, 16 Apr 2011, Roger Leigh wrote:
> >> On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:
> >>> I suggest:
> >>> - on upgrade, bind mount or symlink /run/init -> /lib/init/rw
>
Edward Allcutt writes:
> On Sat, 16 Apr 2011, Roger Leigh wrote:
>> On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:
>>> I suggest:
>>> - on upgrade, bind mount or symlink /run/init -> /lib/init/rw
>>> - on boot, after mounting /run, mkdir /run/init; ln -s /run/init
>>> /lib/ini
On Sat, 16 Apr 2011, Roger Leigh wrote:
On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:
I suggest:
- on upgrade, bind mount or symlink /run/init -> /lib/init/rw
- on boot, after mounting /run, mkdir /run/init; ln -s /run/init /lib/init/rw
Or in other words - exactly like we're
On Sat, Apr 16, 2011 at 05:58:19PM +0100, Edward Allcutt wrote:
> On Sat, 16 Apr 2011, rleigh wrote:
> >We haven't made any plans to remove it yet. We'll look more closely
> >at the best way to do that once all the users are moved over. Given
> >the small number, it's quite likely this won't take
On Sat, 16 Apr 2011, rleigh wrote:
We haven't made any plans to remove it yet. We'll look more closely
at the best way to do that once all the users are moved over. Given
the small number, it's quite likely this won't take very long. If
it turns out that there are other users of /lib/init/rw,
On Sat, Apr 16, 2011 at 12:39:03PM +0200, Thomas Hood wrote:
> While I applaud the introduction of /run, I have some concerns about
> how quickly users of alternatives to /run could be required to switch
> to the new location.
>
> Consider the following scenario.
>
> Package
While I applaud the introduction of /run, I have some concerns about
how quickly users of alternatives to /run could be required to switch
to the new location.
Consider the following scenario.
Package P is using /lib/init/rw. At some point the new version of
initscripts is installed. The
Processing commands for cont...@bugs.debian.org:
> clone 348775 -1
Bug#348775: general: terminal emulators' alternatives settings' priorities
annoy users
Bug 348775 cloned as bug 604959.
> reassign -1 xdg-utils 1.0.2+cvs20100307-3
Bug #604959 [general] general: terminal emulato
clone 348775 -1
reassign -1 xdg-utils 1.0.2+cvs20100307-3
retitle xdg-utils please introduce (sane) xdg-terminal
tags -1 + upstream
quit
Paul Wise wrote:
> In xdg-utils CVS there is an xdg-terminal script, not sure why that
> isn't available in Debian yet:
When no desktop is in use, it uses $TER
On Thu, Nov 25, 2010 at 1:24 AM, Jonathan Nieder wrote:
> . unlike browsers with $BROWSER and desktop-specific settings, there
> is no standard, cross-distro way to make a user-specific choice of
> terminal
...
> To solve (2): one could introduce a TERMINAL environment variable
> analogous to M
al
> emulators is an adequate solution, hence I'm opening this "general" bug
> for discussion on how to reflect individual users' choices properly.
>
> It has been suggested on #debian-devel that maybe creating a per-user
> ~/bin with its own alternatives lin
On Thu, 23 Sep 2010 01:32:21 +0200
Jérémy Lal wrote:
> On 23/09/2010 01:24, Ian Jackson wrote:
> > Jérémy Lal writes ("Re: Bug#597571: nodejs: non common executable
> > name (exclusive alternatives ?)"):
> >> On might object "node" would have a diffe
On 23/09/2010 01:24, Ian Jackson wrote:
> Jérémy Lal writes ("Re: Bug#597571: nodejs: non common executable name
> (exclusive alternatives ?)"):
>> On might object "node" would have a different meaning, depending
>> on the packages installed ; still, nodejs
Jérémy Lal writes ("Re: Bug#597571: nodejs: non common executable name
(exclusive alternatives ?)"):
> On might object "node" would have a different meaning, depending
> on the packages installed ; still, nodejs or x25node (if its maintainer
> cares to follow) would
a postinst routine, common to both packages.
On might object "node" would have a different meaning, depending
on the packages installed ; still, nodejs or x25node (if its maintainer
cares to follow) would be there, and unambiguous.
Do that notion of "exclusive alternatives" is
Description : Makes different sized alternatives of the same images in
Drupal
This module lets you make different sized alternatives of the same images. It
requires an image
manipulation library such as GD2 or ImageMagick and requires clean urls to be
enabled. You can
use imagecache with
: high performance java collection alternatives
A collection of concurrent and highly scalable utilities. These are
intended as direct replacements for the java.util.* or
java.util.concurrent.* collections but with better performance when many
CPUs are using the collection concurrently. Single-threaded
Hi!
On Tue, 2009-06-30 at 12:32:23 +0200, Pino Toscano wrote:
> Few days ago, I had a nice talk with Guillem, and he told me that dpkg
> developers are working for cleaning up update-alternatives' code, and
> planning
> to convert it to C (along with provide a dpkg library); s
Hello,
> I've skimmed over the sources, and it seems kalternatives is reading
> and writting directly to the alternatives db (under
> /var/lib/dpkg/alternatives/). The db should be considered internal,
> and we reserve the right to change its layout in the future.
>
> Ther
e-apps.org/content/show.php/Kalternatives?content=16016
> * License : GPL
> Programming Lang: C++
> Description : graphical alternatives system configuration tool
>
> Kalternatives offers a GUI to configure the alternative systems (a
> system that allows you t
: graphical alternatives system configuration tool
Kalternatives offers a GUI to configure the alternative systems (a
system that allows you to select one alternative file for many in the
filesystem).
.
This is an advanced GUI of the update-alternatives program shipped with dpkg.
--
To
1 - 100 of 328 matches
Mail list logo
