You are seeing this message in Text format. if your email is in the junk
folder, add the sender email to your address book and move this email into your
inbox to view the HTML version.
Marc Espie wrote:
> Briefly, the only info that changes is
> - p* numbers (e.g., PKGNAME = somethingpN)
> - WANTLIB for the affected package.
>
> As much as I don't like adding, as naddy would put it, "more magic", I think
> the p* numbers could live in a separate file, along with most WANTLIB.
On Thu, Jul 08, 2010 at 11:52:44AM -0500, Todd T. Fries wrote:
> The one with the higher numbered libs of course! (Though with manual
> building of things and people who dont update base/xbase often, this
> might produce mixed lists of updated libs, a situation where I don't
> know how automation
Penned by Marc Espie on 20100708 14:49.04, we have:
| On Thu, Jul 08, 2010 at 02:03:41PM +0200, Matthieu Herrb wrote:
| > On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
| > > each time xenocara farts, we get new libs (or less libs).
| > > in order for updates to w
On Thu, 8 Jul 2010, Marc Espie wrote:
On Thu, Jul 08, 2010 at 02:03:41PM +0200, Matthieu Herrb wrote:
On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
each time xenocara farts, we get new libs (or less libs).
in order for updates to work, we *should* propagate those changes to
@wantl
On Thu, 8 Jul 2010, Marc Espie wrote:
On Thu, Jul 08, 2010 at 04:28:27PM +0100, Sam Smith wrote:
The CVS revision number is guaranteed atomically increasing
and only relevant if it's used as a tie breaker against two
otherwise similar versions.
there's probably an obvious reason why this is a
Es Simple, Es Claro.
Descubra la mejor y mas econsmica manera de comunicarse.
Comunicacisn entre los equipos de su flota gratuita e ilimitada en todo
el pams. Equipos totalmente bonificados.
On Thu, Jul 08, 2010 at 04:28:27PM +0100, Sam Smith wrote:
> The CVS revision number is guaranteed atomically increasing
> and only relevant if it's used as a tie breaker against two
> otherwise similar versions.
> there's probably an obvious reason why this is a bad idea.
Stable branches...
On Thu, Jul 08, 2010 at 02:03:41PM +0200, Matthieu Herrb wrote:
> On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
> > each time xenocara farts, we get new libs (or less libs).
> > in order for updates to work, we *should* propagate those changes to
> > @wantlib in each port.
>
> For th
On Thursday 08 July 2010 02:03:41 pm Matthieu Herrb wrote:
> On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
> > each time xenocara farts, we get new libs (or less libs).
> > in order for updates to work, we *should* propagate those changes to
> > @wantlib in each port.
>
> For the base
On Thu, Jul 08, 2010 at 11:50:39AM +0200, Marc Espie wrote:
> each time xenocara farts, we get new libs (or less libs).
> in order for updates to work, we *should* propagate those changes to
> @wantlib in each port.
For the base and xenocara libs, wouldn't it make sense to have some
modules centr
On Thu, Jul 08, 2010 at 12:03:47PM +0100, Stuart Henderson wrote:
> On 2010/07/08 11:50, Marc Espie wrote:
> > each time xenocara farts, we get new libs (or less libs).
> > in order for updates to work, we *should* propagate those changes to
> > @wantlib in each port.
> >
> > This currently isn't
On 2010/07/08 11:50, Marc Espie wrote:
> each time xenocara farts, we get new libs (or less libs).
> in order for updates to work, we *should* propagate those changes to
> @wantlib in each port.
>
> This currently isn't done automatically... check-lib-depends is sloooww
> (needs to check every fil
Hi t...@!
acpiac(4) and acpibat(4) on my ASUS UL30A laptop are not working
correctly. On load, both devices return 'not present'. However, when the
embedded controller fires a GPE event on ac/battery insertion/removal,
they suddenly appear and apm(8) reports their status correctly.
Under Linux/Fr
each time xenocara farts, we get new libs (or less libs).
in order for updates to work, we *should* propagate those changes to
@wantlib in each port.
This currently isn't done automatically... check-lib-depends is sloooww
(needs to check every file before packaging) and not even flawless.
I'm beg
On Mon, Jun 28, 2010 at 08:00:34PM +0200, Christopher Zimmermann wrote:
>
> it just took me 2 hours to figure out that OpenBSD does not yet
> support the WPA enterprise mode (aka 802.1X). Is this actually
> true? If yes, please include the patch below to make this clear
> in the man page.
>
yes,
16 matches
Mail list logo
