> "Sam" == Sam Hartman wrote:
> "Simon" == Simon Richter writes:
> "Sam" == On 6/29/23 01:56, Sam Hartman wrote:
Sam> It also seems a bit strange to require more from the maintainer
Sam> when they are dropping an init script than we would if a
Sam> maintainer started depending on
> On 2023-06-07, Sune Vuorela wrote:
> On 2023-06-07, Paul Wise wrote:
>> I note that there are a number of packages available on i386 but not
>> available on amd64, is anyone planning on an MBF about this issue?
> I got curious. Some of them are hurd specific. Others are a i386
>
> On 2023-05-19, Steve McIntyre wrote:
> Colin Watson wrote:
> On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
> LB == Luca Boccassi wrote:
LB> +1 for stopping publishing installers for i386, it has been
LB> mentioned many times but it's always worth repeatin
>>>>> On 2023-03-23 05:30:01 +0100, Don Armstrong wrote:
>>>>> On Fri, 17 Mar 2023, Ivan Shmakov wrote:
>> It would’ve likely helped me if #1006801 were listed on
>> http://bugs.debian.org/src:tinysshd .
>> (I’m not entirely sure as to /why/ it
> On 2023-03-01 16:30:01 +0100, Sam Hartman wrote:
> Honestly, if there is not currently a submitter behind a bug---someone
> who cares about it and is willing to look into requests for more
> information or to help confirm a fix---I'm not particularly interested
> in working on such a bug
Сс: debian-b...@lists.debian.org
[Cross-posting to tasksel maintainers, debian-boot@; but please
keep the discussion on debian-devel@.]
Unless I deeply misunderstand how locales work in Debian,
I believe that any dependency on the ‘locales’ package is ought
> Jonathan Dowland writes:
> On Tue, Oct 23, 2018 at 11:45:26PM +0200, Marco d'Itri wrote:
> On Oct 23, Tollef Fog Heen wrote:
>>> Wouldn’t it make more sense for mutt to just go «oh, no GPG
>>> installed, let’s note that there are signatures here, but they
>>> can’t be verified,
> Wouter Verhelst writes:
> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote:
> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote:
[…]
>>> I think the prerequisite for making a change like this would be for
>>> the library to be able to surface this transiti
>>>>> Jonathan Dowland writes:
>>>>> On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote:
>> I disagree; to the best of my knowledge, anyone can do the testing
>> and suggest any fixes he or she deems necessary. As such, having an
>>
>>>>> Jonathan Dowland writes:
>>>>> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote:
>> It can be argued that libgpgme11 does not “provide a significant
>> amount of functionality” (7.2) without gnupg.
> It won’t function at al
>>>>> Andrey Rahmatullin writes:
>>>>> On Sun, Oct 21, 2018 at 05:33:57PM +, Ivan Shmakov wrote:
>>> "Every package must specify the dependency information about other
>>> packages that are required for the first to work correctly.&quo
>>>>> Vincent Bernat writes:
>>>>> ❦ 21 octobre 2018 18:12 GMT, Ivan Shmakov :
>>> so if you were an actual user, I would propose you file a bug
>>> report against the package to let the maintainer knows the
>>> dependency
>>>>> Vincent Bernat writes:
>>>>> ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov :
>>>>> ‘TFH’ == Tollef Fog Heen writes:
[…]
TFH> tinysshd only ships a systemd unit file; neomutt links against
TFH> libgpgme11 which again Depends on gnupg. It
>>>>> Andrey Rahmatullin writes:
>>>>> On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote:
>>>>> Tollef Fog Heen writes:
>>> tinysshd only ships a systemd unit file; neomutt links against
>>> libgpgme11 which a
> Ian Jackson writes:
> KatolaZ writes:
>> The problem that spurred this thread is that sysvinit needs a
>> maintainer. That’s why some of us are here: our intention is to
>> help with maintaining sysvinit in Debian if possible, since we will
>> keep maintaining it in Devuan neverthe
> Sune Vuorela writes:
> On 2018-10-21, Jonas Smedegaard wrote:
> Tollef Fog Heen writes:
[I see I’ve managed to botch References: for the
news:linux.debian.devel readers; my apologies for that.]
>>> tinysshd only ships a systemd unit file; neomutt links against
>
> Bastian Blank writes:
> On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote:
> Ansgar Burchardt writes:
>>> Should Debian also support “noalsa”, “noavahi”, “nocups”,
>>> “nopulseaudio”, “nosysvinit”, “nodbus”, “nopam”, “nowayland”,
So long as there’s su
> Marcel Partap writes:
> Dear fellow Debianauts, right now I am in the process of migrating my
> selection of manually installed packages to a freshly debootstrapped
> install using a set of meta-packages built with equivs. While that
> works nice and well, in some instances, I would li
>>>>> Tollef Fog Heen writes:
>>>>> Ivan Shmakov
>>>>> Hans-Christoph Steiner writes:
>>> Package: dpkg-dev
>>> More and more packages are adding unicode files
>> I assume you mean “UTF-8 filenames” here (per below), r
> Hans-Christoph Steiner writes:
> Package: dpkg-dev
> More and more packages are adding unicode files
I assume you mean “UTF-8 filenames” here (per below), right?
> as unicode support has become more reliable and available.
What are the use cases for such filenames?
> Marvin Renich writes:
[…]
> The only benefit I have seen between the new scheme and the previous
> one is that there is no state file. While getting rid of the state
> file is a nice goal, it is extremely minor compared to having short,
> simple names in common use cases like insertin
>>>>> Russ Allbery writes:
>>>>> Ivan Shmakov writes:
>>>>> Adam Borowski writes:
>>> libtasn1-doc: libtasn1-6-dev
>>> * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is),
>>> pulled in by a very-widesp
> Adam Borowski writes:
> On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:
>> Maybe someone has a list of things they view as Recommends inflation
>> that have (a) been reported as bugs to the appropriate package
>> maintainers, and (b) have been rejected by those package
>>>>> Ben Hutchings writes:
>>>>> On Mon, 2016-10-24 at 15:15 +, Ivan Shmakov wrote:
>>>>> Ben Hutchings writes:
[…]
>>> Those certificates look as expected. Since TLS encryption of SMTP
>>> between servers is opportunisti
> Ben Hutchings writes:
[…]
> Those certificates look as expected. Since TLS encryption of SMTP
> between servers is opportunistic, there's no particular reason to use
> a widely trusted CA for server certificates. A MITM can just as
> easily block STARTTLS as substitute their own key.
>>>>> Julien Cristau writes:
>>>>> On Mon, Oct 24, 2016 at 11:45:33 +, Ivan Shmakov wrote:
[…]
>> Speaking of which. Does the gnutls-cli transcript MIMEd signify of
>> an ongoing MitM attack, or is it just a misconfiguration?
> Neither.
>>>>> Andrey Rahmatullin writes:
>>>>> On Mon, Oct 24, 2016 at 11:45:33AM +, Ivan Shmakov wrote:
>> $ gnutls-cli --starttls -p 25 bendel.debian.org
[…]
>> Connecting to '82.195.75.100:443'...
> I cannot reproduce gnutls-cli
> Kristian Erik Hermansen writes:
> On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk wrote:
[…]
>> For the kind of attacks you are describing, https is just snake oil.
> Profusely disagree and so do other members of this list. I'll leave
> it at that, but also I should point out that y
> Eugene V Lyubimkin writes:
[…]
> I'm not sure that benefits outweigh the costs. HTTPS requires that
> I trust the third-parties – mirror provider and CA. Gpgv doesn't
> require third parties.
It does; you have to trust whatever source you’ve /initially/
got the public
>>>>> Lars Wirzenius writes:
>>>>> On Sun, Oct 16, 2016 at 11:50:46AM +, Ivan Shmakov wrote:
>> Doesn’t the presence of the ‘non-free’ section in the official
>> Debian Release (InRelease) files /already/ mislead inexperienced
>> people in
> Jakub Wilk writes:
[…]
> On a semi-unrelated note:
> Some of ftp*.*.d.o and cdimage.d.o mirrors serve random free (and
> sometimes non-free) software that is not Debian[*]. This may mislead
> inexperienced people into thinking that this software is endorsed or
> even produced by Deb
> Axel Wagner writes:
[…]
> I don't think Lennart personally would care, no, but I think *we*
> should care to paint the Opensource community as better than this.
As a member of the said community, I think that, however the
presence of either of the packages in Debian pain
>>>>> Vincent Bernat writes:
>>>>> ❦ 3 décembre 2014 16:47 GMT, Ivan Shmakov :
>>> The problem with those groups is that they are not fine grained
>>> enough. For example, the video group gives access to the
>>> framebuffer device (th
> Josselin Mouette writes:
[…]
> We are talking about the anti-feature of adding UID=1000 to the audio
> group in the installer. This is only relevant for desktop
> installations, and all desktop tasks in the same installer bring
> logind (formerly consolekit).
BTW, what about
> Vincent Bernat writes:
> ❦ 3 décembre 2014 13:55 +0100, Adam Borowski :
[…]
>>> This “adduser first-user audio” was already useless in squeeze and
>>> it hasn’t changed.
>> Only if you run logind or consolekit. Without them (ie, on headless
>> boxes or with classic-type WMs) you
>>>>> Josselin Mouette writes:
>>>>> Le dimanche 30 novembre 2014 à 12:50 +, Ivan Shmakov a écrit :
[…]
>> For home installs, I see no reason for the owner of the device to be
>> /denied/ access to the sound card just because of using SSH. Why
>>>>> Vincent Bernat writes:
>>>>> ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov :
[…]
>> Or does the above concerns the users of “normally battery-powered”
>> devices instead?
> Previously, every DE would need to reimplement power management.
>
>>>>> Josselin Mouette writes:
>>>>> Le samedi 29 novembre 2014 à 16:37 +, Ivan Shmakov a écrit :
>>>>> Josselin Mouette writes:
[…]
>>> Desktops (not only GNOME) use a very tiny bit of systemd,
>>> interfaces that could be
>>>>> Zbigniew Jędrzejewski-Szmek writes:
>>>>> On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote:
>>>>> Zbigniew Jędrzejewski-Szmek writes:
[…]
>>> The second part, making systemd portable, has already been widely
>&
> Zbigniew Jędrzejewski-Szmek writes:
[…]
> The second part, making systemd portable, has already been widely
> discussed. There are significant technical reasons why systemd is
> Linux only. And the potential "recepients", like BSD, don't seem to
> be interested anyway.
Unles
> Josselin Mouette writes:
[…]
> Desktops (not only GNOME) use a very tiny bit of systemd, interfaces
> that could be provided elsewhere.
Is that “use” as in “if available” or is that actually “require
and be sure to die unless provided”?
(Please forgive my ignora
> Vincent Lefevre writes:
> On 2012-12-02 22:04:52 +0100, Wouter Verhelst wrote:
> On Sun, Dec 02, 2012 at 12:31:00PM +0100, Vincent Lefevre wrote:
[…]
>>> You may want relations between key-value pair. For instance, if
>>> you have a line with a key "foo", then a line with a key
> Игорь Пашев writes:
> 2012/12/2 Vincent Lefevre :
>> No, that's not sufficient. You may want relations between key-value
>> pair. For instance, if you have a line with a key "foo", then a line
>> with a key "bar" must also exist. Or a line with a key "number" must
>> have a value th
> Christoph Anton Mitterer writes:
[…]
> But it also has disadvantages to the mbox formats which may be
> crucial for some people:
> - wasting a lot of storage, which can be significant even if you use
> small file systems block sizes...
Only as long as static mbox files are co
> Adam Borowski writes:
[…]
> Quoting from that page:
> # With the advent and now widespread adoption of the superior Maildir
> # format over the past several years, the entire "mbox" family of
> # mailbox formats is gradually becoming irrelevant, and of only
> # historical interest.
>>>>> Jakub Wilk writes:
>>>>> * Ivan Shmakov , 2012-11-26, 14:32:
>> Seriously, XML takes a lot of concerns off an application
>> programmer. It provides quoting, arbitrary hierarchical structure,
>> support for different encodings, etc
> Norbert Preining writes:
[...]
> Ever heard of grep, sed, awk, all these nice things that make
> your life happy. Trash them when you are doing XML.
JFTR: there's xmlstarlet(1), which is capable enough to replace
awk(1), sed(1), and grep(1) (which is more often th
>>>>> Neil Williams writes:
>>>>> Ivan Shmakov wrote:
>>>>> Neil Williams writes:
[…]
>> To note is that Source: gnunet has contrib/report.sh, which calls
>> gettext(1), but it doesn't seem to be propagated to any of the
>&g
> Neil Williams writes:
[…]
> Check if the package contains a shell script which supports
> translated output strings — such packages should Depend: gettext-base
> rather than drop the dependency entirely.
> I've had a quick look at gnas and it does seem that this is a case
> where get
I find somewhat unusual for the following packages to depend on
gettext, given that the latter is a collection of utilities of
interest primarily to software developers and maintainers (as
stated in its own Description:.) Could someone please clarify
on this
> 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 probably the best thing to use right now.
[…]
> (Note that
> Philipp Kern writes:
> On Thu, Oct 04, 2012 at 03:10:01PM -0400, Chris Knadle wrote:
>> Last I looked into this [which has admittedly been a while], Bind 9
>> was the only DNS server that had actually implemented DNSSEC, and
>> the others I looked at (PowerDNS, djbdns, tinydns) had s
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org
There're several packages currently in Debian testing having a
versioned dependency on the semi-virtual libhdf5-7 p
>>>>> Julien Cristau writes:
>>>>> On Sun, Sep 30, 2012 at 00:28:15 +0700, Ivan Shmakov wrote:
>> I tend to think that a re-build (via binNMU or otherwise) will be
>> sufficient for most of the packages affected.
>> Unless there'l
> Eric Valette writes:
[…]
> I do not want to compile microcode tool as a module because module
> loading juts slows down the boot process and contrarilly to many
> other package requiring firmware, this one does not enable to load
> firmware when not compiled as a module.
> So it does
>>>>> Simon McVittie writes:
>>>>> On 26/09/12 18:15, Ivan Shmakov wrote:
>>>>> Simon McVittie writes:
>>> Please research previous discussion to check that you're not
>>> missing arguments that have happened in the past,
> Henrique de Moraes Holschuh writes:
> On Fri, 28 Sep 2012, Eric Valette wrote:
>>
>>
>>
>>
>>
>> Reading the thread about microcode, I wonder why
[…]
> 1. No html, please.
And, especially, no /invalid/ HTML, please.
[…]
--
Advocating the
judici
Package: libglib2.0-0
Version: 2.32.3-1
X-Debbugs-Cc: debian-devel@lists.debian.org
[Filing bug, as was suggested in the debian-devel@ discussion
[1]. I've also started a discussion in gtk-devel-list@ [2].]
Currently, it's not possible for the user to specify an
a
>>>>> Simon McVittie writes:
>>>>> On 26/09/12 17:12, Ivan Shmakov wrote:
>> (Want to use the all-defaults configuration for a program? Just
>> start it like: $ HOME="$(mktemp -dt -- foo.)" foo)
> Debian's GLib has been pat
I do remember filing a bug or two against packages that refer to
the getent () data to find the user's “home” directory instead
of using the HOME environment variable.
The environment is the preferred place to check for this kind of
things: it's (usually) un
> Joenio Costa writes:
> Package: wnpp
> Severity: wishlist
> Owner: Joenio Costa
> * Package name: libarchive-rar-perl
> Version : 2.02
> Upstream Author : jean-marc boulade
> * URL : http://search.cpan.org/dist/Archive-Rar/
> * License : Perl
> Jakub Wilk writes:
[Cross-posting to packages@qa, for elvis is maintained by the QA
group.]
> Many packages remove alternatives on upgrade, only to re-add them
> later, potentially discarding manual choices of the user.
> See also bug #71621.
[…]
> Debian QA Group
> Thomas Goirand writes:
[…]
> BTW, "conffiles" is a pretty bad name. It's confusing, as you can
> see once more.
> I thought about calling it "dpkg-conffiles" which has the advantage
> of underlying that we leave the handling of the file to the
> responsibility of dpkg, keeps the sam
> martin f krafft writes:
[…]
> So the solution was to get one or two additional people, and
> eventually I was even able to invest in more fail-proof hardware.
> … and then you ask yourself what to do with all the spare cycles and
> wouldn't other LUGs profit from your setup… And you
This issue was already discussed [1], and I've filed the
respective bug report [2] (to which there was no reply so far,
though), but now I see that there's a few more packages in
Wheezy with a dependency on libhdf5-7. Consider, e. g.:
$ bzcat \
< http.debian.
> Simon McVittie writes:
[…]
> hicolor-icon-theme is really the infrastructure for a theme, rather
> than *being* a theme: it does not contain any icons of its own. It
> represents the fallback icon theme for all desktops that use
> freedesktop.org themes (GNOME, KDE, XFCE, etc.). The
Abstract
The non-data packages currently having an absolute dependency on
hicolor-icon-theme should consider downgrading it to Recommends:
at the least. The list, and the explanation, are below.
Chapter I
imagemagick
Recently, Depends: hicolor-icon-theme w
>>>>> Timo Juhani Lindfors writes:
>>>>> Ivan Shmakov writes:
>> Curiously enough, ifconfig(8) shows RX/TX byte counts, and, somehow,
>> I didn't manage to get a similar output from iproute. Any pointers?
>> TIA.
> $ ip -s link
> Marco d'Itri writes:
> On Aug 08, Arno Töll wrote:
>> ifconfig and route were around already when everyone insisted on the
>> separation of /bin and /sbin. /bin/ip is slightly newer and
>> supposed to replace ifconfig/route some day entirely.
> Just for the records, iproute entir
> The Fungi writes:
> On 2012-07-26 14:29:14 +0100 (+0100), Ian Jackson wrote:
>> We also need a general word for "someone involved with Debian in a
>> positive way". "Participant" is clumsy; "member of the community"
>> even more so. "Person" might do but word with a more positive s
> Jonathan Nieder writes:
> Goswin von Brederlow wrote:
>> What I don't understand is why compilers (which probably means ld
>> from binutils in all cases) won't use ld.so.conf to find the libs.
>> It only does so to find libs linked into libs you link against. So
>> it is used execp
> Jonas Smedegaard writes:
[…]
> It is a feature (which each user is free to avoid by not using it!)
> for Debian to include a meta-package that pulls in that vil n-m,
> not a bug.
… And what exactly this “feature” gives to the user?
[…]
--
FSF associate member #7257
> Ben Hutchings writes:
[...]
> - twm: no-one should have to suffer this
And, exactly, why not? Before I've switched to Openbox, it was
one of the two WM's I've used, along with FVWM. And they say
[1] that it still can be handy at times.
The “obscure” lab
> Alexander Kuznetsov writes:
[…]
(Some wording fixes and suggestions.)
> Description : A high speed data loading utility for PostgreSQL
> pg_bulkload is designed to load huge amount of data to a database.
> You can choose whether database constraints are checked and how many
> Thorsten Glaser writes:
> Charles Plessy dixit:
>> upstream source moved to GitHub, and we would like to try to
>> maintain the Debian package there as well.
> This is not a good idea: http://mako.cc/writing/hill-free_tools.html
That's why I tend to advocate for the use of
> Weldon Goree writes:
> On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote:
>> I think having / and /tmp share the same file system is a bad idea,
>> because then writing lots of stuff to /tmp would potentially fill up
>> the root file system (that typically also includes /var) an
> Ben Hutchings writes:
> On Sun, 2011-11-20 at 23:44 +0100, Cesare Leonardi wrote:
[…]
>> While i might agree with the exclusion of 486 cpu classes (somewhere
>> i have a Winchip C6 200 MHz but i consider it unusable except for
>> very limited tasks), i think that excluding 586 could
> Jon Dowland writes:
> On Tue, Nov 01, 2011 at 02:56:53PM +, Ian Jackson wrote:
>> We should do it when we judge that the benefits are worth the costs.
>> In this particular case the costs seem to be minimal. There isn't
>> even a direct patch-carrying cost, since the dependency
> Matthias Klumpp writes:
[…]
> It would be very nice, if ftpmasters could tell if they would accept
> a new format in the archive or if we should stay with RFC822 which is
> used for nearly everything else already.
>> Note that the same rationale stands for all metadata to be
>> event
> Adam Borowski writes:
[…]
> GNU's and the inventor of AM_MAINTAINER_MODE's stance:
> http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html
BTW, this URI seems to me like a thing to be reported to GNU
webmasters (Cc:'ed.) The Automake manual should be (and
>>>>> Ben Hutchings writes:
>>>>> On Mon, 2011-10-24 at 22:12 +0700, Ivan Shmakov wrote:
[…]
>> BTW, does the root=UUID= variant require udev as well?
> Yes, currently the kernel filesystem code does not probe for filesystem
> UUIDs. (However, it d
>>>>> Marco d'Itri writes:
>>>>> On Oct 24, Ivan Shmakov wrote:
>> So, the kernel won't try to autoload a module when the corresponding
>> device gets accessed?
> Not for *hardware* drivers, since it cannot know which driver is
>
>>>>> Timo Juhani Lindfors writes:
>>>>> Ivan Shmakov writes:
>> And what the initramfs-tools package has to do with consistent
>> devices' filenames?
> Initramfs runs udev. This allows you to use e.g.
> root=/dev/disk/by-id/ata-WDC_W
>>>>> Marco d'Itri writes:
>>>>> On Oct 24, Ivan Shmakov wrote:
>> It doesn't seem like a good reason for the aforementioned
>> dependency, does it?
> There are many other reasons, you can find them in /lib/udev/.
ACK, than
>>>>> Neil Williams writes:
>>>>> On Mon, 24 Oct 2011 18:19:08 +0700 Ivan Shmakov wrote:
>> I've found that a few packages, contrary to my expectations, have
>> Depends: on udev. I'm primarily concerned with alsa-base and
>>
I've found that a few packages, contrary to my expectations,
have Depends: on udev. I'm primarily concerned with alsa-base
and initramfs-tools, but also wonder about libcomedi0, dkopp,
python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp,
xserver-xo
> Henrique de Moraes Holschuh writes:
[…]
> I do know many of the GUI MUAs are incomplete jack-jobs that fail to
> add a handler for local system folders (i.e. were only partially
> ported to Linux). I am not sure which would be the better aproach to
> deal with this deficiency.
>>>>> Roger Leigh writes:
>>>>> On Wed, Oct 12, 2011 at 11:24:09AM +0700, Ivan Shmakov wrote:
>> With all the sort of software continuously writing to /etc/?
>> Consider, e. g., /etc/blkid.tab, which is updated almost every time
>> a removable
> Michelle Konzack writes:
> Am 2011-10-13 12:13:56, hacktest Du folgendes herunter:
>> The user will not be notified even if the daemons send a mail to
>> them. I don't think any of the desktops GUIs that we ship know
>> anything about the local mail queue unless explicitly configure
>>>>> Tollef Fog Heen writes:
>>>>> ]] Ivan Shmakov
>>>>> Tollef Fog Heen writes:
>>> (With the assumption that /usr is on a separate fs from /): You
>>> might very well need to load some drivers (be it network, FC, USB,
&
> Tollef Fog Heen writes:
>> The problem, AIUI, is that we start udev(7) before /usr is mounted.
>> As udev is prone to spawn all the sorts of software in turn, we're
>> either going to move more and more from /usr to /, /or/ to invent
>> more kluges so that udev scripts would actually wa
> Daniel Baumann writes:
> On 10/11/2011 04:32 PM, Marco d'Itri wrote:
>> I am still not 100% persuaded that this would be easy to do, but at
>> least I think that it has more merit than the old "move all to /"...
> i'd rather see a /$foo and /usr/$foo merger to /system/$foo, so we
>
>>>>> Reinhard Tartler writes:
>>>>> On Mi, Okt 12, 2011 at 06:09:00 (CEST), Ivan Shmakov wrote:
[…]
> AFAIUI Harald (the fedora maintainer for their initramfs tool
> dracut), he dislikes having a separate set of tools in /usr and the
> initramfs, i.e.,
> Philipp Kern writes:
> On 2011-10-11, Ognyan Kulev wrote:
> На 11.10.2011 17:32, Marco d'Itri написа:
[…]
>> /usr/src -> /usr/share/src
> Probably depends if you want to support compile outputs there. I
> guess some people compile their kernels there.
Which isn't a g
> unruh writes:
> On 2011-10-12, Marco d'Itri wrote:
[…]
>> So let's look at the reasons against merging /usr in / listed in my
>> final summary. All of them do not apply to merging / in /usr, and
>> actually become arguments in favour of doing it:
>> - NFS: sharing a read only sy
> Marco d'Itri writes:
[…]
> And then there is the big argument in favour of it: booting without
> /usr is becoming more and more difficult. The two current solutions
> for this adopted by udev and the related tools are both suboptimal:
> waiting in a loop for /usr to appear can fail du
> Marco d'Itri writes:
[…]
> So let's look at the reasons against merging /usr in / listed in my
> final summary. All of them do not apply to merging / in /usr, and
> actually become arguments in favour of doing it:
> - NFS: sharing a read only system over NFS becomes much easier (I
>
>>>>> Mike Hommey writes:
>>>>> On Wed, Oct 12, 2011 at 01:13:38AM +0700, Ivan Shmakov wrote:
>>>>> Marco d'Itri writes:
[…]
>>> No, we discussed the idea of merging /usr in / (to which I was
>>> opposed myself as well). Th
> Marco d'Itri writes:
> On Oct 11, Josselin Mouette wrote:
> Le mardi 11 octobre 2011 à 16:32 +0200, Marco d'Itri a écrit :
>>> I am still not 100% persuaded that this would be easy to do, but at
>>> least I think that it has more merit than the old "move all to
>>> /"...
>> W
>>>>> Marco d'Itri writes:
>>>>> On Oct 11, Ivan Shmakov wrote:
>> Saving a dozen of bytes in ${PATH} doesn't seem like an
>> astonishing idea, anyway. What's the point, then?
> It is explained in the Red Hat wiki page. T
1 - 100 of 144 matches
Mail list logo
