Re: Policy consensus on transition when removing initscripts.

> "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

[i386] adlibtracker2 and fp-units-i386

> 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 >

Re: i386 in the future

> 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

Re: An email address for drive-by bug reports?

>>>>> 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

Re: An email address for drive-by bug reports?

> 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

possible MMBF regarding Depends: locales without | locales-all?

Сс: 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

Re: no{thing} build profiles

> 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,

Re: no{thing} build profiles

> 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

Re: tinysshd dependency on systemd

>>>>> 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

Re: no{thing} build profiles

>>>>> 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

Re: no{thing} build profiles

>>>>> 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

Re: tinysshd dependency on systemd

>>>>> 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 >>> depende

tinysshd dependency on systemd

>>>>> 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

Re: no{thing} build profiles

>>>>> 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 wh

Re: Debian Buster release to partially drop non-systemd support

> 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

Re: no{thing} build profiles

> 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

no{thing} build profiles

> 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

Re: debian/control file: how to selectively suppress recommends?

> 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

Re: make dpkg-buildpackage default locale UTF-8

>>>>> Tollef Fog Heen <tfh...@err.no> writes: >>>>> Ivan Shmakov >>>>> Hans-Christoph Steiner <h...@eds.org> writes: >>> Package: dpkg-dev >>> More and more packages are adding unicode files >> I assume you me

Re: make dpkg-buildpackage default locale UTF-8

> 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

Naming of network devices

> 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

Recommends-If-Manual: ?

>>>>> Russ Allbery <r...@debian.org> writes: >>>>> Ivan Shmakov <i...@siamics.net> writes: >>>>> Adam Borowski <kilob...@angband.pl> writes: >>> libtasn1-doc: libtasn1-6-dev >>> * TRANSITIVELY BAD: probably us

Re: Too many Recommends (in particular on mail-transport-agent)

> 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

Re: when should we esmtps our mxes?

>>>>> Ben Hutchings <b...@decadent.org.uk> writes: >>>>> On Mon, 2016-10-24 at 15:15 +, Ivan Shmakov wrote: >>>>> Ben Hutchings <b...@decadent.org.uk> writes: […] >>> Those certificates look as expected. Since TLS

Re: when should we esmtps our mxes?

> 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

Re: when should we esmtps our mxes?

>>>>> Julien Cristau <jcris...@debian.org> 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

Re: when should we esmtps our mxes?

>>>>> Andrey Rahmatullin <w...@debian.org> 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 rep

when should we esmtps our mxes?

> 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 >

Re: client-side signature checking of Debian archives

> 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/

Re: non-Debian software on ftp*.*.debian.org mirrors

>>>>> Lars Wirzenius <l...@liw.fi> 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 inexperie

non-Debian software on ftp*.*.debian.org mirrors

> 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 >

Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows

Axel Wagner m...@merovius.de 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

Re: DE features dependent on Systemd

Vincent Bernat ber...@debian.org writes: ❦ 3 décembre 2014 13:55 +0100, Adam Borowski kilob...@angband.pl : […] 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

Re: DE features dependent on Systemd

Josselin Mouette j...@debian.org 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

Re: DE features dependent on Systemd

Vincent Bernat ber...@debian.org writes: ❦ 3 décembre 2014 16:47 GMT, Ivan Shmakov i...@siamics.net : The problem with those groups is that they are not fine grained enough. For example, the video group gives access to the framebuffer device (the user can do a screenshot) or to a webcam

DE features dependent on Systemd

Josselin Mouette j...@debian.org writes: Le samedi 29 novembre 2014 à 16:37 +, Ivan Shmakov a écrit : Josselin Mouette j...@debian.org writes: […] Desktops (not only GNOME) use a very tiny bit of systemd, interfaces that could be provided elsewhere. Is that “use

Re: DE features dependent on Systemd

Vincent Bernat ber...@debian.org writes: ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov i...@siamics.net : […] Or does the above concerns the users of “normally battery-powered” devices instead? Previously, every DE would need to reimplement power management. Now, this is handled

Re: DE features dependent on Systemd

Josselin Mouette j...@debian.org 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, it’s exactly what I do. (I even did

Re: Technical committee acting in gross violation of the Debian constitution

Josselin Mouette j...@debian.org 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

Re: Technical committee acting in gross violation of the Debian constitution

Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 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.

Re: Technical committee acting in gross violation of the Debian constitution

Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl writes: […] The second part, making systemd portable, has already been widely discussed. There are significant technical

[OT] config file formats

Игорь Пашев pashev.i...@gmail.com writes: 2012/12/2 Vincent Lefevre vinc...@vinc17.net: 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

[OT] config file formats

Vincent Lefevre vinc...@vinc17.net 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 bar

Re: Maildir vs. mbox in Debian

Christoph Anton Mitterer cales...@scientia.net 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

Maildir vs. mbox in Debian

Adam Borowski kilob...@angband.pl 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

Re: [OT] XML

Jakub Wilk jw...@debian.org writes: * Ivan Shmakov oneing...@gmail.com, 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. Why, don't you think that $ grep

[OT] XML

Norbert Preining prein...@logic.at 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

Re: non-developer packages depending on gettext?

Neil Williams codeh...@debian.org writes: Ivan Shmakov oneing...@gmail.com wrote: Neil Williams codeh...@debian.org 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 binaries currently depending

Re: non-developer packages depending on gettext?

Neil Williams codeh...@debian.org 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

non-developer packages depending on gettext?

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

Re: Packages removing alternatives on upgrade

Russ Allbery r...@debian.org 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 foo path-to-foo fi is probably the best thing to use right now. […]

Bug#689572: nmu: packages linked against libhdf5-7 1.8.8-7.1

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

Re: where is the DNSSEC root key?

Philipp Kern pk...@debian.org 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

Re: mass bug filing about versioned dependency on the libhdf5-7 virtual package

Julien Cristau julien.cris...@logilab.fr 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'll be objections, I'm going to file the respective bug

[OT] kernel modules

Eric Valette eric.vale...@free.fr 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.

Re: Processor microcode update packages

Henrique de Moraes Holschuh h...@debian.org writes: On Fri, 28 Sep 2012, Eric Valette wrote: html head meta http-equiv=content-type content=text/html; charset=UTF-8 /head body bgcolor=#CC text=#00 font size=-1Reading the thread about microcode, I wonder why

Re: ${HOME} vs. g_get_home_dir ()

Simon McVittie s...@debian.org writes: On 26/09/12 18:15, Ivan Shmakov wrote: Simon McVittie s...@debian.org writes: Please research previous discussion to check that you're not missing arguments that have happened in the past, Any particular pointers? Following the git history

Bug#688932: g_get_home_dir () should prefer ${HOME} over getpwuid ()-pw_dir

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

${HOME} vs. g_get_home_dir ()

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)

Re: ${HOME} vs. g_get_home_dir ()

Simon McVittie s...@debian.org 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 patched, and actually has this precedence: G_HOME getpwent

Re: Bug#688826: ITP: libarchive-rar-perl -- interface for the 'rar' command

Joenio Costa joe...@colivre.coop.br writes: Package: wnpp Severity: wishlist Owner: Joenio Costa joe...@colivre.coop.br * Package name: libarchive-rar-perl Version : 2.02 Upstream Author : jean-marc boulade jmbp...@hotmail.com * URL :

Re: Packages removing alternatives on upgrade

Jakub Wilk jw...@debian.org 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

conffiles

Thomas Goirand z...@debian.org 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

Re: status of eligibility of dug lists on lists.debian.org

martin f krafft madd...@debian.org 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…

versioned dependency on the libhdf5-7 virtual package

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 \

Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

Simon McVittie s...@debian.org 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,

Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?

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

[OT] ifconfig(8)

Marco d'Itri m...@linux.it writes: On Aug 08, Arno Töll a...@debian.org 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,

Re: [OT] ifconfig(8)

Timo Juhani Lindfors timo.lindf...@iki.fi writes: Ivan Shmakov oneing...@gmail.com 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 show lo 1: lo: LOOPBACK,UP,LOWER_UP

Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers

The Fungi fu...@yuggoth.org 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 spin

Re: Bug#637232: Multiarch breaks support for non-multiarch toolchain

Jonathan Nieder jrnie...@gmail.com 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

Re: Recommends for metapackages

Jonas Smedegaard d...@jones.dk 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

Re: CD sizes again (and BoF reminder!)

Ben Hutchings b...@decadent.org.uk 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.

Re: Packaging on GitHub ?

Thorsten Glaser t...@mirbsd.de 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

Re: Bug#675106: ITP: pgbulkload -- A high speed data loading utility for PostgreSQL

Alexander Kuznetsov a...@cpan.org 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

/tmp on multi-FS set-ups, or: block users from using /tmp?

Weldon Goree wel...@b.rontosaur.us 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

Re: Increasing minimum 'i386' processor

Ben Hutchings b...@decadent.org.uk 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

Re: Advocating the use of RDF for Debian's published metadata

Matthias Klumpp matth...@tenstral.net 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

Re: Bug#645656: network-manager in Gnome

Jon Dowland j...@debian.org 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

http://www.gnu.org/s/hello/manual/automake/ ?

Adam Borowski kilob...@angband.pl 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

udev: what does it used for in Debian?

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,

Re: udev: what does it used for in Debian?

Neil Williams codeh...@debian.org 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 initramfs-tools, but also wonder about libcomedi0, dkopp

Re: udev: what does it used for in Debian?

Marco d'Itri m...@linux.it writes: On Oct 24, Ivan Shmakov i...@gray.siamics.net 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, thanks. And what the initramfs-tools

Re: udev: what does it used for in Debian?

Timo Juhani Lindfors timo.lindf...@iki.fi writes: Ivan Shmakov i...@gray.siamics.net 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_WD3200AAJS-65B4A0_WD

Re: udev: what does it used for in Debian?

Marco d'Itri m...@linux.it writes: On Oct 24, Ivan Shmakov i...@gray.siamics.net 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 needed. Not even via

Re: udev: what does it used for in Debian?

Ben Hutchings b...@decadent.org.uk 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 does support partition UUIDs as used

MUA's vs. local mail

Henrique de Moraes Holschuh h...@debian.org 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.

Move mtab, etc. below /run

Roger Leigh rle...@codelibre.net 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 media is connected to the system. Or /etc

Re: RFC: Making mail-transport-agent Priority: optional

Michelle Konzack linux4miche...@tamay-dogan.net 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

Re: Move all to /usr

Philipp Kern tr...@philkern.de writes: On 2011-10-11, Ognyan Kulev o...@tower.3.bg 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.

Re: / vs. /usr vs. fsck(8)

Reinhard Tartler siret...@debian.org 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., he strongly favors putting glibc

Re: Move all to /usr

Daniel Baumann daniel.baum...@progress-technologies.net 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

Re: Move all to /usr

Tollef Fog Heen tfh...@err.no 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

Re: Move all to /usr

Tollef Fog Heen tfh...@err.no writes: ]] Ivan Shmakov Tollef Fog Heen tfh...@err.no 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, SATA or something else) and probe some bits (iSCSI auth

Re: Move all to /usr

Marco d'Itri m...@linux.it writes: On Oct 11, Sven Joachim svenj...@gmx.de wrote: Rather complex, I'm afraid. Especially as not all architectures even support an initramfs, AFAIK. I doubt this, since the initramfs can be embedded in the kernel image itself (and indeed it always

Re: Move all to /usr

Marco d'Itri m...@linux.it writes: On Oct 11, Ivan Shmakov i...@gray.siamics.net 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. Try reading it again. Indeed, I've just

Re: Move all to /usr

Marco d'Itri m...@linux.it writes: On Oct 11, Josselin Mouette j...@debian.org 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 /...

Re: Move all to /usr

Mike Hommey m...@glandium.org writes: On Wed, Oct 12, 2011 at 01:13:38AM +0700, Ivan Shmakov wrote: Marco d'Itri m...@linux.it writes: […] No, we discussed the idea of merging /usr in / (to which I was opposed myself as well). This is a different concept. The only significant

/ vs. /usr vs. fsck(8)

Marco d'Itri m...@linux.it 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

/ vs. /usr vs. udev(7)

Marco d'Itri m...@linux.it 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

  1   2   >