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
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 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
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
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 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,
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
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 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
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
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
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
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
[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 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
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 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
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
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
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
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
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
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
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-
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
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 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
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
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
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
-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: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
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.
35 matches
Mail list logo
