On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
> And it is also very unclear to me why this has to be in /lib/udev at
> all.
Because it provides a single point where the desktop hooks into the kernel
hotplug event system, instead of having hal redo all the work already done
by udev.
On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> proposal below to migrate it to dpkg triggers [0]
> The Current Messy State of Affairs
> update-inetd script is problematic (maintainer scripts use i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
package: wnpp
X-Debbugs-CC: debian-devel@lists.debian.org
Pandora build is a collection of m4 macros used by libdrizzle,
libmemcached, drizzle and gearmand : developers working on these
projects need the macros installed.
- -Rob
-BEGIN PGP SIGNA
On Fri, Sep 04, 2009 at 09:12:03PM +0200, Marco d'Itri wrote:
> > But I guess Red Hat and Suse decide. Debian does what they do, nobody
> They are currently providing most of the manpower for developing udev
> and the related infrastructure so this is pretty much the practical
> effect, yes.
So w
Package: wnpp
Severity: wishlist
Owner: "Yves-Alexis Perez"
* Package name: xfce4-volumed
Version : 0.1.4
Upstream Author : Steve Dodier
* URL : https://code.launchpad.net/xfce4-volumed
* License : GPLv3
Programming Lang: C
Description : volume keys d
Hello world,
As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
proposal below to migrate it to dpkg triggers [0]
The Current Messy State of Affairs
update-inetd script is problematic (maintainer scripts use it to update the
/etc/inetd.conf conffile leading to local-poli
On Fri, Sep 04, 2009 at 06:58:18PM +0200, Marco d'Itri wrote:
> On Sep 04, Bastian Blank wrote:
>
> > Why do you not extend the current setup to do another step? Currently we
> Even if this were possible at all, it would require (for a start):
> - working out all the possible side effects of synt
m...@linux.it (Marco d'Itri) writes:
> On your part, you could try to understand them instead of attributing to
> me straw man positions.
That's a good advice. Thanks. Please help me understand: What is the
usb-db and/or pci-db use case?
I'm afraid my creative imagination is far too limited to
On Sep 04, Bjørn Mork wrote:
> The issue is most certainly raised by other distributions. See e.g. the
> thread starting with http://article.gmane.org/gmane.linux.gentoo.devel/62973
This is about the micromanagement of dependencies which greatly excites
Gentoo users, so is not very relevant (and
Hendrik Sattler writes:
> Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl:
>> devkit-disks-part-id and devkit-disks-probe-ata-smart both link against
>> libraries which are (currently) in /usr/lib, i.e.
>> devkit-disks-part-id links against libglib-2.0 (784K)
>> devkit-disks-probe-ata-
Carl Worth writes:
> That is, surely there must be a way for you to keep the debian
> directory in the single repository along with the implementation and
> still build a non-native package from it. That would seem to me the
> ideal way to go.
http://www.eyrie.org/~eagle/notes/debian/git.html
a
Excerpts from Jens Peter Secher's message of Fri Sep 04 11:12:47 -0700 2009:
> FWIW, I wrote this answer (but did not send it):
Funny, because I received it. :-)
> There is no point pretending there is an upstream when there clearly
> isn't. Pretending there is an upstream just forces me put eve
Bjørn Mork wrote:
Personally I really can't see why these addons (usb-db,pci-db) are so
important. Nobody has demonstrated a usecase for them. Yet you make it
sound like there is no choice at all, but to include them in udev.
Seconded. The Debian 5 system I just built (2.6.29 kernel from
b
2009/9/4 Gunnar Wolf :
> Wouter Verhelst dijo [Thu, Sep 03, 2009 at 12:47:44PM +0200]:
>> > > * Upstream has abandoned the program, so the package is now Debian
>> > > native.
>> >
>> > Switching upstreams does not make a package native.
>>
>> How so? There is no reason why a package where th
Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl:
> devkit-disks-part-id and devkit-disks-probe-ata-smart both link against
> libraries which are (currently) in /usr/lib, i.e.
> devkit-disks-part-id links against libglib-2.0 (784K)
> devkit-disks-probe-ata-smart links against (48K)
>
>
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Ron Johnson wrote:
>
>> Whatever the cause, it breaks the FHS.
> Since it keeps being repeated, it is time to destroy this argument.
> FHS documents what distributions want to do: of the other relevant
> distributions, representatives from Red Hat
On Sep 04, Bastian Blank wrote:
> Why do you not extend the current setup to do another step? Currently we
Even if this were possible at all, it would require (for a start):
- working out all the possible side effects of synthesizing all/most
(which ones?) events a second time
- having to forwa
On Sep 04, Ron Johnson wrote:
> Whatever the cause, it breaks the FHS.
Since it keeps being repeated, it is time to destroy this argument.
FHS documents what distributions want to do: of the other relevant
distributions, representatives from Red Hat and Suse said they do not
support this and exce
Gabor Gombas wrote:
>
> IMHO this looks more and more like the udev rules has to be split into
> at least two categories:
>
> - a basic set that is used during boot and early system setup. Services
> in rcS.d are allowed to rely on these rules only, and these rules must
> not rely on anything
On Fri, Sep 04, 2009 at 04:36:52PM +0200, Michael Biebl wrote:
> I'd like to add here, that devicekit-disks will install udev helpers
> /lib/udev/devkit-disks-* which are called in
> /lib/udev/rules.d/95-devkit-disks.rules.
>
> devkit-disks-part-id and devkit-disks-probe-ata-smart both link again
[Bastian Blank]
> Why do you not extend the current setup to do another step?
> Currently we have two
> - in the initramfs with only minimal information and
> - during the rcS run with / available.
Eh, currently we have 5 sections during the boot:
- initramfs with minimal set of files available.
Package: devicekit-disks
Severity: serious
On Fri, Sep 04, 2009 at 04:36:52PM +0200, Michael Biebl wrote:
> I'd like to add here, that devicekit-disks will install udev helpers
> /lib/udev/devkit-disks-* which are called in
> /lib/udev/rules.d/95-devkit-disks.rules.
>
> devkit-disks-part-id and d
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote:
> FYI, udev 146 ships usb-id and pci-id programs which read
> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
> udev itself does not care about the results of these programs but other
> programs which used to use HAL may do, leadin
Marco d'Itri wrote:
> On Sep 04, Steve Langasek wrote:
>
>> I still can't fathom why someone decided that udev should be responsible for
>> translating PCI IDs and USB IDs into text strings. This smells of crazy.
> I think that part of the rationale is that eventually HAL will go away
> replaced
Manoj Srivastava wrote:
> On Thu, Sep 03 2009, Franck Joncourt wrote:
>> At a first glance there is no need to split it, and all of the binary
>> packages could be created from one source package as you mentionned.
>> However, for other distributions than Debian I do not know how their
>> packagin
Package: wnpp
Severity: wishlist
Owner: Didier Raboud
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package name: pyside-tools
Version : 0.1
Upstream Author : Nokia Corporation and subsidiaries
Trolltech
Torsten Marek
On 2009-09-04 07:46, Marco d'Itri wrote:
On Sep 04, Gabor Gombas wrote:
Incompetent, no. Careless, yes. Just think about the udev-related
breakages in the past. And speaking about design, udev was originally
praised because it can do everything in user space. Now, the authors of
udev are propo
Wouter Verhelst dijo [Fri, Sep 04, 2009 at 09:01:47AM +0200]:
> On Thu, Sep 03, 2009 at 06:29:31PM -0500, Gunnar Wolf wrote:
> > Why should it be Debian-native?
>
> I never said it *should* be. I said it *could* be, and that whether or
> not it is should be the maintainer's prerogative.
Bad choic
On Sep 04, Gabor Gombas wrote:
> Incompetent, no. Careless, yes. Just think about the udev-related
> breakages in the past. And speaking about design, udev was originally
> praised because it can do everything in user space. Now, the authors of
> udev are proposing devtmpfs, because as it turned
On Fri, Sep 04, 2009 at 11:41:41AM +0200, Marco d'Itri wrote:
> So you believe that the upstream maintainers are incompetent and
> released something which is unreliable by design?
Incompetent, no. Careless, yes. Just think about the udev-related
breakages in the past. And speaking about design,
m...@linux.it (Marco d'Itri) writes:
> On Sep 04, Bjørn Mork wrote:
>
>> Yes. Any device specific matching should use vid:pid. How about just
>> disabling the /lib/udev/{pci,usb}-db helpers alltogether to avoid ever
>> getting any users of this info in Debian? It will always be too
>> unreliabl
On Fri, Sep 4, 2009 at 11:41:41 +0200, Marco d'Itri wrote:
> On Sep 04, Steve Langasek wrote:
>
> > I still can't fathom why someone decided that udev should be responsible for
> > translating PCI IDs and USB IDs into text strings. This smells of crazy.
> I think that part of the rationale is
On Sep 04, Steve Langasek wrote:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
I think that part of the rationale is that eventually HAL will go away
replaced by udev and programs like thi
Steve Langasek writes:
> I still can't fathom why someone decided that udev should be responsible for
> translating PCI IDs and USB IDs into text strings. This smells of crazy.
Yes. Any device specific matching should use vid:pid. How about just
disabling the /lib/udev/{pci,usb}-db helpers al
On Thu, Sep 03, 2009 at 06:29:31PM -0500, Gunnar Wolf wrote:
> Why should it be Debian-native?
I never said it *should* be. I said it *could* be, and that whether or
not it is should be the maintainer's prerogative.
--
The biometric identification system at the gates of the CIA headquarters
work
35 matches
Mail list logo
