On 20/12/2024 12:30, Ansgar 🙀 wrote:
> On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
>> Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
>> > It also avoids the problem of removed-but-not-purged packages.
>>
>> With files copied into /etc, you will still have configuration files
On 2024-12-20 at 11:42 -0800, Russ Allbery wrote:
> Maybe it would be more productive to take the preference disagreement as
> given and then try to figure out how to proceed given that we're never
> going to all agree on the best way of handling configuration files? Is
> there some way that we can
On 2024-12-22 at 08:37 +0100, Marc Haber wrote:
> Maybe our conffile handling should be modified to automatically
> accept comment-only changes to dpkg-conffiles.
>
> Greetings
> Marc
That would require to tag what is considered a comment for each
conffile.
While most config files seem to use a
On Mon, Dec 23, 2024 at 08:23:33AM -0500, Theodore Ts'o wrote:
> On Sat, Dec 21, 2024 at 04:38:46PM -0800, Josh Triplett wrote:
> > On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
> > > > Right now, the model we have is "some packages use the empty /etc model,
> > > > some packages install co
Daniel Gröber writes:
> Debian policy section 10.7.2:
>> Any configuration files created or *used* by your package must reside in
>> /etc, [...]
> (Emphasis mine)
Policy has a specific definition of configuration file, which makes your
point here somewhat ambiguous, but I can understand this mi
Hi Gioele,
On Mon, Dec 23, 2024 at 08:34:57PM +0100, Gioele Barabucci wrote:
> On 23/12/24 16:23, Daniel Gröber wrote:
> > As an example I'm familiar with iproute2 moved it's default config from
> > /etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads*
> > the config from the
On 23/12/24 16:23, Daniel Gröber wrote:
As an example I'm familiar with iproute2 moved it's default config from
/etc/iproute2 to /usr/share/iproute2 in trixie, that is it actually *loads*
the config from there, it's not just example files so in that case upstream
patching or symlink trickery woul
Hi Josh,
On Thu, Dec 19, 2024 at 07:05:56PM -0800, Josh Triplett wrote:
> Suppose that packages ship sample configuration files *that exactly
> match their defaults* (which should in general mean that everything is
> commented out) in some standardized path under /usr/share/doc/$package/
> (e.g. e
On Sat, Dec 21, 2024 at 04:38:46PM -0800, Josh Triplett wrote:
> On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
> >
> >
> > > Right now, the model we have is "some packages use the empty /etc model,
> > > some packages install commented-out defaults, and there's no
> > > consistency". I'd
On Sat, 21 Dec 2024 07:33:46 +0100, Andreas Metzler
wrote:
>On 2024-12-19 Andrey Rakhmatullin wrote:
>> On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
And it is actively harmful as if one edits the example configuration to
have a useful configuration as dpkg will start
On Fri, Dec 20, 2024 at 08:37:33AM -0600, rhys wrote:
>
>
> > Right now, the model we have is "some packages use the empty /etc model,
> > some packages install commented-out defaults, and there's no
> > consistency". I'd love to move to the model of "all packages use
> > whichever model the sysa
On 2024-12-19 Andrey Rakhmatullin wrote:
> On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
>>> And it is actively harmful as if one edits the example configuration to
>>> have a useful configuration as dpkg will start annoying admins with
>>> "the example configuration has changed
Russ Allbery wrote:
> And this is the root of the problem: you want one thing for understandable
> reasons, and other people, like myself, would prefer the opposite behavior
> of having /etc empty by default for different understandable reasons. We
> both understand the other's point of view and si
On Fri, 20 Dec 2024 11:50:57 +0100, Samuel Thibault
wrote:
>Josh Triplett, le ven. 20 déc. 2024 02:05:30 -0800, a ecrit:
>> I'm talking about the "empty /etc" model here, which is why I'm trying
>> to find a solution so that people who *want* the file-full-of-comments
>> have it, without installin
Samuel Thibault writes:
> It seems way more often to me that I want to easily inspect/modify/amend
> the configuration in /etc (without having to look whatever other place
> to find out about the default configuration) than checking what changes
> I have made to /etc which I may not want any more
> Right now, the model we have is "some packages use the empty /etc model,
> some packages install commented-out defaults, and there's no
> consistency". I'd love to move to the model of "all packages use
> whichever model the sysadmin prefers".
As a long-time sysadmin - and following on my pre
>
>> Suppose that packages ship sample configuration files *that exactly
>> match their defaults* (which should in general mean that everything is
>> commented out) in some standardized path under /usr/share/doc/$package/
>> (e.g. examples/etc), that makes it easy to see what path the example
>
Ansgar 🙀, le ven. 20 déc. 2024 13:07:36 +0100, a ecrit:
> On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
> > Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> > > On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > > > What I completely fail to understand is why people
Henrik Ahlgren, le ven. 20 déc. 2024 13:47:24 +0200, a ecrit:
> On Fri, 2024-12-20 at 12:01 +0100, Ansgar 🙀 wrote:
> > With empty-/etc, you would (ideally) only have explicit local
> > configuration in /etc which makes it much, much easier to see what the
> > local admin changed to diagnose problem
On Fri, 20 Dec 2024 02:05:30 -0800
Josh Triplett wrote:
>
> I'm talking about the "empty /etc" model here, which is why I'm trying
> to find a solution so that people who *want* the file-full-of-comments
> have it, without installing it for people who *don't* want it.
This sounds to be a reasona
Hi,
On Fri, 2024-12-20 at 13:00 +0100, Samuel Thibault wrote:
> Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> > On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > > What I completely fail to understand is why people would want to not
> > > see any file in /etc. What harm doe
Ansgar 🙀, le ven. 20 déc. 2024 12:01:24 +0100, a ecrit:
> On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> > What I completely fail to understand is why people would want to not
> > see any file in /etc. What harm does it *actually* cause?
>
> It makes it hard to see what was actually c
On Fri, 2024-12-20 at 12:01 +0100, Ansgar 🙀 wrote:
> With empty-/etc, you would (ideally) only have explicit local
> configuration in /etc which makes it much, much easier to see what the
> local admin changed to diagnose problems, prepare upgrades and so on.
> This is practically impossible now.
On Thu, Dec 19, 2024 at 08:36:25AM -0600, rhys wrote:
>
>
> >
> >> What group of idiots came up with a system where instead of having all of
> >> the configs in maximum of two places (/etc | ~/.config) have now spread
> >> them out across five completely separate directory trees?
> >
> > The
Hi,
On Fri, 2024-12-20 at 11:50 +0100, Samuel Thibault wrote:
> What I completely fail to understand is why people would want to not
> see any file in /etc. What harm does it *actually* cause?
It makes it hard to see what was actually configured: there is random
configuration bits, possibly from
Josh Triplett, le ven. 20 déc. 2024 02:05:30 -0800, a ecrit:
> On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
> > Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> > > Samuel Thibault wrote:
> > > > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > > > And
On Fri, Dec 20, 2024 at 09:55:17AM +0100, Samuel Thibault wrote:
> Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> > Samuel Thibault wrote:
> > > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > > And it is actively harmful as if one edits the example configuration to
>
Richard Lewis, le ven. 20 déc. 2024 09:42:11 +, a ecrit:
> but perhaps what is missing is a way to see what changed on upgrade
> (you'd want to save the clean version from the _previous_ version of a
> package to be able to do that after the upgrade)?
You mean ucf?
Samuel
Henrik Ahlgren, le ven. 20 déc. 2024 11:32:37 +0200, a ecrit:
> On Fri, 2024-12-20 at 09:55 +0100, Samuel Thibault wrote:
> > But isn't it what we already have? If I don't modify the example in /etc
> > and only add files to .d/, I'm getting upgrades without questions.
> > And if I modify the examp
Josh Triplett writes:
> Suppose that packages ship sample configuration files *that exactly
> match their defaults* (which should in general mean that everything is
> commented out) in some standardized path under /usr/share/doc/$package/
> (e.g. examples/etc), that makes it easy to see what pat
On Fri, 2024-12-20 at 09:55 +0100, Samuel Thibault wrote:
> But isn't it what we already have? If I don't modify the example in /etc
> and only add files to .d/, I'm getting upgrades without questions.
> And if I modify the example in /etc, I'm getting the question. That way
> I can decide per-pack
Josh Triplett, le jeu. 19 déc. 2024 19:05:56 -0800, a ecrit:
> Samuel Thibault wrote:
> > Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > > And it is actively harmful as if one edits the example configuration to
> > > have a useful configuration as dpkg will start annoying admins with
>
Samuel Thibault wrote:
> Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> > And it is actively harmful as if one edits the example configuration to
> > have a useful configuration as dpkg will start annoying admins with
> > "the example configuration has changed; what do you want to do"
>
On Thu, Dec 19, 2024 at 04:58:06PM +0100, Samuel Thibault wrote:
> > And it is actively harmful as if one edits the example configuration to
> > have a useful configuration as dpkg will start annoying admins with
> > "the example configuration has changed; what do you want to do"
> > messages.
>
>
Ansgar 🙀, le jeu. 19 déc. 2024 16:21:03 +0100, a ecrit:
> On Thu, 2024-12-19 at 11:16 +0100, Samuel Thibault wrote:
> > Also, /etc would thus be full of empty /etc/$proj directories? I don't
> > see the point of not just putting the example files there? Why making it
> > more difficult for the admi
Hi,
On Thu, 2024-12-19 at 11:16 +0100, Samuel Thibault wrote:
> Also, /etc would thus be full of empty /etc/$proj directories? I don't
> see the point of not just putting the example files there? Why making it
> more difficult for the admin to configure their server?
Examples belong to /usr/share
Hi,
On Thu, 2024-12-19 at 12:34 +0100, Frank Guthausen wrote:
> On Thu, 19 Dec 2024 11:00:03 +0100
> Ansgar 🙀 wrote:
> > On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> > >
> > > Debian GNU/Systemd is only an unofficial
> > > subdistribution of Debian GNU/Linux. YMMV
> >
> > Pleas
>
>> What group of idiots came up with a system where instead of having all of
>> the configs in maximum of two places (/etc | ~/.config) have now spread them
>> out across five completely separate directory trees?
>
> The group is called "The Linux Userspace API (UAPI) Group", and according
On Thu, 2024-12-19 at 07:08 -0600, rhys wrote:
>
> What group of idiots came up with a system where instead of having all of the
> configs in maximum of two places (/etc | ~/.config) have now spread them out
> across five completely separate directory trees?
The group is called "The Linux User
>>>
>>> $ cp /usr/lib/$proj/foo.conf /etc/$proj/
>>
>> Which is not trivial, really.
Well, it IS, but in the same way that "rm -rf /" is trivial. It's easy to do,
but some non-trivial thought should occur before doing it.
> Put another way: would it really be /usr/lib/$proj, or
>
> this is what can be called "old style" overrides.
Things get to be "old" because they actually work well.
> The modern way of doing it is the "stateless" style, most commonly associated
> with systemd but used by plenty of other projects, plus "drop-in" .d
> directories.
>
> The basic
On Thu, 19 Dec 2024 12:34:57 +0100, Frank Guthausen
wrote:
>If my suggestions do not apply to situations where systemd is used,
>I'd suggest systemd advocates to stay quiet because the topic does
>not concern them
That nicely helps me to put your suggestion in the correct
compart
On Thu, 19 Dec 2024 11:00:03 +0100
Ansgar 🙀 wrote:
> On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> >
> > Debian GNU/Systemd is only an unofficial
> > subdistribution of Debian GNU/Linux. YMMV
>
> Please keep such messages to appropriate mailing lists such as the
> Devuan list
As
Hi,
On Thu, 2024-12-19 at 10:09 +0100, Frank Guthausen wrote:
> On Thu, 19 Dec 2024 09:01:09 +0100
> Marco d'Itri wrote:
> >
> > No: the expected default for systemd-managed services is to use
> > /etc/$SERVICE/ .
>
> Debian GNU/Systemd is only an unofficial
> subdistribution of Debian GNU/Lin
Samuel Thibault, le jeu. 19 déc. 2024 10:26:12 +0100, a ecrit:
> Gioele Barabucci, le jeu. 19 déc. 2024 10:22:02 +0100, a ecrit:
> > On 19/12/24 10:19, Samuel Thibault wrote:
> > > Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
> > > > * Admin can override the standard configuratio
On Thu, 19 Dec 2024 10:09:41 +0100, Frank Guthausen
wrote:
>Debian GNU/Systemd is only an unofficial
>subdistribution of Debian GNU/Linux.
Bullshit.
--
Marc Haber | " Questions are the | Mailadresse i
On Thu, 19 Dec 2024 18:03:06 +0900
Simon Richter wrote:
> On 12/19/24 16:17, Frank Guthausen wrote:
>
> > A lot of packages do default configuration in /etc/project.conf and
> > admin related stuff in /etc/project.d/whatsoever.conf to separate
> > the distribution part from local overrides.
>
Gioele Barabucci, le jeu. 19 déc. 2024 10:22:02 +0100, a ecrit:
> On 19/12/24 10:19, Samuel Thibault wrote:
> > Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
> > > * Admin can override the standard configuration via /etc/$proj/foo.conf
> > [...]
> > > Upstream projects are moving
On 19/12/24 10:19, Samuel Thibault wrote:
Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
* Admin can override the standard configuration via /etc/$proj/foo.conf
[...]
Upstream projects are moving to this style. I hope that one day Debian
packages will stop shipping files under
Gioele Barabucci, le jeu. 19 déc. 2024 10:15:47 +0100, a ecrit:
> * Admin can override the standard configuration via /etc/$proj/foo.conf
[...]
> Upstream projects are moving to this style. I hope that one day Debian
> packages will stop shipping files under /etc.
Having pre-filled configuration f
On 19/12/24 08:17, Frank Guthausen wrote:
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.
Hi,
this is what can be called "old style" overrides.
The modern way of d
On Thu, 19 Dec 2024 09:01:09 +0100
Marco d'Itri wrote:
>
> No: the expected default for systemd-managed services is to use
> /etc/$SERVICE/ .
Debian GNU/Systemd is only an unofficial
subdistribution of Debian GNU/Linux. YMMV
--
kind regards
Frank
pgp3MLhxRVRIo.pgp
Description: OpenPGP digita
Hi,
On 12/19/24 16:17, Frank Guthausen wrote:
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.
It depends on the package.
Some packages have a "registry-style" con
On Dec 19, Frank Guthausen wrote:
> Is it reasonable to use this idea as "best practice" and implement it
> into Debian style administration recommendations? It works very well
No: the expected default for systemd-managed services is to use
/etc/$SERVICE/ .
--
ciao,
Marco
signature.asc
Descr
Hello.
A lot of packages do default configuration in /etc/project.conf and
admin related stuff in /etc/project.d/whatsoever.conf to separate the
distribution part from local overrides.
Every now and then it might be useful to switch changes on and off. The
Debian apache2 package uses sites-availa
On Fri, 31 May 2024 18:35:53 +, nino He?i
wrote:
>My suggestion is regarding locales. Currently we get to chose locale based
>on choices of language and keyboard layout and here in lies the problem.
>Rather than offer locales based on our selections don't,just list al
On Fri, May 31, 2024 at 06:35:53PM +, nino Heđi wrote:
> My suggestion is regarding locales. Currently we get to chose locale based
> on choices of language and keyboard layout and here in lies the problem.
> Rather than offer locales based on our selections don't,just list al
My suggestion is regarding locales. Currently we get to chose locale based
on choices of language and keyboard layout and here in lies the problem.
Rather than offer locales based on our selections don't,just list all of
them in installer and let us users chose which one we want. For me en
and fuzzy search suggestion written
in Go
Fuzzy is a very fast spell checker and query suggester written in
Golang.
Reason for packaging: Needed by go-task
OpenPGP_0xD599E76CFFCABF60.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
On 1.12.2022 12:16, Paul Wise wrote:
On Sat, 2022-11-26 at 19:42 +0100, Patrice Duroux wrote:
Any (or a specific group of) users could be able to install any
package of the first class by their own without asking a sysadmin (or
explicitly acquiring privilege of) user.
The general idea of a
On Sat, 2022-11-26 at 19:42 +0100, Patrice Duroux wrote:
> Any (or a specific group of) users could be able to install any
> package of the first class by their own without asking a sysadmin (or
> explicitly acquiring privilege of) user.
The general idea of a safe way to allow users to manage sys
On 26.11.22 19:42, Patrice Duroux wrote:
Dear Debian people,
Already possible or not, I would like to have a Debian system for
which packages can be installed either by a specific user
(root/sysadmin as usual) only or by any other (or a group of) users.
But this would also depend on the class of
Dear Debian people,
Already possible or not, I would like to have a Debian system for
which packages can be installed either by a specific user
(root/sysadmin as usual) only or by any other (or a group of) users.
But this would also depend on the class of the requested packages:
1. packages provid
On Mon, 2022-08-22 at 07:12 -0500, Steven Robbins wrote:
> NOTE for whoever is maintaining the very nice
> db.debian.org/machines.cgi page:
https://salsa.debian.org/dsa-team/mirror/userdir-ldap-cgi/
> I guess that one should really be searching in the Description field
> rather than Architecture
On Monday, August 22, 2022 1:29:13 A.M. CDT Nilesh Patra wrote:
> On Mon, Aug 22, 2022 at 08:08:30AM +0200, Sebastiaan Couwenberg wrote:
> > On 8/22/22 07:15, Steve Robbins wrote:
> > > Oh. I did use Eller -- but the architecture is listed as mipsel. I need
> > > mips64el>
> > eller has mips64el
>From the buildlogs / testlogs / local tests (ppc64el qemu), it seems that
there is completely no improvement for ppc64el. Simple scripts can still
encounter segmentation faults (e.g., autopkgtest for src:lua-moses).
s390x is newly enabled. I still have not seen enough test log to give
any prelimin
Hi Frédéric,
On 09-06-2022 16:19, Frédéric Bonnard wrote:
did you see any improvement with luajit2 ?
Improvements, yes. All fixed, no.
I was looking at luakit, which still fails "silently" on ppc64el, a lua
script generating a .h with no symbols with luajit2, where it does work
with lua.
Als
Hi Mo, Paul,
did you see any improvement with luajit2 ?
I was looking at luakit, which still fails "silently" on ppc64el, a lua
script generating a .h with no symbols with luajit2, where it does work
with lua.
Also I see that the autopkgtest of knot-resolver still fails on
ppc64el.
F.
On Thu, 19
On Thu, 2022-05-19 at 16:30 +0200, Frédéric Bonnard wrote:
> Hi,
>
> I've followed luajit closely since 2015 on ppc64el as a porter
> without enough knowledge to port it, but trying to ease on the
> packaging/Debian side (being both IBMer/DD).
> That port has been a mixed effort between a code bou
Hi Dipack,
I filed an ITP bug for luajit2 and will look into it.
Thank you!
On Mon, 2022-05-16 at 16:22 +, Dipak Zope1 wrote:
> Hello all,
> It'd be better to switch to luajit2 if it is possible. We can see
> right now the main issue with luajit project is no response from
> upstream of LuaJI
Hi,
I've followed luajit closely since 2015 on ppc64el as a porter
without enough knowledge to port it, but trying to ease on the
packaging/Debian side (being both IBMer/DD).
That port has been a mixed effort between a code bounty and an IBM
effort (some devs) .
It didn't started well (
https://w
om: M. Zhou
Date: Thursday, 12 May 2022 at 8:07 AM
To: debian-devel
Subject: [EXTERNAL] needs suggestion on LuaJit's IBM architecture dilemma
Hi folks,
I learned in disappointment after becoming LuaJit uploader that
the LuaJit upstream behaves uncooperatively especially for IBM
architectures
mmercial interest in working POWER/S390 support, he
takes care of the package and makes sure it keeps working on these
architectures.
My suggestion would be to just pick the packages from openSUSE [1]
since they are kept up-to-date.
Adrian
> [1] https://build.opensuse.org/package/show/devel:l
Hi folks,
I learned in disappointment after becoming LuaJit uploader that
the LuaJit upstream behaves uncooperatively especially for IBM
architectures [1]. IIUC, the upstream has no intention to care
about IBM architectures (ppc64el, s390x).
The current ppc64el support on stable is done through c
Dear Woman and Man!
Suggestion: You should delete Mozilla ESR programs otherwise you have
double work for programming, testing.
You should leave more time for the normal version.
http://ftp.mozilla.org/pub/firefox/releases/52.0.2/linux-x86_64/en-US/
With kind Greetings!
Hi Marek,
Quoting Marek Mosiewicz (2019-01-24 09:49:35)
> I have been trying to have good looking fonts in Debian. What I found
> it seems that Firefox ignores dpkg-reconfigure fontconfig-config.
>
> It is not case for Chromium. After playing with native/autohinting
> configuration it seems tha
Hello,
I have been trying to have good looking fonts in Debian. What I found
it seems that Firefox ignores dpkg-reconfigure fontconfig-config.
It is not case for Chromium. After playing with native/autohinting
configuration it seems that it is difficult to have all apps looking
good, because some
Hello Hans
The earlier message in this thread mentioned that Debian Testing is
"frozen". You'll find more information about what this means here:
https://release.debian.org/stretch/freeze_policy.html
though that document is really written for people who are familiar with
Debian development.
Hi Andrey,
> Now please look in experimental.
Yes, I saw it in experimental. However, I wondered, why it is still not in
unstable or testing, because in Kali it is already since weeks.
> Please also remember that we are currently frozen.
Of course, I forgot. This is an explanation, of course. N
On Tue, May 23, 2017 at 07:48:39PM +0200, Hans wrote:
> I see, that even in unstable openvas is still available in version 8.
Now please look in experimental.
Please also remember that we are currently frozen.
--
WBR, wRAR
signature.asc
Description: PGP signature
Dear developers,
I see, that even in unstable openvas is still available in version 8. The
actual version however is version 9. Of course I understand, that you have to
check the stability and other things.
But please allow me to suggest this:
In Kali-Linux there are already binary packages i
Aldrin P. S. Castro wrote...
> I would very much like the Universal Media Server to be in the Debian
> repositories.
> He is a very good dlna server. It is done in Java.
Unfortunately, by mailing debian-devel your suggestion will very likely
not reach the people who might be willing
I would very much like the Universal Media Server to be in the Debian
repositories.
He is a very good dlna server. It is done in Java.
On Tue, 20 Oct 2015 21:10:03 +0200, Arturo Borrero Gonzalez wrote:
> El 20 oct. 2015 5:15 p. m., "Francisco José Fernández Naranjo" <
> fjfnara...@gmail.com> escribió:
>>
>> I was considering myself adding a quick note to the section, but I am
>> not an English native speaker and I am concerned wi
El 20 oct. 2015 5:15 p. m., "Francisco José Fernández Naranjo" <
fjfnara...@gmail.com> escribió:
>
> I was considering myself adding a quick note to the section, but I am
> not an English native speaker and I am concerned with the quality of
> my contribution.
In fact, your english level seems goo
Hello guys.
I was checking the DontBreakDebian wiki page and I realized one thing.
In the section "Don't 'make install'" there is no mention to the
alternative path installation options in automake or other building
systems. Some people install packages in the system using "sudo" or
root when the
On Thu, Sep 17, 2015 at 10:55:58AM +0200, Andreas Henriksson wrote:
this, I think it would be a *service* to our users if we removed this
(and many other packages in similar situation) from the archive so that
we don't fool users into using (or wasting time even looking at)
long-deprecated softwa
Hello all.
On Wed, Sep 16, 2015 at 09:10:15PM +0200, Sven Hartge wrote:
[...]
> Why? The vlan package is not needed since at least Wheezy to configure
> VLANs on devices since the program "ip" can do everything the same or
> even better.
>
> Also ifupdown was changed to be able to configure VLAN
> it is possible to add package "vlan" to the DVD instalation images?
> It is tiny package (36kB) and in some special environment (without
> Internet with DVD in vmware environmen) i have to download and install
> it manually.
Hi Josef.
In case you really need it, you can build you own live & ins
Pascal Giard wrote:
> On Wed, Sep 16, 2015 at 3:10 PM, Sven Hartge wrote:
>> Josef Masek wrote:
>>> it is possible to add package "vlan" to the DVD instalation images?
>>> It is tiny package (36kB) and in some special environment (without
>>> Internet with DVD in vmware environmen) i have to do
On Wed, 2015-09-16 at 15:26 -0400, Pascal Giard wrote:
> On Wed, Sep 16, 2015 at 3:10 PM, Sven Hartge wrote:
> > Josef Masek wrote:
> >
> >> it is possible to add package "vlan" to the DVD instalation images?
> >> It is tiny package (36kB) and in some special environment (without
> >> Internet wi
On Wed, Sep 16, 2015 at 3:10 PM, Sven Hartge wrote:
> Josef Masek wrote:
>
>> it is possible to add package "vlan" to the DVD instalation images?
>> It is tiny package (36kB) and in some special environment (without
>> Internet with DVD in vmware environmen) i have to download and install
>> it m
Josef Masek wrote:
> it is possible to add package "vlan" to the DVD instalation images?
> It is tiny package (36kB) and in some special environment (without
> Internet with DVD in vmware environmen) i have to download and install
> it manually.
Why? The vlan package is not needed since at least
Hello,
it is possible to add package "vlan" to the DVD instalation images?
It is tiny package (36kB) and in some special environment (without
Internet with DVD in vmware environmen) i have to download and install
it manually.
Ps. I did not find better mailing list for this purpose, so I am trying
my Wifi adapter, which I
> needed for the installation.
>
> Here’s a suggestion: Let the installer display a code, which the user can
> enter on debian.org - it then automatically shows you the needed files and
> let you download them instead of mentioning cryptic file names l
On 27/01/15 19:19, Johannes Schauer wrote:
> Hi,
>
> Quoting Riley Baird (2015-01-27 04:01:20)
>> That's a good idea. That being said, tarballs containing *all* of
>> the firmware are already (unofficially) produced on a regular
>> basis[1].
>>
>> Perhaps an easier way of solving this problem wou
Hi,
Quoting Riley Baird (2015-01-27 04:01:20)
> That's a good idea. That being said, tarballs containing *all* of the
> firmware are already (unofficially) produced on a regular basis[1].
>
> Perhaps an easier way of solving this problem would be to have the
> installer tell the user where these
ldn't need a network connection for installation if
you downloaded the full CD.
> Here’s a suggestion: Let the installer display a code, which the
> user can enter on debian.org - it then automatically shows you the
> needed files and let you download them instead of mentioning
> crypt
suggestion: Let the installer display a code, which the user can enter
on debian.org - it then automatically shows you the needed files and let you
download them instead of mentioning cryptic file names like rtl8168e-3.fw and
so on.
Best greetings from Berlin & Thanks,
Stephan
signature
Octavio Alvarez:
Question: is it safe to say that systemd doesn't yet support the
> full /etc/fstab specification from util-linux [1]?
Yes; it's safe. It's also wrong. But it's quite safe. (-:
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe
1 - 100 of 327 matches
Mail list logo
