Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Andrea Pappacoda
Severity: wishlist
* Package name: android-udev-rules
Version : 0~20250314-1
Upstream Contact: https://github.com/M0Rf30/android-udev-rules/issues
* URL : https://github.com/M0Rf30
Am 04.01.24 um 18:57 schrieb Michael Biebl:
Hi fellow DDs,
due to popular request, the pkg-config files systemd.pc and udev.pc have
been split into a separate arch:all package named systemd-dev.
A lot of packages Build-Depend on systemd and/or udev to get the paths
such as
Hi fellow DDs,
due to popular request, the pkg-config files systemd.pc and udev.pc have
been split into a separate arch:all package named systemd-dev.
A lot of packages Build-Depend on systemd and/or udev to get the paths
such as systemd_system_unit_dir or udev_dir for installation of upstream
On Tue, 31 Mar 2020 at 10:17:23 -0500, Ryan Pavlik wrote:
> Also, it is a free partial alternative to the steam-devices non-free package
> for
> the Steam-related devices that are VR/AR related.
The actual udev rules in steam-devices are MIT/X11-licensed, but they're
part of th
Package: wnpp
Severity: wishlist
Owner: Ryan Pavlik
* Package name: xr-hardware
Version : 0.2.1
Upstream Author : Ryan Pavlik
* URL : https://gitlab.freedesktop.org/monado/utilities/xr-hardware
* License : BSL-1.0
Programming Lang: udev rules, generated by
Nicolas Braud-Santoni writes ("Re: Bug#899299: libu2f-udev: Post-inst script
should make udev reload rules"):
> On Sun, Jun 03, 2018 at 06:20:03PM +0100, James Cowgill wrote:
> > Running a command from another package in postinst only requires a
> > normal Depends - not a
On Jun 04, Philipp Kern wrote:
> Is this synchronous, or does one also need a call to "udevadm settle"? I
> had a problem with kpartx where the loop devices were not available
> after the package was installed, likely because of a race. I wonder if a
Yes, events in udev
7;re interested in (see the udevadm man page).
Is this synchronous, or does one also need a call to "udevadm settle"? I
had a problem with kpartx where the loop devices were not available
after the package was installed, likely because of a race. I wonder if a
feature request would make sens
colas Braud-Santoni wrote:
> >> [libu2f-udev's post-inst script should make udev reload rules.]
> >> Otherwise, the rules are not active until the next reboot (or until the
> >> user
> >> manually calls `udevadm control -R`).
> >
> > To fix
Hi,
On 03/06/18 16:08, Nicolas Braud-Santoni wrote:
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> Hi Debianites !
>
> On Tue, May 22, 2018 at 10:23:33AM +0200, Nicolas Braud-Santoni wrote:
>> [libu2f-udev's post-inst script should make udev reload rules.]
>&
X-Debbugs-CC: debian-devel@lists.debian.org
Hi Debianites !
On Tue, May 22, 2018 at 10:23:33AM +0200, Nicolas Braud-Santoni wrote:
> [libu2f-udev's post-inst script should make udev reload rules.]
> Otherwise, the rules are not active until the next reboot (or until the user
>
Package: wnpp
Severity: wishlist
Owner: Ville Ranki
* Package name: perse
Version : 1.0.2
Upstream Author : Ville Ranki
* URL : https://github.com/vranki/perse
* License : GPLv3
Programming Lang: C++
Description : Permission settings GUI for udev
Package: wnpp
Severity: wishlist
Owner: Ian Campbell
* Package name: lua-udev
Version : 0.2
Upstream Author : dodo
* URL : https://github.com/dodo/lua-udev
* License : Expat
Programming Lang: Lua, C
Description : udev library for the Lua language
On May 18, Mathieu Malaterre wrote:
> Could a udev guru please comment on the (somewhat) famous issue
> `Transport endpoint is not connected` happening when a udev rule tries
> to mount fuse filesystem ? The only description I found of this issue
I think that the fuse process is bei
On Monday 18 May 2015 15:10:56 Mathieu Malaterre wrote:
> 1. What is the actual issue of ``udev`` vs ``fuse``
> 2. What (if possible) is needed to make a *udev* rules mount a FUSE
> filesystem (I do not really care for proper umount for now).
I can only guess that:
- mounting a file sy
I have seen this issue outside of udev, for iRODS mounting filesystems
via fuse;
if there was a break in connectivity (network) the kernel driver would
crash,
and this problem would occur.
On 18/05/2015 14:10, Mathieu Malaterre wrote:
> On Mon, May 18, 2015 at 3:00 PM, Dominique Dumont wr
On Mon, May 18, 2015 at 3:00 PM, Dominique Dumont wrote:
> On Monday 18 May 2015 14:13:46 Mathieu Malaterre wrote:
>> Could a udev guru please comment on the (somewhat) famous issue
>> `Transport endpoint is not connected` happening when a udev rule tries
>> to mount fuse
On Monday 18 May 2015 14:13:46 Mathieu Malaterre wrote:
> Could a udev guru please comment on the (somewhat) famous issue
> `Transport endpoint is not connected` happening when a udev rule tries
> to mount fuse filesystem ? The only description I found of this issue
> appear on archli
Could a udev guru please comment on the (somewhat) famous issue
`Transport endpoint is not connected` happening when a udev rule tries
to mount fuse filesystem ? The only description I found of this issue
appear on archlinux wiki, it does not explain the actual issue: it
only tells you one should
They are stable as long as the kernel and the hardware do not change too
much; e.g. enabling the "other" graphics card in a hybrid setup
sometimes adds a PCIe bus, so all names shift around.
Or adding something like a firewire card which happens to be based on a
PCIe to PCI bridge chip would
le,
>> and do not change on every VM reboot...
[..]
> There are still race conditions.
The point here is, that the new network naming scheme doesn't reuse the
ethX namespace but completely different names which do not clash with
the kernel names.
Say you have two network interface
Btw, we didn't remove support for the new predictable network interface
naming scheme.
It's explicitly opt-in atm and you can use it by setting the
net.ifnames=1 kernel command line parameter [1].
Existing NAMEs set via /etc/udev/rules.d/70-persistent-net.rules still
take precedence, s
hcp
iface mbb inet dhcp
iface testv4 inet dhcp
iface testv6 inet6 manual
iface usb0 inet dhcp
iface usb1 inet dhcp
iface tap0 inet manual
iface tap0.42 inet manual
iface bnep0 inet dhcp
Only two of them have persistent entries and can be expected to continue
working:
bjorn@nemi:~$ grep NAME /etc
d keep renaming
> the same card to eth0. So you need to assume something more to have an
> example of a problem case.
As I mentioned earlier, the problem is for those cases, where we
*didn't* generate persistent network interface names and used the kernel
provided names.
The conditions are
t; use case, physical hardware is used to run the virtual machine images
>> without virtualization. It is *not possible to choose the MAC*, as this
>> is the one that is physically in the hardware, though udev should
>> continue to behave "as if it was a virtual machine MAC add
Russ Allbery wrote:
>Kay Sievers writes:
> > Hmm, why would upgrades break?
>
> > The old file would still be there, rename the devices (if you keep the
> > patch to swap names, which upstream does not support any more), and take
> > precedence over tht new names; the old rules file would just no
Am 10.09.2013 00:05, schrieb Kay Sievers:
> On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl wrote:
>> Am 09.09.2013 23:53, schrieb Kay Sievers:
>>> Hmm, why would upgrades break?
>>
>> See [1], there are several cases where 75-persistent-net-generator.rules
>> doesn't generate a persistent name (m
Kay Sievers writes:
> On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl wrote:
>> We (Debian pkg-systemd team) decided to keep the old persistent naming
>> scheme "as default" for now, for the simple reason, that we didn't want
>> to break upgrades. It just didn't seem possible to detect every case
On Tue, Sep 10, 2013 at 12:00 AM, Michael Biebl wrote:
> Am 09.09.2013 23:53, schrieb Kay Sievers:
>> Hmm, why would upgrades break?
>
> See [1], there are several cases where 75-persistent-net-generator.rules
> doesn't generate a persistent name (mostly VM related). In those cases,
> you would ty
cause the
> namespace is mostly depleted these days...)
There is no shortage of namespace; only a tiny fraction of the 2^22
valid OUIs have been allocated. But perhaps some OUIs are abused for
volatile and non-unique assignments and you're right that this breaks
the old naming policy.
Th
Hi Kay,
Am 09.09.2013 23:53, schrieb Kay Sievers:
> Hmm, why would upgrades break?
See [1], there are several cases where 75-persistent-net-generator.rules
doesn't generate a persistent name (mostly VM related). In those cases,
you would typically use eth0 in your /etc/network/interface etc.
On u
Hi Kay,
Am 09.09.2013 23:53, schrieb Kay Sievers:
> Hmm, why would upgrades break?
See [1], there are several cases where 75-persistent-net-generator.rules
doesn't generate a persistent name (mostly VM related). In those cases,
you would typically use eth0 in your /etc/network/interface etc.
On u
tile and non-unique assignments and you're right that this breaks
> the old naming policy.
>
> The new udev policy isn't any better for Thomas's use case, though.
> He seems to want to take his chances with kernel probing order...
It's hopefully still better for most v
On Mon, Sep 9, 2013 at 11:48 PM, Michael Biebl wrote:
> Am 09.09.2013 20:50, schrieb Lennart Poettering:
>> It's now a Debianism to stick to the persistant names, all support for
>> it has been removed upstream. From upstream we hope DEbian eventually
>> drops support for the old persistant names
Hi Lennart,
Am 09.09.2013 20:50, schrieb Lennart Poettering:
> It's now a Debianism to stick to the persistant names, all support for
> it has been removed upstream. From upstream we hope DEbian eventually
> drops support for the old persistant names too.
We (Debian pkg-systemd team) decided to k
ible to choose the MAC*, as this
> is the one that is physically in the hardware, though udev should
> continue to behave "as if it was a virtual machine MAC address".
>
> Therefore, I think there should be an easy, documented way, of telling
> udev to behave one way or an
the usual VM case).
>
> You'll need to install rules that work out which interface should be
> 'eth0' (or, better, some meaningful name) based on the site conventions
> for wiring up network ports.
Note that such a convention is already the default in upstream udev [1]
(at least ass
#x27;s not something I've ever heard of people
doing on a regular basis, but I can see you would want to override
udev's behaviour in this case.
> It is *not possible to choose the MAC*, as this
> is the one that is physically in the hardware, though udev should
> continue to behave
arted on another hardware. In such
use case, physical hardware is used to run the virtual machine images
without virtualization. It is *not possible to choose the MAC*, as this
is the one that is physically in the hardware, though udev should
continue to behave "as if it was a virtual machine
you use the OpenStack
> >> bare metal driver, then you continue to use virtual machine images,
> >> though they will be used on a real hardware where you can't change
> >> the MAC address.
> >
> > So you're saying, when your NIC is tied to actu
achine images,
>> though they will be used on a real hardware where you can't change
>> the MAC address.
>
> So you're saying, when your NIC is tied to actual physical hardware,
> udev behaves as though it is tied to actual physical hardware.
No. I'm saying t
Michael Biebl writes:
> The persistent network interface naming rules are already skipped if
> udev is run within a virtual machine.
Which made me look closer at
/lib/udev/rules.d/75-persistent-net-generator.rules
I find it a bit strange that it has lots of logic involving different
OUI
have to hack and
> hack again? I'm sure I'm not the only one to think that dpkg-divert
> over-engineering something that should be fixed upstream.
The least ugly thing we came up with was:
$ cat /lib/udev/rules.d/60-${our_package}.rules
# Avoid udev persistent names (see
# /lib/udev/r
I think I gonna simply skip the udev rules overriding, it will be up to the
user to do the cleaning if he wants to do cloning etc... as done in
cloud-init package, waiting for easier udev management from package side.
Thanks to all for your advises.
quoting previous...
--
>
> gpg
you can't change
> the MAC address.
So you're saying, when your NIC is tied to actual physical hardware,
udev behaves as though it is tied to actual physical hardware.
Seriously, the reason for udev to not make a VM NIC persistent is not
because it is virtual, per se, but because ce
generator.rules file (which I know is
> > the wrong way to do it as it wont survive upgrades, though I currently
> > don't know how to do it cleanly, so I have fallen back to that).
>
> touch /etc/udev/rules.d/75-persistent-net-generator.rules
>
> yeap, as a user, but
ay to do it as it wont survive upgrades, though I currently
> don't know how to do it cleanly, so I have fallen back to that).
touch /etc/udev/rules.d/75-persistent-net-generator.rules
http://anonscm.debian.org/gitweb/?p=mirror/dsa-misc.git;a=blob;f=scripts/VM-installs/ganeti-bytemark;
On 08/20/2013 11:44 PM, Vincent Bernat wrote:
> ❦ 20 août 2013 22:00 CEST, Thomas Goirand :
>
>>> I did not know that udev skipped (at least) persistent-net in virtual
>>> machines so I did not try without those replacement rules (how does it
>>> know it is a vi
❦ 20 août 2013 22:00 CEST, Thomas Goirand :
>> I did not know that udev skipped (at least) persistent-net in virtual
>> machines so I did not try without those replacement rules (how does it
>> know it is a virtual machine?).
>
> Oh, missed that part! I also would be h
Ccing the list
-- Message transféré --
De : "olivier sallou"
Date : 20 août 2013 22:27
Objet : Re: overriding udev rules
À : "Thomas Goirand"
Le 20 août 2013 22:18, "Thomas Goirand" a écrit :
>
> On 08/20/2013 07:02 PM, olivier sallou
On 08/20/2013 07:02 PM, olivier sallou wrote:
> I did not know that udev skipped (at least) persistent-net in virtual
> machines so I did not try without those replacement rules (how does it
> know it is a virtual machine?).
Oh, missed that part! I also would be happy to know how i
On 08/20/2013 07:02 PM, olivier sallou wrote:
> ok,
> I am packaging a package for OpenNebula that is to be installed on
> virtual machine images.
> It does many setup at startup.
> Among other things, in upstream packages, it replaces 2 udev rules:
> 75-cd-aliases-gene
2013/8/20 olivier sallou
>
>
>
> 2013/8/20 Michael Biebl
>
>> Am 20.08.2013 10:39, schrieb olivier sallou:
>> > hi,
>> > I need for a package to override some udev standard rules.
>> >
>> > If I put an identical rule name in /etc/udev/
2013/8/20 Michael Biebl
> Am 20.08.2013 10:39, schrieb olivier sallou:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
>
> olivier sallou writes:
> > hi,
> > I need for a package to override some udev standard rules.
> >
> > If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> > the one in /lib/udev/rules.d
> >
> >
> > However, lintian raise
On Aug 20, olivier sallou wrote:
> This particular package is for use in virtual machines creation where
> package removes default network persistence.
Please explain what you are actually trying to achieve.
> Is there an other way to override udev rules in package or should I simply
&
On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote:
> I need for a package to override some udev standard rules.
Well. This would be not suitable for a package in Debian itself.
> However, lintian raises an error if I put an udev rule in /etc instead of
> /lib.
lintian is
Am 20.08.2013 10:39, schrieb olivier sallou:
> hi,
> I need for a package to override some udev standard rules.
>
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
>
>
> However, lintian raises an error if I
On Tue, Aug 20, 2013 at 10:39:13AM +0200, olivier sallou wrote:
> hi,
> I need for a package to override some udev standard rules.
>
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
> [...]
> Is there an other way to o
olivier sallou writes:
> hi,
> I need for a package to override some udev standard rules.
>
> If I put an identical rule name in /etc/udev/rules.d, I know it overrides
> the one in /lib/udev/rules.d
>
>
> However, lintian raises an error if I put an udev rule in /etc inste
hi,
I need for a package to override some udev standard rules.
If I put an identical rule name in /etc/udev/rules.d, I know it overrides
the one in /lib/udev/rules.d
However, lintian raises an error if I put an udev rule in /etc instead of
/lib.
And if I try to put the file in /lib, it fails at
On Wed, Dec 05, 2012 at 07:03:23PM +0800, Thomas Goirand wrote:
> On 12/05/2012 06:15 AM, Steve Langasek wrote:
> > I understand that concern and recognize that this is a not-uncommon
> > sentiment among Debian folks; this very closely parallels the question of
> > whether one is willing to release
On 12/05/2012 06:15 AM, Steve Langasek wrote:
> I understand that concern and recognize that this is a not-uncommon
> sentiment among Debian folks; this very closely parallels the question of
> whether one is willing to release software under a BSD license - or the MPL
> - vs. the GPL. But while s
On Tue, Dec 04, 2012 at 06:42:37PM +, Ian Jackson wrote:
> Barry Warsaw writes ("Re: Contributor agreements and copyright assignment
> (was Re: Really, about udev, not init sytsems)"):
> > FTR: http://www.canonical.com/contributors
> That allows Canonical to make
Ian Jackson writes:
> Barry Warsaw writes ("Re: Contributor agreements and copyright assignment
> (was Re: Really, about udev, not init sytsems)"):
>> FTR: http://www.canonical.com/contributors
>
> That allows Canonical to make proprietary forks of the code
On Dec 04, 2012, at 06:42 PM, Ian Jackson wrote:
>That allows Canonical to make proprietary forks of the code (eg, to
>engage in the dual licensing business model). This is very
>troublesome for me; it's too asymmetric a relationship.
Not to diminish your own concerns, but it doesn't bother me.
Barry Warsaw writes ("Re: Contributor agreements and copyright assignment (was
Re: Really, about udev, not init sytsems)"):
> FTR: http://www.canonical.com/contributors
That allows Canonical to make proprietary forks of the code (eg, to
engage in the dual licensing business model).
On Dec 01, 2012, at 07:21 AM, Clint Byrum wrote:
>Just any FYI, Canonical no longer requires copyright assignment in their
>CLA. You are still giving Canonical an unlimited perpetual license on the
>code, but you retain your own copyrights.
FTR: http://www.canonical.com/contributors
with embedde
On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
> the discussion that systemd is a bad design because it uses the same
> configuration file syntax as Windows ini files or XDG .desktop files,
> adding the statement that these are too difficult to parse.
If you are referin
On Dec 1, 2012, at 0:45, Wouter Verhelst wrote:
> On Fri, Nov 30, 2012 at 09:14:20AM +0100, Tollef Fog Heen wrote:
>> Are you equating the FSF and the PSF with a private, for-profit company
>> here? That seems to be stretching it a bit.
>
> Not really, IMO.
>
> Personally, I'm not comfortable
On 01.12.2012 06:18, Michael Biebl wrote:
> For b/ there is already a bug report for initramfs-tools [1]. It's
> probably too late to get that into wheezy. But we should follow up there
> to get that into wheezy.
^
jessie, of course.
--
Why is it that all o
Le samedi 01 décembre 2012 à 09:52 +0100, Wouter Verhelst a écrit :
> On Thu, Nov 29, 2012 at 03:58:05PM +0100, Josselin Mouette wrote:
> > Le jeudi 29 novembre 2012 à 15:24 +0100, Wouter Verhelst a écrit :
> > > Now if someone wants to fork the particular bits of upstream software so
> > > makin
On Thu, Nov 29, 2012 at 08:51:47PM +0100, John Paul Adrian Glaubitz wrote:
> On Thu, Nov 29, 2012 at 03:28:40PM +0100, Wouter Verhelst wrote:
> > http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF
> >
> > the most recent processor you can find there was released in January
> > 2012
On Thu, Nov 29, 2012 at 03:58:05PM +0100, Josselin Mouette wrote:
> Le jeudi 29 novembre 2012 à 15:24 +0100, Wouter Verhelst a écrit :
> > Now if someone wants to fork the particular bits of upstream software so
> > making use of a separate /usr is still possible, even if you think it's
> > totall
On Fri, Nov 30, 2012 at 09:14:20AM +0100, Tollef Fog Heen wrote:
> Are you equating the FSF and the PSF with a private, for-profit company
> here? That seems to be stretching it a bit.
Not really, IMO.
Personally, I'm not comfortable signing off my copyright to the FSF, for
the very same reason
On 30.11.2012 03:39, Steve Langasek wrote:
> that's fine; I've been convinced myself that it's not reasonable to have a
> system with /usr on a separate partition and expect that to work without an
> initramfs, and think we *should* simplify our overall architecture rather
> than continuing to put
On Wed, Nov 28, 2012 at 05:04:25PM +0100, Tollef Fog Heen wrote:
> ]] Bjørn Mork
> > "The default 'configure' install locations have changed. Packages for
> >systems with the historic / vs. /usr split need to be adapted,
> >otherwise udev wi
> I do not agree that reconfiguring your machine to avoid an initrd is a
> normal standard desktop configuration. There's also several other things
> about your setup which I would argue are not standard (see below)
Well no but are you trying to argue that my problems are due to my kernel
configu
On Fri, Nov 30, 2012 at 07:23:12PM +0100, Bernhard R. Link wrote:
> * Jon Dowland [121130 16:06]:
> > I do not agree that reconfiguring your machine to avoid an initrd is a
> > normal
> > standard desktop configuration. There's also several other things about your
> > setup which I would argue ar
On Fri, Nov 30, 2012 at 07:23:12PM +0100, Bernhard R. Link wrote:
> * Jon Dowland [121130 16:06]:
> > I do not agree that reconfiguring your machine to avoid an initrd is a
> > normal
> > standard desktop configuration. There's also several other things about your
> > setup which I would argue ar
* Jon Dowland [121130 16:06]:
> I do not agree that reconfiguring your machine to avoid an initrd is a normal
> standard desktop configuration. There's also several other things about your
> setup which I would argue are not standard (see below)
Will Debian come by default with initrds on all rel
On Thu, Nov 29, 2012 at 06:12:14PM +0100, John Paul Adrian Glaubitz wrote:
> Hi Harald,
Hi Adrian
>
> On Thu, Nov 29, 2012 at 04:58:35PM +0100, Harald Jenny wrote:
> > I have tried systemd but as it does not support the Debian extensions to
> > cryptsetup (namely the crypttab keyscript parameter
On Nov 30, 2012, at 09:14 AM, Tollef Fog Heen wrote:
>There's a significant difference whether your contractual counterpart is
>somebody who has the public good or profits in the pockets of its owners
>in mind.
In the abstract, the non-profit or for-profit status of an organization is
little indi
On Fri, Nov 30, 2012 at 12:19:22PM +0100, Salvo Tomaselli wrote:
> I am using systemd on my laptop, i have a very default system configuration,
> (except that i compile my own kernel to avoid initrd)…
^^
> …if I, with a normal, standard desktop co
> I can't say anything about the fetchmail problem, but I just tried to
> reproduce the problem you explained in #693522 and it works on my
> installation.
>
> So we will probably need more input to debug this.
Please post on the bug what kind of test you want me to do.
I was just pointing out h
On Fri, Nov 30, 2012 at 12:19:22PM +0100, Salvo Tomaselli wrote:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693522
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694048
I can't say anything about the fetchmail problem, but I just tried to
reproduce the problem you explained in #693522
> Again, I am constantly asking here what these reasons might be and yet
> people always come with strawman arguments.
You should bother to read the answers to your question then :-)
I am using systemd on my laptop, i have a very default system configuration,
(except that i compile my own kern
]] Barry Warsaw
> On Nov 29, 2012, at 03:40 PM, John Paul Adrian Glaubitz wrote:
>
> >Plus, you have to sign a contributor's agreement with Canonical which leaves
> >a bad taste in my mouth. That shouldn't be the case with true free software,
> >should it?
>
> In an ideal world maybe it shouldn
On Thu, Nov 29, 2012 at 11:51:12PM +, Roger Leigh wrote:
> On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
> > On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote:
> > > > Well, systemd and udev are developed by the same developers.
On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
> On Thu, Nov 29, 2012 at 03:21:02PM +0100, Wouter Verhelst wrote:
> > > Well, systemd and udev are developed by the same developers. Both
> > > daemons interact very closely and integration o
On Fri, Nov 30, 2012 at 03:40:47AM +0800, Thomas Goirand wrote:
> We can ignore what happens to other downstreams of udev,
> however I don't think that's a good idea to do so.
Why bother other downstreams if they don't complain? I find it rather
intrusive to post on the lists
On Thu, Nov 29, 2012 at 03:28:40PM +0100, Wouter Verhelst wrote:
> http://www.freescale.com/webapp/sps/site/homepage.jsp?code=PC68KCF
>
> the most recent processor you can find there was released in January
> 2012.
Yeah, someone else posted this information already.
How much are these instructio
too user, as far as I understand (I'm not a
>> Gentoo user), do not use kernel modules at all.
> In that situation, you'd be posting to gentoo-dev.
We can ignore what happens to other downstreams of udev,
however I don't think that's a good idea to do so.
What ma
On Nov 29, 2012, at 03:40 PM, John Paul Adrian Glaubitz wrote:
>Plus, you have to sign a contributor's agreement with Canonical which leaves
>a bad taste in my mouth. That shouldn't be the case with true free software,
>should it?
In an ideal world maybe it shouldn't, but in truth it is for both
2012/11/29 Wouter Verhelst :
> glibc and the kernel is developed by the same group of companies. Both
> interact very closely and integration of the sources was the natural
> consequence.
Please, *DON"T* :-)
I've tired of this crap on illumos
--
To UNSUBSCRIBE, email to debian-devel-requ...@l
On Fri, Nov 30, 2012 at 12:55:13AM +0800, Thomas Goirand wrote:
> However, you are running Gentoo and rebuild your kernel, why would
> you bother with such thing as kernel modules and initrd? The thing is,
> many (most? all?) Gentoo user, as far as I understand (I'm not a
> Gentoo user), do not use
Hi Harald,
On Thu, Nov 29, 2012 at 04:58:35PM +0100, Harald Jenny wrote:
> I have tried systemd but as it does not support the Debian extensions to
> cryptsetup (namely the crypttab keyscript parameter) it is not a
> valuable alternative for me - sysvinit and upstart btw do support them,
> I did n
On 11/29/2012 10:58 PM, Josselin Mouette wrote:
> There are valid arguments for forking udev, but /usr support is not one
> of them; we will just move /usr mounting to the initrd if it cannot be
> mounted later.
On the Debian side of things, you are probably right, since using an
initrd
Dear Adrian
On Thu, Nov 29, 2012 at 03:40:41PM +0100, John Paul Adrian Glaubitz wrote:
>
> Again, I am constantly asking here what these reasons might be and yet
> people always come with strawman arguments. I mean, seriously we had
> the discussion that systemd is a bad design because it uses th
higher of you than someone who’d bring again the /usr
argument which has already been debunked to death.
There are valid arguments for forking udev, but /usr support is not one
of them; we will just move /usr mounting to the initrd if it cannot be
mounted later.
--
.''
1 - 100 of 792 matches
Mail list logo
