FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-24-2012, 12:42 AM
Zac Medico
 
Default About forcing rebuilds of other packages issue

On 06/10/2012 11:18 AM, Zac Medico wrote:
> On 06/10/2012 05:25 AM, Ciaran McCreesh wrote:
>> On Sat, 09 Jun 2012 13:55:53 -0700
>> Zac Medico <zmedico@gentoo.org> wrote:
>>> A dependency atom will have optional SLOT and ABI_SLOT parts. Using
>>> the dbus-glib depedency on glib:2 as an example [1], the dbus-glib
>>> dependency will be expressed with an atom such as dev-libs/glib:2:=
>>> and the package manager will translate that atom to
>>> dev-libs/glib:2:=2.32 at build time. So, ':' is always used to
>>> distinguish SLOT deps, and ':=' is always used to distinguish
>>> ABI_SLOT deps. Is that syntax good?
>>
>> Here's a nicer syntax: no ABI_SLOT variable, and SLOT="2/2.32". Then you
>> can do explicit :2/2.32 dependencies if you like, or :2 (which would
>> match SLOT="2" or SLOT="2/anything"), or :2= (which gets rewritten
>> to :2/2.32=) or :2*. If an ebuild does SLOT="2", it's treated as 2/2.
>
> Yes, I prefer your syntax.

In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI
“4-slot-abi”:


http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
--
Thanks,
Zac
 
Old 06-25-2012, 01:03 PM
Ian Stakenvicius
 
Default About forcing rebuilds of other packages issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/06/12 08:42 PM, Zac Medico wrote:
> On 06/10/2012 11:18 AM, Zac Medico wrote:
>> On 06/10/2012 05:25 AM, Ciaran McCreesh wrote:
>>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico
>>> <zmedico@gentoo.org> wrote:
>>>> A dependency atom will have optional SLOT and ABI_SLOT parts.
>>>> Using the dbus-glib depedency on glib:2 as an example [1],
>>>> the dbus-glib dependency will be expressed with an atom such
>>>> as dev-libs/glib:2:= and the package manager will translate
>>>> that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is
>>>> always used to distinguish SLOT deps, and ':=' is always used
>>>> to distinguish ABI_SLOT deps. Is that syntax good?
>>>
>>> Here's a nicer syntax: no ABI_SLOT variable, and SLOT="2/2.32".
>>> Then you can do explicit :2/2.32 dependencies if you like, or
>>> :2 (which would match SLOT="2" or SLOT="2/anything"), or :2=
>>> (which gets rewritten to :2/2.32=) or :2*. If an ebuild does
>>> SLOT="2", it's treated as 2/2.
>>
>> Yes, I prefer your syntax.
>
> In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI
> “4-slot-abi”:
>
>
> http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/


Does
>
anyone have a fork of the tree that's being converted to test
this new functionality? If so I'd like to sign up.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/oYYcACgkQ2ugaI38ACPBZ3QEAkXXOmiTdC/7Hgl84c2oSlwbM
5YNUbcgh6wI59FTCAboA/RGdo1YptVCvmHYlyvJ2VKNY98pq2g+FKhY1T7SAbrlo
=hXfd
-----END PGP SIGNATURE-----
 
Old 06-25-2012, 05:58 PM
Zac Medico
 
Default About forcing rebuilds of other packages issue

On 06/25/2012 06:03 AM, Ian Stakenvicius wrote:
> On 23/06/12 08:42 PM, Zac Medico wrote:
>> On 06/10/2012 11:18 AM, Zac Medico wrote:
>>> On 06/10/2012 05:25 AM, Ciaran McCreesh wrote:
>>>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico
>>>> <zmedico@gentoo.org> wrote:
>>>>> A dependency atom will have optional SLOT and ABI_SLOT parts.
>>>>> Using the dbus-glib depedency on glib:2 as an example [1],
>>>>> the dbus-glib dependency will be expressed with an atom such
>>>>> as dev-libs/glib:2:= and the package manager will translate
>>>>> that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is
>>>>> always used to distinguish SLOT deps, and ':=' is always used
>>>>> to distinguish ABI_SLOT deps. Is that syntax good?
>>>>
>>>> Here's a nicer syntax: no ABI_SLOT variable, and SLOT="2/2.32".
>>>> Then you can do explicit :2/2.32 dependencies if you like, or
>>>> :2 (which would match SLOT="2" or SLOT="2/anything"), or :2=
>>>> (which gets rewritten to :2/2.32=) or :2*. If an ebuild does
>>>> SLOT="2", it's treated as 2/2.
>>>
>>> Yes, I prefer your syntax.
>
>> In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI
>> “4-slot-abi”:
>
>
>> http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
>
>
> Does
>
> anyone have a fork of the tree that's being converted to test
> this new functionality? If so I'd like to sign up.

That would be nice to have, but I haven't heard of anyone doing it yet.
--
Thanks,
Zac
 
Old 06-27-2012, 07:38 PM
Ian Stakenvicius
 
Default About forcing rebuilds of other packages issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/06/12 01:58 PM, Zac Medico wrote:
> On 06/25/2012 06:03 AM, Ian Stakenvicius wrote:
>> On 23/06/12 08:42 PM, Zac Medico wrote:
>>> On 06/10/2012 11:18 AM, Zac Medico wrote:
>>>> On 06/10/2012 05:25 AM, Ciaran McCreesh wrote:
>>>>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico
>>>>> <zmedico@gentoo.org> wrote:
>>>>>> A dependency atom will have optional SLOT and ABI_SLOT
>>>>>> parts. Using the dbus-glib depedency on glib:2 as an
>>>>>> example [1], the dbus-glib dependency will be expressed
>>>>>> with an atom such as dev-libs/glib:2:= and the package
>>>>>> manager will translate that atom to dev-libs/glib:2:=2.32
>>>>>> at build time. So, ':' is always used to distinguish SLOT
>>>>>> deps, and ':=' is always used to distinguish ABI_SLOT
>>>>>> deps. Is that syntax good?
>>>>>
>>>>> Here's a nicer syntax: no ABI_SLOT variable, and
>>>>> SLOT="2/2.32". Then you can do explicit :2/2.32
>>>>> dependencies if you like, or :2 (which would match SLOT="2"
>>>>> or SLOT="2/anything"), or :2= (which gets rewritten to
>>>>> :2/2.32=) or :2*. If an ebuild does SLOT="2", it's treated
>>>>> as 2/2.
>>>>
>>>> Yes, I prefer your syntax.
>>
>>> In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for
>>> EAPI “4-slot-abi”:
>>
>>
>>> http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
>>
>>
>>
>>>
Does
>>
>> anyone have a fork of the tree that's being converted to test
>> this new functionality? If so I'd like to sign up.
>
> That would be nice to have, but I haven't heard of anyone doing it
> yet.


Well, I am now. If anyone wants to test, i'm going to make an attempt
to keep the following overlay in sync with the main tree within a
24-hour delay (excluding weekends).

git://git.overlays.gentoo.org/dev/axs.git

FYI, all the work subslotting the perl stuff doesn't work yet, so it's
probably best to wait a few days before trying it out.

Sorry, no means of bug reporting on any of this yet (ie, don't file on
b.g.o about it), but i'm in #-dev on freenode most weekdays.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/rYTgACgkQ2ugaI38ACPAOvwD/WBqDNCnCJLZw+2302SJOZzO4
cDYOcr3nNk5JeMVz1YAA/jrllZuqcl2skF0WBf4ku8Jb8dsTucddqB3SarxSBB25
=Efzw
-----END PGP SIGNATURE-----
 
Old 07-07-2012, 11:29 AM
Peter Stuge
 
Default About forcing rebuilds of other packages issue

Zac Medico wrote:
> >>>>> I'd suggest a special ebuild phase to check for ABI changes, like
> >>>>> the pre_pkg_preinst_abi_check phase suggested here:
> >>>>>
> >>>>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20
> >>>>
> >>>> I guess, that phase would detect ABI change and package manager
> >>>> would know how to handle it by itself?
> >
> > Yeah, it would be like a warning system,
> >
> > And once we bump SLOT/ABI_SLOT, package manager would know about
> > how to handle that situation and rebuild needed stuff?

Is it unrealistic to assume that upstream ABI providers will mark
their ABIs by using sonames correctly?

Maybe that is at least the common case, then ABI_SLOT could be set
automatically.

Maybe I'm too far ahead, and baby steps are better.


//Peter
 
Old 07-07-2012, 02:10 PM
Ian Stakenvicius
 
Default About forcing rebuilds of other packages issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/07/12 07:29 AM, Peter Stuge wrote:
> Zac Medico wrote:
>>>>>>> I'd suggest a special ebuild phase to check for ABI
>>>>>>> changes, like the pre_pkg_preinst_abi_check phase
>>>>>>> suggested here:
>>>>>>>
>>>>>>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20
>>>>>>
>>>>>> I guess, that phase would detect ABI change and package
>>>>>> manager would know how to handle it by itself?
>>>
>>> Yeah, it would be like a warning system,
>>>
>>> And once we bump SLOT/ABI_SLOT, package manager would know
>>> about how to handle that situation and rebuild needed stuff?
>
> Is it unrealistic to assume that upstream ABI providers will mark
> their ABIs by using sonames correctly?
>
> Maybe that is at least the common case, then ABI_SLOT could be set
> automatically.
>
> Maybe I'm too far ahead, and baby steps are better.
>

Although we have a lot of this information available (which is why/how
@preserved-libs works, for instance), there is no way for portage to
know *prior to emerging the update* if abi has changed. This is why
it needs to be specified in the ebuild somehow (and sub-slots via
4-slot-abi seem very capable of handling this)

That said, while experimenting with 4-slot-abi porting on my overlay,
usually I am just specifying the major (or sometimes major.minor)
version parts of the sonames, since that seems to make the most sense
usually.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/4Q2IACgkQ2ugaI38ACPBzagD/blTq3Dq1K9Yrv2PdxSirxwu7
POUSNlLr59x8jKaE2oYBAIS+mATPRj3vn1W/uB37ipLmbg76gbcr7LTqh6Mb7Unv
=VKuj
-----END PGP SIGNATURE-----
 
Old 07-07-2012, 06:54 PM
Peter Stuge
 
Default About forcing rebuilds of other packages issue

Ian Stakenvicius wrote:
> > Is it unrealistic to assume that upstream ABI providers will mark
> > their ABIs by using sonames correctly?
> >
> > Maybe that is at least the common case, then ABI_SLOT could be set
> > automatically.
>
> Although we have a lot of this information available (which is why/how
> @preserved-libs works, for instance), there is no way for portage to
> know *prior to emerging the update* if abi has changed.

Knowing that a library changes ABI before building is nice, but not
relying on a human to encode this is nicer still.

After compile, before install, there is an opportunity to show the
effects of installing the package.

I'm only talking about the context of the developer who is adding the
new ebuild. So ABI_SLOT (or / SLOT) would be set automatically just
once, in the process of committing the ebuild. No need to repeat the
binary analysis - except if one source package has different ABI for
different ARCHes. Fun!


//Peter
 
Old 07-07-2012, 08:18 PM
Zac Medico
 
Default About forcing rebuilds of other packages issue

On 07/07/2012 11:54 AM, Peter Stuge wrote:
> Ian Stakenvicius wrote:
>>> Is it unrealistic to assume that upstream ABI providers will mark
>>> their ABIs by using sonames correctly?
>>>
>>> Maybe that is at least the common case, then ABI_SLOT could be set
>>> automatically.
>>
>> Although we have a lot of this information available (which is why/how
>> @preserved-libs works, for instance), there is no way for portage to
>> know *prior to emerging the update* if abi has changed.
>
> Knowing that a library changes ABI before building is nice, but not
> relying on a human to encode this is nicer still.
>
> After compile, before install, there is an opportunity to show the
> effects of installing the package.
>
> I'm only talking about the context of the developer who is adding the
> new ebuild. So ABI_SLOT (or / SLOT) would be set automatically just
> once, in the process of committing the ebuild.

Well, if you're talking about having portage automatically edit the
ebuild, I don't think we want to do that. If developers use
portage-2.2_alpha with preserve-libs, then they'll know automatically
when there's an SONAME change that triggers preserve-libs. Part of the
beauty of the approach used in EAPI 4-slot-abi is that that it can be
used to trigger rebuilds in cases that don't even involve SONAME
dependencies (consider a "pure" perl module that only needs to be
rebuilt in order to install its interpreted *.pm files in a different
directory for a new version of perl).

> No need to repeat the
> binary analysis - except if one source package has different ABI for
> different ARCHes. Fun!

It might be nice to add some binary analysis things beyond preserve-libs
in the future. However, EAPI 4-slot-abi should work quite well even
without that. It just automates rebuilds [1] that the user was
previously required to handle manually, when prompted by elog messages,
or by running tools like revdep-rebuild and perl-cleaner. It's being
tested in the axs overlay [2], and it seems to be working pretty well.

[1]
http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
[2] http://git.overlays.gentoo.org/gitweb/?p=dev/axs.git;a=summary
--
Thanks,
Zac
 
Old 09-06-2012, 09:01 AM
Fabian Groffen
 
Default About forcing rebuilds of other packages issue

Replying to this email since it seems to be the discussion behind
the "sub-slot" feature proposed for EAPI 5.

On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote:
> This is why I think we should try to push a bit my first suggestion for
> the short term until "the perfect one" is ready as, until then, we are
> having for years a problem that, personally, I think it should be
> handled a bit better.

After reading this thread, I have seen numerous occasions where has been
asked what this proposal actually solves. Unless I've accidentially
skipped over it, the answer has yet to be given. It appears to me now
sub-slot is a feature that makes it easy to express a situation that
could be expressed today as well, but requiring more work. As such
"syntactic sugar", it seems not well bounded, allowing possibly for
doing things that result in a big mess (I cannot prove this atm, and
there is no specification afaict.)

So, I'm looking for a specification what the components in the sub-slot
exactly mean, and what behaviour they trigger. To me, it seems right
now that sub-slot is simply ${SLOT}/${PV}, and some fancy sub-part
matching (up to the '/' actually). It would be nice to have a sound and
clear definition of that the SLOT value means, and what the sub-slot
value means. How can one make it up? Could one also just start with 1
as sub-slot? Or use names? (SLOT="2/$(use fnord && echo fnord)"). I
have no clue how to use this correctly, as well as what problems I
should have that it solves.

To clarify the last bit, could you please explain how the following
situation benefits from sub-slot.

Consider the packages libfnord, foo and bar. libfnord being a library,
used by foo and bar, which are simple executables. libfnord has 6
versions (not necessarily all at the same time in the tree), with ELF
soname and library versions:

libfnord-1 libfnord.so.3 libfnord.so.3.0
libfnord-2 libfnord.so.5 libfnord.so.5.1
libfnord-2.1 libfnord.so.5 libfnord.so.5.2
libfnord-2.1-r5 libfnord.so.5 libfnord.so.5.2
libfnord-3 libfnord.so.5 libfnord.so.5.8
libfnord-3.5 libfnord.so.5 libfnord.so.5.12

Package foo and bar have the following versions and {,R}DEPEND:

foo-3.0 >=libfnord-2
bar-1.234b =libfnord-1*
bar-2.4 >=libfnord-3

How would the SLOT and {,R}DEPEND values for these ebuilds look like,
what happens when libfnord 2 and 3 are introduced in the tree, etc.
Please show for both EAPI 4, EAPI 4+slot-deps and EAPI 4+sub-slot.
What if libfnord-2.1 or libfnord-3.5 would be masked due to some problem
not noticed prior to stabling that makes it useless for many users.
bar-2.4 during configure checks for a new function in libfnord-3.5 and
uses it if available, or uses an alternative code-path instead.
libfnord-2.1-r5 fixes a crash in some function of the library.
(Note: this whole example/question sounds like an ebuild-quiz question
that any dev should be able to answer then.)

What would be the advantage of sub-slot here, assuming the versioning of
the libraries follows ABI versioning rules defined by e.g. libtool.


Please enlighten me.
Fabian

--
Fabian Groffen
Gentoo on a different level
 
Old 09-06-2012, 01:25 PM
Ian Stakenvicius
 
Default About forcing rebuilds of other packages issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/09/12 05:01 AM, Fabian Groffen wrote:
> Replying to this email since it seems to be the discussion behind
> the "sub-slot" feature proposed for EAPI 5.
>
> On 04-06-2012 23:26:18 +0200, Pacho Ramos wrote:
>> This is why I think we should try to push a bit my first
>> suggestion for the short term until "the perfect one" is ready
>> as, until then, we are having for years a problem that,
>> personally, I think it should be handled a bit better.
>
> After reading this thread, I have seen numerous occasions where has
> been asked what this proposal actually solves. Unless I've
> accidentially skipped over it, the answer has yet to be given. It
> appears to me now sub-slot is a feature that makes it easy to
> express a situation that could be expressed today as well, but
> requiring more work. As such "syntactic sugar", it seems not well
> bounded, allowing possibly for doing things that result in a big
> mess (I cannot prove this atm, and there is no specification
> afaict.)
>

#1 - there is both a specification, and an initial implementation, AND
a fork of the tree that is kept semi-up-to-date on my dev overlay. So
please test away. At present sub-slots have been set on Xorg
(automatically rebuilding x11-drivers/* on upgrades), and on perl
(automatically rebuilding everything (afaik) that perl-cleaner would
normally be needed for). There should be more than enough work done
on my portage fork for you to be able to experiment and prove/disprove
said mess.

#2 - related to your question about what the proposal solves -- in my
opinion, the biggest thing the proposal solves is the case where we
want the ability to use SLOTs in the tree to manage and track
dependency changes (ie, when an API or ABI has changed), but NOT allow
multiple versions of a package to be installed at the same time.
Further to this, it allows PMs to determine what needs to be rebuilt
due to the old (no longer existing) dep being supported prior to said
dep actually being removed.



> So, I'm looking for a specification what the components in the
> sub-slot exactly mean, and what behaviour they trigger. To me, it
> seems right now that sub-slot is simply ${SLOT}/${PV}, and some
> fancy sub-part matching (up to the '/' actually). It would be nice
> to have a sound and clear definition of that the SLOT value means,
> and what the sub-slot value means. How can one make it up? Could
> one also just start with 1 as sub-slot? Or use names?
> (SLOT="2/$(use fnord && echo fnord)"). I have no clue how to use
> this correctly, as well as what problems I should have that it
> solves.

sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}.
It doesn't have to replate to ${PV} at all, and generally shouldn't.
More likely it should relate to the ${major}.${minor} in the main
library's SONAME. For non-libtool dependencies some other form of id
is used, ie for perl I used the major.minor from $PV.



>
> To clarify the last bit, could you please explain how the
> following situation benefits from sub-slot.
>
> Consider the packages libfnord, foo and bar. libfnord being a
> library, used by foo and bar, which are simple executables.
> libfnord has 6 versions (not necessarily all at the same time in
> the tree), with ELF soname and library versions:
>
> libfnord-1 libfnord.so.3 libfnord.so.3.0 libfnord-2
> libfnord.so.5 libfnord.so.5.1 libfnord-2.1 libfnord.so.5
> libfnord.so.5.2 libfnord-2.1-r5 libfnord.so.5
> libfnord.so.5.2 libfnord-3 libfnord.so.5
> libfnord.so.5.8 libfnord-3.5 libfnord.so.5
> libfnord.so.5.12
>
> Package foo and bar have the following versions and {,R}DEPEND:
>
> foo-3.0 >=libfnord-2 bar-1.234b =libfnord-1*
> bar-2.4 >=libfnord-3
>
> How would the SLOT and {,R}DEPEND values for these ebuilds look
> like, what happens when libfnord 2 and 3 are introduced in the
> tree, etc. Please show for both EAPI 4, EAPI 4+slot-deps and EAPI
> 4+sub-slot.

EAPI="4-slot-deps" is new to me; the implementation i've been testing
is EAPI="4-slot-abi" which is sub-slots and slot operators. This is
the spec that was written and proposed for EAPI=5 and so this is what
i'll use to describe the above.

First, assuming currently libfnord is SLOT=0, and that there are no
ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use
the ${major} version from the SONAME for the sub-slot. IE:

libfnord-1:SLOT="0/3"
libfnord-2:SLOT="0/5"
libfnord-2.1:SLOT="0/5"
...
libfnord-3.5:SLOT="0/5"


And then, assuming that foo and bar both link in the usual way, IE
they link against libfnord.so.3 instead of just libfnord.so , they
both would RDEPEND as follows:

RDEPEND="app-cat/libfnord:="


> (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5
> would be masked due to some problem not noticed prior to stabling
> that makes it useless for many users. [2]bar-2.4 during configure
> checks for a new function in libfnord-3.5 and uses it if available,
> or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes
> a crash in some function of the library. (Note: this whole
> example/question sounds like an ebuild-quiz question that any dev
> should be able to answer then.)
>
> What would be the advantage of sub-slot here, assuming the
> versioning of the libraries follows ABI versioning rules defined by
> e.g. libtool.

[1] No advantage as sub-slots wouldn't relate to this, UNLESS the
masking would then remove -all- SLOT="0/5" versions from the tree. In
that case, the old SLOT="0/3" provider would be the 'upgrade' path and
so 'foo' and 'bar' would be triggered for rebuild (since the lib they
were linked to would be disappearing during emerge -uDN)

[2] In this case, the new ABI/API offering in libfnord-3.5 would need
to be addressed in the SLOT, ie, SLOT="0/5.12". As such when
libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged
of course) would be triggered for rebuild. 'foo' would afaik also be
triggered for rebuild, though, as (at present) there isn't a way to
match partial sub-slots (or sub-sub-slots, as it were) via the slot
operators := and :*.

[3] No advantage, as linking would be consistent. Sub-slots wouldn't
be needed in this case, and afaict updating libfnord-2.1 to
libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any
additional mediation anyways.

Hope this helps clear things up..

Ian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBIpGEACgkQ2ugaI38ACPBAAAD/T7kE+KkCJ2IfeHOmP/WYb+CX
ofEfsqWXZ2L0aNWDoZIA/0MeHvdH3Yul/SayBbg1Z1Etmiv6vt7f2QqBPArAl/L8
=pLhN
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 07:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org