[gentoo-dev] pcmcia-cs 3.2.4 ebuild?

[gentoo-dev] pcmcia-cs 3.2.4 ebuild?

[Dhruba Bandopadhyay]

Hello

How do I go about requesting an ebuild for pcmcia-cs 3.2.4 as released on
https://sourceforge.net/projects/pcmcia-cs/?  Is bugs.gentoo.org for
ebuild requests also or should I get in touch with the author of previous
ebuilds?  If the latter, then kindly mention who the best person to
contact would be?

I'm assuming it isn't as simple as changing the version in the filename of
the ebuild to make it download the newest version.

Many thanks
Dhruba Bandopadhyay



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pcmcia-cs 3.2.4 ebuild?

[Joseph Carter]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Tue, Mar 04, 2003 at 08:56:51PM -0000, Dhruba Bandopadhyay wrote:
> How do I go about requesting an ebuild for pcmcia-cs 3.2.4 as released on
> https://sourceforge.net/projects/pcmcia-cs/?  Is bugs.gentoo.org for
> ebuild requests also or should I get in touch with the author of previous
> ebuilds?  If the latter, then kindly mention who the best person to
> contact would be?
> 
> I'm assuming it isn't as simple as changing the version in the filename of
> the ebuild to make it download the newest version.

Would this be a good time to do the pcmcia-cs-drivers and pcmcia-cs-tools
split?

-- 
Joseph Carter <knghtbrd@efn.org>                  Not ready for prime-time
 
<barneyfu> knghtbrd: crap, SDL sure makes DGA a helluva alot easier too
           doesn't it? :)
<knghtbrd> barneyfu: what DGA?
<barneyfu> mouse dga
<knghtbrd> barneyfu: (does that answer your question?)
<barneyfu> Hahahahaha YEAH! :)


[-- Attachment #2: Type: application/pgp-signature, Size: 253 bytes --]

Re: [gentoo-dev] pcmcia-cs 3.2.4 ebuild?

[Mark Gordon]

On Tue, 4 Mar 2003 15:40:19 -0800
Joseph Carter <knghtbrd@efn.org> wrote:

> On Tue, Mar 04, 2003 at 08:56:51PM -0000, Dhruba Bandopadhyay wrote:
> > How do I go about requesting an ebuild for pcmcia-cs 3.2.4 as
> > released on https://sourceforge.net/projects/pcmcia-cs/?  Is
> > bugs.gentoo.org for ebuild requests also or should I get in touch
> > with the author of previous ebuilds?  If the latter, then kindly
> > mention who the best person to contact would be?
> > 
> > I'm assuming it isn't as simple as changing the version in the
> > filename of the ebuild to make it download the newest version.
> 
> Would this be a good time to do the pcmcia-cs-drivers and
> pcmcia-cs-tools split?

Sounds like it to me. The split works for my combination.
-- 
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Currently looking for a new job commutable from Slough, Berks, U.K.
Although my email address says spamtrap, it is real and I read it.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pcmcia-cs 3.2.4 ebuild?

[Joseph Carter]

[-- Attachment #1: Type: text/plain, Size: 4591 bytes --]

On Wed, Mar 05, 2003 at 08:32:25AM +0000, Mark Gordon wrote:
> > > I'm assuming it isn't as simple as changing the version in the
> > > filename of the ebuild to make it download the newest version.
> > 
> > Would this be a good time to do the pcmcia-cs-drivers and
> > pcmcia-cs-tools split?
> 
> Sounds like it to me. The split works for my combination.

So far as I know, the purpose of pcmcia-cs-drivers is to allow you to use
the kernel pcmcia driver and the modules from pcmcia-cs, a combination
which is not exactly guaranteed to work, but which can be more stable for
certain people.

I see another advantage, especially as the pcmcia-cs modules are made to
work correctly under 2.5 kernels with proper sysfs hotplug interface: the
deprecation of the card services tools (cardmgr, cardctl, etc..)  This
will mean that removable devices will finally have a single interface, if
one which is perhaps still a bit immature.

I'm looking at details of improving hotplug to add some of the features
found in cardmgr and usbmgr, as well as features which are found in
neither, but would be nice to have.  I've talked with Peter Johanson about
some of this stuff mostly on irc.  My primary interests with hacking the
hotplug stuff in Gentoo are:

 - User notification (something that can inform non-root processes what
   hotplug is doing, or at the least communicate success and failure at
   various stages through beeps and the like the way cardmgr and usbmgr do
   currently..)

 - Hotplug device schemes, similar to PCMCIA schemes, but more powerful.
   To explain: I have onboard ethernet and PCMCIA wireless.  Both are
   modules since having neither loaded conserves power.  Can't be sure
   which will be eth0 and which will be eth1.  And simple DHCP works for
   both interfaces, except for EFN's machine room which needs a static
   config and a couple of APs which need WEP keys.  Plus there are two
   locations in which connecting to the network should start up VPN stuff!

   This is beyond PCMCIA schemes, but not beyond hotplug, if someone goes
   to the effort of writing the glue interface.  This is trivial, though,
   the real problem is interfacing the result with Gentoo's setup without
   frustrating the hell out of everyone with yet another special case!

 - Device removal, whether for actually unplugging the device, in the case
   of a notebook, just stop trying to use it to conserve battery power!  I
   have found that the Linux kernel is horrible about letting you remove
   an unused device, even if the device is removable as is the case with
   USB and PCMCIA.  cardctl eject <slot#> issued before removing the card
   does, without fail, cause this problem to go away with PCMCIA.  This
   needs to become a generic thing, possibly part of the sysfs interface
   to hotplug devices in 2.5.

 - Uniform device identification, which ties into the above two areas of
   interest..  My USB pendisk is the example this time - once inserted, I
   can know that the usb-storage module was loaded, but there is no way to
   know what disc devices were created by it, especially since they show
   up in /dev/scsi rather than /dev/usb..  And because USB devices cannot
   be stopped the way PCMCIA devices can be, the driver does not always
   give back the SCSI device name it registered, making fstab entries
   rather pointless.

   Many devices can be identified in some unique manner.  My goal is then
   to make this unique identifier usable for all of the above purposes.


It's a rather ambitious and long-term project, and only parts of it are
Gentoo-specific, however there is some advantage to doing this kind of
thing on a Gentoo system where things like hotplug and devfsd are pretty
much standard components.  The schemes developed for hotplug, for example,
can easily be used with ANY device on a Gentoo system by virtue of devfs.

If others are interested or have been working on similar things, it would
be good to share the work, especially given that with work and school I am
generally pretty busy these days.  Working on my own, it may well be a few
months before I have anything to show for my efforts.

-- 
Joseph Carter <knghtbrd@efn.org>                 I swallowed your goldfish
 
"If the designers of X-Windows built cars, there would be no fewer than
five steering wheels hidden about the cockpit, none of which followed the
same principles -- but you'd be able to shift gears with your car stereo.
Useful feature, that."
        -- Marus J. Ranum


[-- Attachment #2: Type: application/pgp-signature, Size: 253 bytes --]