Re: [gentoo-dev] mysql-4.1.12 call for testers

[Rumen Yotov]

Rumen Yotov wrote:

>Lance Albertson wrote:
>
>  
>
>>Robin H. Johnson wrote:
>>
>> 
>>
>>
>>
>>>Many thanks to Francesco Riosa <[EMAIL PROTECTED]> for his hard
>>>work in dealing with MySQL-4.1. He's joining Gentoo soon as a new developer 
>>>to
>>>help maintain MySQL for the 4.1 and 5.0 series, and hopefully also providing 
>>>a
>>>package for the official MySQL AB binaries.
>>>   
>>>
>>>  
>>>
>>Great work! I used his 4.1.11 ebuild recently and everything seems to work
>>pretty well. I'll see if I can try the 4.1.12 ebuild soon. Upgrades within the
>>4.1.x series shouldn't be painful right?
>>
>>Cheers,
>>
>> 
>>
>>
>>
>Hi,
>Also using 4.1.11 (ebuild from Francesco) on x86-stable, works OK.
>Will try out 4.1.12 soon.
>Rumen
>  
>
Hi,
Just finished emerging mysql-4.1.12 (unmasked first)- all OK, warnings
about "m4's underquoted defs".
Rumen


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[Doug Goldstein]

Stroller wrote:
> Hi,
> 
. far to long.
> 
> Stroller.
> 

In summary and simple conclusion, yes you are wrong. So that makes 2 out
of the 4 or 5 active Mobile herd devs who say you're wrong. brix is 100%
correct. Let me give you an explaination


  "The firmware itself does not depend on wireless-tools for operation.
   DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might
   want to use along with the package in question - it is for technical
   dependencies such as libraries and utilities."

There ya go. Explained. In fact, you actually explained the logical
reason in your e-mail, surprised you didn't notice it. But I'll
highlight it for you.

acx100 and rt2500 contain drivers. prism54 is a driver. ipw2200 is a
driver. They depend on wireless-tools. The firmware, which in 2 of these
cases are in seperate packages, do not depend on wireless-tools. And for
a last example which I just thought of... ndiswrapper acts the sameway.
Considering the Windows drivers are more of a "firmware" and ndiswrapper
is the driver.

-- 
Doug Goldstein <[EMAIL PROTECTED]>
http://dev.gentoo.org/~cardoe/


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Wireless driver / firmware ebuilds & wireless-tools

[Stroller]

Hi,

I thought about filing another bug about this, but decided I'd rather 
whine about it in public to get a better airing / flaming / 
understanding of the issues.


Using a wireless network card under linux may require various 
components:

- the hardware driver itself
- a firmware to be uploaded to the card via hotplug
- hotplug
- as I understand it: wireless-tools to actually configure the SSID, 
WEP key

  &c of the wireless network to be connected to.

Is my understanding of the last point incorrect?
Because it seems to me there's little point in emerging the ebuild for 
a wireless network card unless it's going to be connected to a wireless 
network, and in that case the least thing that's going to need setting 
is the SSID & IP address.


Prism54 is the name of one such driver, and because it is being 
incorporated into the main kernel tree there exists more than one 
ebuild for it - one which includes the hardware driver module itself, 
and one for one for users of the latest kernels who only require the 
firmware.


These two ebuilds take a different approach to wireless-tools - one 
requires it as a depend, the other does not:


$ emerge -pv prism54

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N] sys-apps/hotplug-20040923  43 kB
[ebuild  N] net-wireless/prism54-firmware-1.0.4.3  91 kB
[ebuild  N] net-wireless/wireless-tools-27  +nls 0 kB
[ebuild  N] net-wireless/prism54-20050125  -pcmcia 74 kB

Total size of downloads: 210 kB
$ emerge -pv prism54-firmware

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N] sys-apps/hotplug-20040923  43 kB
[ebuild  N] net-wireless/prism54-firmware-1.0.4.3  91 kB

Total size of downloads: 135 kB
$

I filed a bug  about this 
a few weeks ago, and was told:

  "The firmware itself does not depend on wireless-tools for operation.
   DEPEND/RDEPEND/PDEPEND in ebuilds are not for what you might
   want to use along with the package in question - it is for technical
   dependencies such as libraries and utilities."

Now, as I say, I can see few reasons to install the prism54 firmware & 
not use wireless-tools - were you to use a Prism54 card in passive-mode 
as a packet-sniffer then I suppose it's possible, but most users want 
to `emerge prism54-firmware` and have it "Just Work (tm)".


Having been blown out on my bug I took it deeply personally, then 
shrugged & forgot about it. Forgot about it, that is, until I went to 
setup the wireless card in a freshly-installed laptop today:


$ emerge -pv acx100

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N] net-wireless/wireless-tools-27  +nls 0 kB
[ebuild  N] net-wireless/acx100-0.2.0_pre8-r5  -pcmcia 275 kB

Total size of downloads: 275 kB
$

It seems to me that I could now file a bug about acx100 saying that it 
"incorrectly depends upon wireless-tools" but - unless I'm 
misunderstanding something pertinent - I still think this is the wrong 
behaviour. Whether I'm installing a prism54 or an acx100 card in my 
machine, I'm still going to need to iwconfig them to the right wireless 
network.


The ebuild for the Ralink cards seems to feel the same way:

$ emerge -pv rt2500

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N] net-wireless/wireless-tools-27  +nls 0 kB
[ebuild  N] net-wireless/rt2500-1.1.0_beta2-r1  +qt 286 kB

Total size of downloads: 286 kB
$

So, anyway, I don't intend for this posting to be a criticism of brix 
for blowing me out on my bug, I  just want to understand better. Can 
anyone tell me if there's a logical reason for wireless-tools to be 
treated differently by these 4 packages? If you "might want to use" 
wireless-tools in almost every circumstance with the prism54-firmware & 
this isn't covered by DEPEND/RDEPEND/PDEPEND, can we have a new 
variable "YOU_MIGHT_WANT_TO_USE_DEPEND", please?


Stroller.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Jason Stubbs]

On Friday 20 May 2005 21:30, Michael Haubenwallner wrote:
> Jason Stubbs wrote:
> 
>
> > I intend that the package to be installed should not assume anything
> > about where its dependencies are and should query portage for them all.
>
> Oh no, now many things get much clearer to me :(
>
> But - aren't there many settings left over to the packages to decide,
> at least to choose the package-defaults ?

Any package that does this is broken. There are a couple of cases where 
there's no other choice because portage doesn't allow for anything else but 
that will change.

> > Requiring ebuilds to have special handling for when their dependencies
> > are in the same ${PREFIX} and when in a different ${PREFIX} just seems
> > crazy to me.
>
> Agreed.
> You intend to use some portage-API in ebuilds which knows where and how
> to look for dependencies, did i get this right ?
> But having portage to behave differently seems crazy to me though.

I would fiercely disagree with implementing ${PREFIX} support without doing 
major changes in portage to support it. There's enough hacks in portage 
already.

> > If portage doesn't tell the packages what to build against, they'll go
> > their own merry way which would definitely make the binary packages
> > mentioned below impossible.
>
> Disagreed - binary packages right now can only be shared between highly
> identical machines...

In general, I do not be the case.

> It seems that there are two philosophies of how packages find their
> dependencies:
>
> 1) The Gentoo-Linux one:
>All the depency information comes from the package manager and is
>passed to packages by commandline, skipping the whole
>autoconf-intelligence.
>
> pro:
> + The patching required for packages is less complex, most of the
> time the autoconf-intelligence has to be disabled if there's a
> commandline parameter missing for a particular feature.

+ Portage is able to know what a package requires and can ensure system
  consistency.

+ Binary packages are possible.

> contra:
> - To get this work on different platforms, an autoconf alike
> intelligence has to be re-implemented to portage and the ebuilds,
> including access to provided/injected packages or to the
> primary pkg mgr's database.

Wrong. What do you think *DEPEND is if it's not "autoconf alike intelligence"?

> - External packages installed by hand into the primary prefix will not
> be stored in the primary pkg mgr's database and therefore cannot
> be seen by portage as the secondary mgr once portage could read it.

No different to the current system. This is what package.provided is for.

> - There's always a rest of decicions left to the package's
> autoconf-intelligence.

Such as? I don't know if this is a pro or a con or what.

> - This works for the primary package mgr, but would become
> unmaintainable for secondary installations - which is your
> legitimate fear.

Without it, there is no guarantee of system consistency and hence no reason 
for adding support for it into portage at all. If you don't want portage to
maintain system consistency for you, why not just do "./configure; make; make 
install" ?

> - Different behaviour seems to be required within the ebuilds or
> (through an API) portage if installed to / or prefix or ~.

Different behaviour between prefix or ~ only. / is just another prefix. This 
is definitely not a con of philosophy 1. It is a requirement regardless.

> 2) The one necessary for secondary installation:
>Let the packages decide from environment (PATH,PKG_CONFIG_PATH,...)
>and filesystem where to find their dependencies, and the package
>manager just has to prepare the environment variables and the
>filesystem to let the autoconf intelligence work.

"necessary"? I think not.

> pro:
> + Many of the packages already do compile and run on several platforms,
> by checking the environment and filesystem, and are shipped with the
> autoconf-intelligence required for that.
> This intelligence is used and therefore not needed in portage and
> ebuilds.

Works the same for "/", no? Tell me again what the point of portage is?

> + This is what autoconf/libtool are created for.

Do you use a new point to reiterate your last point just to make it look like 
your way is better?

> + If there are external packages installed by hand into the primary
> prefix, they are normally recognized, because they appear on the
> filesystem and in the environment.

Woops. Exactly the same point again.

> + When installing within a primary portage, this continues to work.

And again. Except that here you're saying that system consistency should be 
thrown out the window altogether. It seems to me like your concept of portage 
is:

emerge() {
PKG="$1"
tar zxf ${PKG}
cd ${PKG/.tar.gz/}
./configure
make && make install
}

> + The pkg mgr does nearly the same commands as an administrator likes to
> do 

Re: [gentoo-dev] Keywording, for the umpteenth time

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael Cummings wrote:
> It's a nice idea (I know I recently opened "negotiations" up with the mips 
> team for access so I could close some of my open bugs against them), but the 
> two problems I can see with this are: remote access tends to mean you can't 
> test any X related properly (shoot, I have a sparc sitting next to me 
> headless, but being headless I never broach the gui related sparc stuff)

You might like to try Xvfb, Xvnc, etc., perhaps over nomachine if your
network connection isn't too quick and you actually want to see the app.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCjn4NXVaO67S1rtsRAnWNAKDC1NJACSqtPg8zoqHouZdSDAs3IQCfYgJa
UwbAeXV9Lnckq0CBZAIBLwQ=
=1jAq
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Ciaran McCreesh]

On Fri, 20 May 2005 19:11:13 +0900 Georgi Georgiev <[EMAIL PROTECTED]>
wrote:
| O, so true, so true...
| 
| I am trying to redeem myself with the following. Care to give it a
| try?

Pretty close, thanks. I think I'll adapt it a bit to define a cluster in
make.vim and then add to that cluster in automake.vim rather than just
overriding the entire rule. That way if make.vim is ever updated we'll
either carry on working or get a nice visible patch failure rather than
silent weirdness. Bug 93378 if you want to track it.

I'll be doing new vim6 and 7 snapshots soon from the looks of things, so
I'll include it then.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp7qHRs1zmHY.pgp
Description: PGP signature

Re: [gentoo-dev] Keywording, for the umpteenth time

[Tom Wesley]

On Fri, 2005-05-20 at 22:22 +0100, Ciaran McCreesh wrote:
> Not gonna happen. Emulators don't cut it and won't find all the problems
> (but they will find a load of other bogus non-issues). Plus, from
> experience I'd say that at least half our devs wouldn't have a clue
> where to start when doing arch testing...

Add this HOWTO arch test to your developer docs.  Very nice by the way.

> Then there's the issue of most alt-archs having far higher QA standards
> than x86 anyway, and us not wanting to sink to what x86 considers
> acceptable for marking stable.
> 
> From experience -- the current policy as it is now *works*, so long as
> everyone follows it.

And as long as ciaranm, or someone from a non x86 arch bitches once a
month here.

-- 
Tom Wesley <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Keywording, for the umpteenth time

[Ciaran McCreesh]

On Fri, 20 May 2005 15:51:51 -0500 Brian Jackson <[EMAIL PROTECTED]>
wrote:
| Wouldn't it be better from a QA perspective to go back to the (really)
| old policy of dropping anything you can't test on. I know that puts
| more work on you guys, but this is only going to get worse as we get
| more devs. Wouldn't it be better to nip this in the bud now. Maybe
| broaden the arch teams by giving some devs access to remote boxes.

Not really. Dropping to ~arch when bumping works well. Sure, ~arch does
occasionally end up broken, but it's better than us lagging behind
massively. There're too many packages and not enough people these
days...

The assumption is, if foo-1.2 works on, say, sparc, then foo-1.3
probably will too to the extent that we're happy for it to go to ~sparc.
On the other hand, we're *not* confident enough in upstreams' abilities
to always put out perfect releases that we're prepared to move things to
stable without explicit testing.

See, we *really* don't want arch to get broken. We'd rather ~arch didn't
break either, of course, but taking the occasional hit there is
acceptable if it lets us keep everything up to date.

| Get every dev access to all the supported arches (some of this could
| probably be done with emulators of some sort, qemu or somesuch). Make
| them test on every arch before they change any keywords.

Not gonna happen. Emulators don't cut it and won't find all the problems
(but they will find a load of other bogus non-issues). Plus, from
experience I'd say that at least half our devs wouldn't have a clue
where to start when doing arch testing...

Then there's the issue of most alt-archs having far higher QA standards
than x86 anyway, and us not wanting to sink to what x86 considers
acceptable for marking stable.

From experience -- the current policy as it is now *works*, so long as
everyone follows it.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgp2HGtPZzQ6m.pgp
Description: PGP signature

Re: [gentoo-dev] Keywording, for the umpteenth time

[Michael Cummings]

On Friday 20 May 2005 16:51, Brian Jackson wrote:
>
> Get every dev access to all the supported arches (some of this could
> probably be done with emulators of some sort, qemu or somesuch). Make them
> test on every arch before they change any keywords.

It's a nice idea (I know I recently opened "negotiations" up with the mips 
team for access so I could close some of my open bugs against them), but the 
two problems I can see with this are: remote access tends to mean you can't 
test any X related properly (shoot, I have a sparc sitting next to me 
headless, but being headless I never broach the gui related sparc stuff), and 
ultimately, that kind of open ended freedom will still result in people 
marking things ~arch and arch that they shouldn't be - maybe they rushed and 
just made sure it installed, not really worked, or they figure they can 
always go back later if they see any bugs.

Man, when did I become the dour note?

-- 
-o()o-
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net 
-o()o-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Keywording, for the umpteenth time

[Brian Jackson]

Jason Wever wrote:

> 
> From my perspective, if a package maintainer asks for testing and the
> ability to keyword (i.e. Spanky asking me if it was OK to bump binutils
> to 2.16, to which I said yes) then that is fine.  However adding or
> changing keywords in an ebuild for which you cannot test (regardless of
> how trivial the changes are or how "portable" the programming language
> of said package is supposed to be) is really where I'm looking at here.

Wouldn't it be better from a QA perspective to go back to the (really) old
policy of dropping anything you can't test on. I know that puts more work on you
guys, but this is only going to get worse as we get more devs. Wouldn't it be
better to nip this in the bud now. Maybe broaden the arch teams by giving some
devs access to remote boxes.

--Or--

Get every dev access to all the supported arches (some of this could probably be
done with emulators of some sort, qemu or somesuch). Make them test on every
arch before they change any keywords.

--Iggy

> 
> For some odd reason, trying to ensure QA (even in the nicest of
> fashions) seems to result in a majority of less than positive
> responses.  Even recently I've had a developer get quite confrontational
> with me over email when I nicely asked him not to stabilize packages for
> which he could not test (even if the changes were supposedly trivial). 
> History has shown that we cannot depend on assuming that trivial changes
> for me == works for you if we want to have some level of Q in QA.
> 
> Cheers,
> - -- Jason Wever
> Gentoo/Sparc Co-Team Lead

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Keywording, for the umpteenth time

[Jason Wever]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 20 May 2005, Duncan Coutts wrote:
Sorry folks this was my fault. I've sent my grovelling apology to the
sparc team. Hopefully they'll accept my apologies and put my digressions
down to me being a new dev. :-)
You can only take some of the credit Duncan, but not all of it :)
Every once and a while it seems a reminder such as this is needed as 
people tend to start playing with package keywords when they shouldn't be. 
It's kind of like guarding the cookie jar, you can't ever let your guard 
down, even if you cut off everyone else's hands.  I try not to point 
fingers or name names since it's not something I like done to myself.  I'd 
also like to think that this gives such guilty parties a better 
understanding of why the arch teams (and especially SPARC) can be so 
maniacal about this sometimes, in hopes that it will lessen and/or prevent 
this problem in the future.

From my perspective, if a package maintainer asks for testing and the 
ability to keyword (i.e. Spanky asking me if it was OK to bump binutils to 
2.16, to which I said yes) then that is fine.  However adding or changing 
keywords in an ebuild for which you cannot test (regardless of how trivial 
the changes are or how "portable" the programming language of said package 
is supposed to be) is really where I'm looking at here.

For some odd reason, trying to ensure QA (even in the nicest of fashions) 
seems to result in a majority of less than positive responses.  Even 
recently I've had a developer get quite confrontational with me over email 
when I nicely asked him not to stabilize packages for which he could not 
test (even if the changes were supposedly trivial).  History has shown 
that we cannot depend on assuming that trivial changes for me == works for 
you if we want to have some level of Q in QA.

Cheers,
- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCjkP3dKvgdVioq28RAqw+AJ9yuqHTVZSsdnfyFt9PgJSm3jt+2QCdEjwE
TS+flVWEr60GwuMEdWIqV/g=
=xrIF
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Keywording, for the umpteenth time

[Mike Frysinger]

On Friday 20 May 2005 02:53 pm, Duncan Coutts wrote:
> Sorry folks this was my fault.

ah, good to know ... thought it might have been my binutils-2.16 ~sparc 
marking, but i guess that's somewhat sane since Weeve gave it a quick run and 
it seems to be OK thus far ...
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Keywording, for the umpteenth time

[Duncan Coutts]

On Fri, 2005-05-20 at 10:42 -0600, Jason Wever wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> OK, let's review this again.
> 
> If you cannot test a given ebuild on a given arch, then don't touch that 
> arch's keyword (unless you need to remove it for broken dependencies).
> 
> If you can test for a given arch and are not part of that arch team, 
> please please please let the arch teams know that before you go around 
> keywording things arbitrarily.  It makes the baby Jesus cry when you don't 
> and really isn't the greatest from a QA perspective either.

Sorry folks this was my fault. I've sent my grovelling apology to the
sparc team. Hopefully they'll accept my apologies and put my digressions
down to me being a new dev. :-)

Actually I did do fairly thorough testing / QA but I didn't tell the
arch team before keywording (bad me!).

In case anyone is interested; this is about the Haskell packages which I
hope to get up to scratch on sparc (with the consent and approval of the
sparc team in future!)

Duncan

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Keywording, for the umpteenth time

[Jason Wever]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OK, let's review this again.
If you cannot test a given ebuild on a given arch, then don't touch that 
arch's keyword (unless you need to remove it for broken dependencies).

If you can test for a given arch and are not part of that arch team, 
please please please let the arch teams know that before you go around 
keywording things arbitrarily.  It makes the baby Jesus cry when you don't 
and really isn't the greatest from a QA perspective either.

Maintaining almost all of the packages in the portage tree is a demanding 
job, but it is what we as architecture teams do.  Please respect 
architecture keywording like you were trying to make changes to a package 
someone else maintains.

Thanks,
- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCjhNpdKvgdVioq28RAhhtAJ0cJQ2XH5I25ZNShYZrpf0MXXxIwwCgoyqE
m9Ax44lGL3GlqhIalNDcTMA=
=Ey/o
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Request for Permission

[Paul de Vrieze]

On Monday 16 May 2005 23:48, Drake Wyrm wrote:
> Rick Sivernell <[EMAIL PROTECTED]> wrote:
> > I am operating a small IT service organization and I would like to
> > put a link to Gentoo on my site. My ad:
>
> [snip]
>
> > If there is a standard ad that you would prefer, I will use it. This
> > is a service for my clients use and reference. If you allow my
> > listing your site, please extend your permission.
>
> If I'm out of line here, somebody slap me.

Not really. This request should of course be send to the foundation ;-), 
but that's not really a problem.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpT9DSFNotyD.pgp
Description: PGP signature

Re: [gentoo-dev] Naming scheme confusion

[Paul de Vrieze]

On Tuesday 17 May 2005 10:27, Marius Mauch wrote:
>
> Well, it's valid with portage-2.1, but not 2.0.

Concerning that, how far are we from it being testable by the general 
developer population?

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpUaDXjWhOxK.pgp
Description: PGP signature

Re: [gentoo-dev] Naming scheme confusion

[Paul de Vrieze]

On Monday 16 May 2005 15:04, Henrik Brix Andersen wrote:
>
> The current ebuild is orinoco-0.15_rc2-r2.ebuild, and the logical name
> for a CVS snapshot would, as I see it, be
> orinoco-0.15_rc2_pre20050516.ebuild, but mixing _rcX and _preY is not
> allowed by portage.

in any case it should be _pY as your snapshot is newer than the current 
version. _p stands for patch level, _pre for prerelease. In case of cvs 
ebuilds patch levels are more appropriate as the new version is often not 
known.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpJx3HZxt37N.pgp
Description: PGP signature

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Michael Haubenwallner]

Jason Stubbs wrote:

> I intend that the package to be installed should not assume anything about 
> where its dependencies are and should query portage for them all.

Oh no, now many things get much clearer to me :(

But - aren't there many settings left over to the packages to decide,
at least to choose the package-defaults ?

> Requiring ebuilds to have special handling for when their dependencies
> are in the same ${PREFIX} and when in a different ${PREFIX} just seems
> crazy to me.

Agreed.
You intend to use some portage-API in ebuilds which knows where and how
to look for dependencies, did i get this right ?
But having portage to behave differently seems crazy to me though.

> If portage doesn't tell the packages what to build against, they'll go their 
> own merry way which would definitely make the binary packages mentioned below 
> impossible.

Disagreed - binary packages right now can only be shared between highly
identical machines...

It seems that there are two philosophies of how packages find their
dependencies:

1) The Gentoo-Linux one:
   All the depency information comes from the package manager and is
   passed to packages by commandline, skipping the whole
   autoconf-intelligence.

pro:
+ The patching required for packages is less complex, most of the
time the autoconf-intelligence has to be disabled if there's a
commandline parameter missing for a particular feature.

contra:
- To get this work on different platforms, an autoconf alike
intelligence has to be re-implemented to portage and the ebuilds,
including access to provided/injected packages or to the
primary pkg mgr's database.

- External packages installed by hand into the primary prefix will not
be stored in the primary pkg mgr's database and therefore cannot
be seen by portage as the secondary mgr once portage could read it.

- There's always a rest of decicions left to the package's
autoconf-intelligence.

- This works for the primary package mgr, but would become
unmaintainable for secondary installations - which is your
legitimate fear.

- Different behaviour seems to be required within the ebuilds or
(through an API) portage if installed to / or prefix or ~.

2) The one necessary for secondary installation:
   Let the packages decide from environment (PATH,PKG_CONFIG_PATH,...)
   and filesystem where to find their dependencies, and the package
   manager just has to prepare the environment variables and the
   filesystem to let the autoconf intelligence work.

pro:
+ Many of the packages already do compile and run on several platforms,
by checking the environment and filesystem, and are shipped with the
autoconf-intelligence required for that.
This intelligence is used and therefore not needed in portage and
ebuilds.

+ This is what autoconf/libtool are created for.

+ If there are external packages installed by hand into the primary
prefix, they are normally recognized, because they appear on the
filesystem and in the environment.

+ When installing within a primary portage, this continues to work.

+ The pkg mgr does nearly the same commands as an administrator likes to
do by hand if she has no pkg mgr at hand:
   ./configure [--prefix=/my/prefix]
   make
   make install [DESTDIR=/tmp/inst]
without any more arguments ideally.

+ Seems to be much less need for ebuild/portage to behave differently if
installed to / or prefix or ~

contra:
- If the autoconf-intelligence does not work, there's more effort needed
to create the patches to get it work.

- There's always a rest of issues needed to be dealt with in some
ebuilds.


Portage itself does not predetermine which philosophy to use - it is to
the ebuild-dev to choose one - but maybe portage's full-support for the
former "doesn't exist and isn't going to exist for a very long time, if
ever" (to say it with ciaranm's words).

To me now, my real problem seems to be the philosophy established
in the ebuild-devs right now, could that be the case ?

> Until portage supports other package formats, an equivalent of 
> package.provided would be used for this. However, this has nothing to do with 
> how ebuilds would find out where their dependencies are.

Agreed, but just to ensure unterstanding:
One thing is the dependency tree for the pkg mgr to install all the
prerequisites, the other is how packages then find those prerequisites,
right ?

>>>7  Portage needs to be able to configured with one-way dependency
>>>allowance between installed package databases. For example, ~ installed
>>>packages are allowed to depend on / installed packages.

When installing a package into ~, a dependency install to / or prefix
becomes triggered or sth. like that, do you mean this ?

> This is just silly, in my opinion. Home-support may have issues beyond 
> prefix-support, but most of them are the same. Why would you only want to 
> consider prefix-support and implement it if considering home-

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Georgi Georgiev]

maillog: 20/05/2005-10:29:53(+0100): Ciaran McCreesh types
> On Fri, 20 May 2005 18:01:04 +0900 Georgi Georgiev <[EMAIL PROTECTED]>
> wrote:
> | > | %.1 : %.in
> | > | @regex_cmd@ -e "s,[EMAIL PROTECTED]@,$(VERSION),g" $? > 
> $@
> | > | 
> | > | The first "@" is span.Special and the second one is span.Constant.
> | > 
> | > Hrm, that's a vim thing (I'm using a vim script to do the
> | > highlighting at compile time, it's not manual). If someone enjoys
> | > pain they could have a go at making vim's automake highlighting
> | > smarter... Don't think I'm brave enough to touch that one myself.
> | 
> | The 2html.vim that comes with vim seems to work fine here. Tried both
> | 7__ and 6.3. The HTML is ugly, but at least it's properly highlighted:
> | 
> | http://gg3.net/~chutz/gentoo/highlight/
> | 
> | Of course, you need to "set ft=automake", which is different than
> | ft=make. ;)
> 
> That's only working because you're indenting using spaces rather than
> tabs. If you indent using tabs you'll get the mixed colouring.

O, so true, so true...

I am trying to redeem myself with the following. Care to give it a try?

--- /usr/share/vim/vim70aa/syntax/automake.vim.old  2005-05-20 
19:05:09.0 +0900
+++ /usr/share/vim/vim70aa/syntax/automake.vim  2005-05-20 19:07:05.0 
+0900
@@ -43,6 +43,7 @@
 syn region  automakeMakeDString start=+"+  skip=+\\"+  end=+"+  
contains=makeIdent,automakeSubstitution
 syn region  automakeMakeSString start=+'+  skip=+\\'+  end=+'+  
contains=makeIdent,automakeSubstitution
 syn region  automakeMakeBString start=+`+  skip=+\\`+  end=+`+  
contains=makeIdent,makeSString,makeDString,makeNextLine,automakeSubstitution
+syn region makeCommands start=";"hs=s+1 start="^\t" end="^[^\t#]"me=e-1,re=e-1 
end="^$" contained 
contains=makeCmdNextLine,makeSpecial,makeComment,makeIdent,makePreCondit,makeDefine,makeDString,makeSString,autoMakeSubst,automakeMakeError,automakeBadSubst
 nextgroup=makeCommandError
 
 " Define the default highlighting.
 " For version 5.7 and earlier: only when not done already

-- 
/\   Georgi Georgiev   /\ Be not anxious about what you have, but  /\
\/[EMAIL PROTECTED]\/ about what you are. -- Pope St. Gregory I\/
/\  +81(90)2877-8845   /\  /\


pgpl8EQHZEjAs.pgp
Description: PGP signature

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Georgi Georgiev]

maillog: 20/05/2005-18:01:04(+0900): $B'$'V'`'b'T'Z(B $B'$'V'`'b'T'Z'V'S(B 
(Btypes
(B> maillog: 20/05/2005-07:22:15(+0100): Ciaran McCreesh types
(B> > Hrm, that's a vim thing (I'm using a vim script to do the highlighting
(B> > at compile time, it's not manual). If someone enjoys pain they could
(B> > have a go at making vim's automake highlighting smarter... Don't think
(B> > I'm brave enough to touch that one myself.
(B> 
(B> The 2html.vim that comes with vim seems to work fine here. Tried both 
(B> 7$B&A(B
(B> and 6.3. The HTML is ugly, but at least it's properly highlighted:
(B> 
(B> http://gg3.net/~chutz/gentoo/highlight/
(B> 
(B> Of course, you need to "set ft=automake", which is different than
(B> ft=make. ;)
(B> 
(B> $ vim -c 'set ft=automake' Makefile.in -c TOhtml -c wq -c qa
(B
(BTaking back my words about the ugly HTML. I just met html_use_css.
(B
(Bvim -c 'set ft=automake' -c 'let use_xhtml=1' -c 'let html_use_css=1' \
(B-c TOhtml -c wq -c qa Makefile.in
(B
(B-- 
(B(Georgi Georgiev   (  heavy, adj.: Seduced by the chocolate side   (
(B )[EMAIL PROTECTED] ) of the force. )
(B(   +81(90)2877-8845   (   (

pgp31bGu2WOzT.pgp
Description: PGP signature

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Ciaran McCreesh]

On Fri, 20 May 2005 18:01:04 +0900 Georgi Georgiev <[EMAIL PROTECTED]>
wrote:
| > |   %.1 : %.in
| > |   @regex_cmd@ -e "s,[EMAIL PROTECTED]@,$(VERSION),g" $? > $@
| > | 
| > | The first "@" is span.Special and the second one is span.Constant.
| > 
| > Hrm, that's a vim thing (I'm using a vim script to do the
| > highlighting at compile time, it's not manual). If someone enjoys
| > pain they could have a go at making vim's automake highlighting
| > smarter... Don't think I'm brave enough to touch that one myself.
| 
| The 2html.vim that comes with vim seems to work fine here. Tried both
| 7__ and 6.3. The HTML is ugly, but at least it's properly highlighted:
| 
| http://gg3.net/~chutz/gentoo/highlight/
| 
| Of course, you need to "set ft=automake", which is different than
| ft=make. ;)

That's only working because you're indenting using spaces rather than
tabs. If you indent using tabs you'll get the mixed colouring.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



pgpwdBL1vLriN.pgp
Description: PGP signature

Re: [gentoo-dev] Unofficial Gentoo Development Guide and Autotools

[Georgi Georgiev]

maillog: 20/05/2005-07:22:15(+0100): Ciaran McCreesh types
> On Fri, 20 May 2005 15:06:12 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> | The phrase "when an option is specified" is a bit ambiguous,
> | especially since it is later referred by the explanation of
> | AC_ARG_WITH. I was not sure if "option" in this case means "option" as
> | in "--enable-foo=OPTION". I was confused, because one paragarph before
> | the example you talk about "--enable-foo and --disable-foo *switches*
> | to ./configure".
> 
> .. Important:: The third argument is used when a ``--enable`` or
>   ``--disable`` switch to ``./configure`` is provided, and the fourth
>   is used when such a switch is *not* passed. A common misconception is
>   that the third is enable and the fourth is disable -- this is **not**
>   the case. You may encounter packages that get this wrong.
> 
> Does that sound any better?

Yes, much better.

> | - coloring
> | 
> | %.1 : %.in
> | @regex_cmd@ -e "s,[EMAIL PROTECTED]@,$(VERSION),g" $? > $@
> | 
> | The first "@" is span.Special and the second one is span.Constant.
> 
> Hrm, that's a vim thing (I'm using a vim script to do the highlighting
> at compile time, it's not manual). If someone enjoys pain they could
> have a go at making vim's automake highlighting smarter... Don't think
> I'm brave enough to touch that one myself.

The 2html.vim that comes with vim seems to work fine here. Tried both 7Î
and 6.3. The HTML is ugly, but at least it's properly highlighted:

http://gg3.net/~chutz/gentoo/highlight/

Of course, you need to "set ft=automake", which is different than
ft=make. ;)

$ vim -c 'set ft=automake' Makefile.in -c TOhtml -c wq -c qa

-- 
 /   Georgi Georgiev/ Harp not on that string. -- William   /
\ [EMAIL PROTECTED]\  Shakespeare, "Henry VI"  \
 /  +81(90)2877-8845/   /


pgptkHQIuqNRC.pgp
Description: PGP signature

[gentoo-dev] Re: UPGRADE complete bugs.gentoo.org

[R Hill]

Hello.
Jeffrey Forman wrote:
The upgrade for bugs.gentoo.org went exactly as I had planned for.
Completed in under 20 minutes, which included this email. I've upgraded
our Bugzilla from the old 2.18rc2 to 2.18.1. This fixes more security
and code than I can even begin to mention. I have cleaned out a lot of
the code and added in some nice features.
Sorry to bother you, but I was wondering what ppl think about the 
Advanced Query and "Step one: search for your bug." on the submittal 
form only searching open bugs.  I don't believe this was the case before 
the upgrade, but i could just have noticed it now.  Either way, having 
these search all bugs, open and closed, would seriously lessen the 
number of dupes IMO.  especially on the submittal form, where there's no 
way to change the behaviour and no indication that only open bugs are 
being returned.  for most users, that search is the only one they do (if 
they do one at all).  even for people that do bother to do an actual 
query, the adv search screen is a nightmare behemoth of complexity for 
the avg user.  defaults should be geared towards these types of people 
so they can get the most accurate information they can without needing 
to know what all the buttons do, and hopefully stop filing dupes.

did i mention it would cut down on dupes?
;)
--de.
--
gentoo-dev@gentoo.org mailing list