[gentoo-dev] help

[gentoo_bugs_peep]

help

[gentoo-dev] help

[darveter]

help

Mit freundlichen Grüßen

Ilja Pogrebnjak

--
Ilja Pogrebnjak 

GnuPG-KeyID: 0x834288FD
Fingerprint: 3849 A2DF 5EFB 9F7E BD51  AC8C F422 ED39 8342 88FD

Re: [gentoo-dev] Help wanted with net-misc/frr maintenance

[Alarig Le Lay]

On Wed 12 Jul 2023 22:38:00 GMT, Jakov Smolić wrote:
> Great!
> 
> If you want to get started it would be good to update the package (and 
> dev-util/clippy with it too) to latest version and fix some of the open 
> bugs. Feel free to ping me on IRC if you run into problems or need any help.
> 
> Thanks,

I bumped the version my overlay (because it’s easy) and upgraded one of
my machines:
rr2 ~ # vtysh

Hello, this is FRRouting (version 8.5.2-gentoo).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

I’ll let it run through the night and push tomorrow if nagios is happy.

-- 
Alarig

Re: [gentoo-dev] Help wanted with net-misc/frr maintenance

[Christian Bricart]

Am 13.07.23 um 09:10 schrieb Jaco Kroon:

Hi Alarig,

On 2023/07/12 15:18, Alarig Le Lay wrote:

Hello Jakov,

On Wed 12 Jul 2023 10:54:47 GMT, Jakov Smolić wrote:

Hi all,
I was recently left as the sole maintainer of net-misc/frr and given I'm
not actively using the package anymore it would be good if someone who
is an active user could take over. There are several open bugs and a new
upstream release.

I can stay as a secondary maintainer and help out (non-Gentoo developers
are also welcome, I can proxy for you), otherwise if no one is
interested I'll drop the package to maintainer-needed soon.

Regards,

I’m already maintaining bird, so I could happily step in for frr as
well!
Happy to assist where I can.  For the most part frr "just works" for us 
though.  Also not something we like to upgrade on a frequent basis 
unless there is a specific reason to.


Kind Regards,
Jaco



FYI: upstream also has a (neglected?) overlay on their site:
https://github.com/FRRouting/gentoo-overlay

Christian

Re: [gentoo-dev] Help wanted with net-misc/frr maintenance

[Jaco Kroon]

Hi Alarig,

On 2023/07/12 15:18, Alarig Le Lay wrote:

Hello Jakov,

On Wed 12 Jul 2023 10:54:47 GMT, Jakov Smolić wrote:

Hi all,
I was recently left as the sole maintainer of net-misc/frr and given I'm
not actively using the package anymore it would be good if someone who
is an active user could take over. There are several open bugs and a new
upstream release.

I can stay as a secondary maintainer and help out (non-Gentoo developers
are also welcome, I can proxy for you), otherwise if no one is
interested I'll drop the package to maintainer-needed soon.

Regards,

I’m already maintaining bird, so I could happily step in for frr as
well!
Happy to assist where I can.  For the most part frr "just works" for us 
though.  Also not something we like to upgrade on a frequent basis 
unless there is a specific reason to.


Kind Regards,
Jaco

Re: [gentoo-dev] Help wanted with net-misc/frr maintenance

[Jakov Smolić]

On 7/12/23 15:18, Alarig Le Lay wrote:

Hello Jakov,

On Wed 12 Jul 2023 10:54:47 GMT, Jakov Smolić wrote:

Hi all,
I was recently left as the sole maintainer of net-misc/frr and given I'm
not actively using the package anymore it would be good if someone who
is an active user could take over. There are several open bugs and a new
upstream release.

I can stay as a secondary maintainer and help out (non-Gentoo developers
are also welcome, I can proxy for you), otherwise if no one is
interested I'll drop the package to maintainer-needed soon.

Regards,


I’m already maintaining bird, so I could happily step in for frr as
well!

Great!

If you want to get started it would be good to update the package (and 
dev-util/clippy with it too) to latest version and fix some of the open 
bugs. Feel free to ping me on IRC if you run into problems or need any help.


Thanks,




--
Jakov

Re: [gentoo-dev] Help wanted with net-misc/frr maintenance

[Alarig Le Lay]

Hello Jakov,

On Wed 12 Jul 2023 10:54:47 GMT, Jakov Smolić wrote:
> Hi all,
> I was recently left as the sole maintainer of net-misc/frr and given I'm 
> not actively using the package anymore it would be good if someone who 
> is an active user could take over. There are several open bugs and a new 
> upstream release.
> 
> I can stay as a secondary maintainer and help out (non-Gentoo developers 
> are also welcome, I can proxy for you), otherwise if no one is 
> interested I'll drop the package to maintainer-needed soon.
> 
> Regards,

I’m already maintaining bird, so I could happily step in for frr as
well!

-- 
Alarig

[gentoo-dev] Help wanted with net-misc/frr maintenance

[Jakov Smolić]

Hi all,
I was recently left as the sole maintainer of net-misc/frr and given I'm 
not actively using the package anymore it would be good if someone who 
is an active user could take over. There are several open bugs and a new 
upstream release.


I can stay as a secondary maintainer and help out (non-Gentoo developers 
are also welcome, I can proxy for you), otherwise if no one is 
interested I'll drop the package to maintainer-needed soon.


Regards,
--
Jakov

Re: [gentoo-dev] Help with "unrecognized ELF files" needed

[Sam James]

> On 15 Oct 2021, at 16:00, xgqt  wrote:
> 
> Hi!
> 
> I'm having a problem with guile packages and portage QA checks.
> Guile puts the compiled bytecode into the /usr/lib64 directory which produces 
> a portage warning that unrecognized ELF files are being installed.
> 
> Example bug reports:
> https://bugs.gentoo.org/727146
> https://bugs.gentoo.org/817230
> 
> What can I do about this issue?

You can silence the QA warnings _if they're not genuine_ with QA_* variables. 
See https://devmanual.gentoo.org/eclass-reference/ebuild/index.html
or man ebuild.

But looks like you did that already now.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

[gentoo-dev] Help with "unrecognized ELF files" needed

[xgqt]

Hi!

I'm having a problem with guile packages and portage QA checks.
Guile puts the compiled bytecode into the /usr/lib64 directory which 
produces a portage warning that unrecognized ELF files are being installed.


Example bug reports:
https://bugs.gentoo.org/727146
https://bugs.gentoo.org/817230

What can I do about this issue?

--
Have a great day!

~ Maciej XGQT Barć

Re: [gentoo-dev] Help with category for Authenticator

[Alexander Trotsenko]

Thank you, guys

I actually like Andrew's suggestion for sys-auth. I am still relatively
new to gentoo, so when I was skipping through all the categories it just
didn't sound like even a possible match to me. But its description
definitely sounds very close to Authenticator. I guess I was scared off
by the sys- prefix :)

Alex.

On 8/28/18 10:01 AM, Andrew Savchenko wrote:
> On Tue, 28 Aug 2018 09:32:29 -0500 Alexander Trotsenko wrote:
>> Hello, guys!
>>
>> I tried asking this question in #gentoo-proxy-maint IRC and I was told I
>> should venture for gentoo-dev mailing list.
>>
>> So I introduced a new package into Gentoo, Authenticator
>> (https://github.com/bilelmoussaoui/Authenticator). I placed it under
>> gnome-extra. However, shortly after the commit, gnome-extra guy said it
>> does not belong there and I am supposed it to move somewhere else. There
>> is a bug that touches this subject https://bugs.gentoo.org/663820.
>>
>> I currently consider to move it to app-crypt. Some folks also suggested
>> net-misc as a reasonable destination. I wonder if I could contact
>> "maintainers" so to say of those categories to make sure they are
>> willing to accept authenticator within their category.
>>
>> What's the best way to handle this situation? Also, if somebody wants to
>> suggest yet another category, speak up!
> I suggest the system-auth category.
>
> Why? It is always good to look where similar applications belong.
> Authenticator is basicall 2FA/OATH GUI, and oath-toolkit is in
> system-auth, most yubikey stuff is there as well.
>
> And now look in sys-auth/metadata.xml:
>
> The sys-auth category contains applications and libraries to support
> authentication and authorization facilities.
> Here belongs PAM modules, NSS modules and login apps.
>
> Authenticator fits here perfectly as an application to support
> authentication and authorization facilities.
>
> Best regards,
> Andrew Savchenko

Re: [gentoo-dev] Help with category for Authenticator

[Andrew Savchenko]

On Tue, 28 Aug 2018 09:32:29 -0500 Alexander Trotsenko wrote:
> Hello, guys!
> 
> I tried asking this question in #gentoo-proxy-maint IRC and I was told I
> should venture for gentoo-dev mailing list.
> 
> So I introduced a new package into Gentoo, Authenticator
> (https://github.com/bilelmoussaoui/Authenticator). I placed it under
> gnome-extra. However, shortly after the commit, gnome-extra guy said it
> does not belong there and I am supposed it to move somewhere else. There
> is a bug that touches this subject https://bugs.gentoo.org/663820.
> 
> I currently consider to move it to app-crypt. Some folks also suggested
> net-misc as a reasonable destination. I wonder if I could contact
> "maintainers" so to say of those categories to make sure they are
> willing to accept authenticator within their category.
> 
> What's the best way to handle this situation? Also, if somebody wants to
> suggest yet another category, speak up!

I suggest the system-auth category.

Why? It is always good to look where similar applications belong.
Authenticator is basicall 2FA/OATH GUI, and oath-toolkit is in
system-auth, most yubikey stuff is there as well.

And now look in sys-auth/metadata.xml:

The sys-auth category contains applications and libraries to support
authentication and authorization facilities.
Here belongs PAM modules, NSS modules and login apps.

Authenticator fits here perfectly as an application to support
authentication and authorization facilities.

Best regards,
Andrew Savchenko


pgpDIGc0wsY_P.pgp
Description: PGP signature

Re: [gentoo-dev] Help with category for Authenticator

[kuzetsa]

On 08/28/2018 10:32 AM, Alexander Trotsenko wrote:
> Hello, guys!
> 
> I tried asking this question in #gentoo-proxy-maint IRC and I was told I
> should venture for gentoo-dev mailing list.
> 
> So I introduced a new package into Gentoo, Authenticator
> (https://github.com/bilelmoussaoui/Authenticator). I placed it under
> gnome-extra. However, shortly after the commit, gnome-extra guy said it
> does not belong there [...]

> I currently consider to move it to app-crypt. Some folks also suggested
> net-misc as a reasonable destination. [...]
> 
> Thank you!
> Alex.
> 
> 


gnome-extra is for things maintained by gnome, right?

app-crypt is more accurate than net-${anything}

--kuza

[gentoo-dev] Help with category for Authenticator

[Alexander Trotsenko]

Hello, guys!

I tried asking this question in #gentoo-proxy-maint IRC and I was told I
should venture for gentoo-dev mailing list.

So I introduced a new package into Gentoo, Authenticator
(https://github.com/bilelmoussaoui/Authenticator). I placed it under
gnome-extra. However, shortly after the commit, gnome-extra guy said it
does not belong there and I am supposed it to move somewhere else. There
is a bug that touches this subject https://bugs.gentoo.org/663820.

I currently consider to move it to app-crypt. Some folks also suggested
net-misc as a reasonable destination. I wonder if I could contact
"maintainers" so to say of those categories to make sure they are
willing to accept authenticator within their category.

What's the best way to handle this situation? Also, if somebody wants to
suggest yet another category, speak up!

Thank you!
Alex.

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/12/2017 10:21 AM, Ulrich Mueller wrote:
> 
>>   * Change the PMS to remove "undefined behavior" and replace it with
>> "empty directories must be tracked, and may only be removed once no
>> installed package is using them," or something along those lines.
>> That leaves the implementation up to the PM.
> 
> How? Look up VDB entries of all installed packages? Note that this
> would have to be done for every dir that becomes empty, not just the
> ones currently containing a .keep_* file.

Not necessarily. I chose the "empty directories must be tracked" wording
to avoid that. If the PM were about to remove a directory that wasn't in
the database of empty directories, then it could proceed normally.


> What problem are you trying to solve? I see typically around 100
> .keep_* files on my systems. These are empty files, so they don't use
> any blocks. And 100 inodes system wide looks like negligible usage
> of resources to me.

If you're asking what problem I was trying to solve by leaving the
implementation up to the PM, then I was only trying not to be pushy. If
the "automatic keepdir" idea...

>   * Have portage call its keepdir code on any empty directories in $D
> between src_install and pkg_preinst.

is workable and if the PM authors are fine with it, then we could spec that.

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/12/2017 08:43 AM, Michał Górny wrote:
> 
> I'm not convinced a QA warning is valid, given that not every empty
> directory is meaningful. You're going to either cause people to create
> unnecessary 'keepdir's, or to be swamped by false positives.

The warning would essentially be saying, "you installed this empty
directory, do you need it?" Granted, it would be annoying if the answer
was "no" and if my package triggered thirty of them, but then that's a
bug (possibly upstream) that should be reported and fixed. On the other
hand, if you need the directory, then you should be calling "keepdir" on
it -- so in either case I don't think the warning is a false positive.


>>   * Have portage call its keepdir code on any empty directories in $D
>> between src_install and pkg_preinst.
> 
> How does this account for /run and other non-persistent locations?

What specific problem do you foresee?

The implementation above should be no worse than what we have. Right
now, there are a lot of ebuilds that are installing empty directories.
Those ebuilds are buggy in one way or another: either relying on
undefined behavior, or creating unused directories for no reason. (Many
of the first type are not easily fixed, since the upstream build system
creates them.) The "automatic keepdir" would still create unused
directories, but it would fix the directories that should have been
keepdir'd but weren't.

This presents the usual problems with /run, but none that we don't
already have. Ebuilds that create directories under /run already receive
a QA warning not to do that, and those directories are already clobbered
on a reboot; that doesn't change. If a package like baselayout wants to
create an empty /run, it can do so in pkg_postinst to avoid the ".keep"
file. What else am I missing?


>>   * Change the PMS to remove "undefined behavior" and replace it with
>> "empty directories must be tracked, and may only be removed once no
>> installed package is using them," or something along those lines.
>> That leaves the implementation up to the PM.
> 
> ...and makes interoperability between different package managers
> impossible, defeating the purpose of PMS in the first place.

Well, that's why I'm asking.. I don't know WTF I'm doing, but I'd still
like the proposal to be decent when I give it to the people who do.

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Ulrich Mueller]

> On Sun, 12 Nov 2017, Michael Orlitzky wrote:

> Some day -- I'll add it to my list. For now I'll update the docs to
> explain why you should use keepdir, and do a QA warning for empty
> directories. Then how does this sound for EAPI=next?

>   * Ban keepdir.

>   * Have portage call its keepdir code on any empty directories in $D
> between src_install and pkg_preinst.

>   * Update the devmanual and portage documentation to suggest dodir
> instead of keepdir in the new EAPI.

>   * Change the PMS to remove "undefined behavior" and replace it with
> "empty directories must be tracked, and may only be removed once no
> installed package is using them," or something along those lines.
> That leaves the implementation up to the PM.

How? Look up VDB entries of all installed packages? Note that this
would have to be done for every dir that becomes empty, not just the
ones currently containing a .keep_* file.

What problem are you trying to solve? I see typically around 100
.keep_* files on my systems. These are empty files, so they don't use
any blocks. And 100 inodes system wide looks like negligible usage
of resources to me.

Ulrich


pgpqmVNueWrlc.pgp
Description: PGP signature

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michał Górny]

W dniu nie, 12.11.2017 o godzinie 07∶53 -0500, użytkownik Michael
Orlitzky napisał:
> On 11/11/2017 02:26 PM, Michał Górny wrote:
> > > 
> > > As far as the actual implementation goes, I'm not sure that
> > > automatically-generated ".keep" files are better than having the package
> > > manager maintain its own database. The latter would be more complex, but
> > > would avoid littering everyone's filesystems with ".keep" files.
> > 
> > Do you care enough to spec this properly, introduce EAPI-conditional
> > behavior for it and prepare patches for the package managers?
> > 
> 
> Some day -- I'll add it to my list. For now I'll update the docs to
> explain why you should use keepdir, and do a QA warning for empty
> directories.

I'm not convinced a QA warning is valid, given that not every empty
directory is meaningful. You're going to either cause people to create
unnecessary 'keepdir's, or to be swamped by false positives.

>  Then how does this sound for EAPI=next?
> 
>   * Ban keepdir.
> 
>   * Have portage call its keepdir code on any empty directories in $D
> between src_install and pkg_preinst.

How does this account for /run and other non-persistent locations?

>   * Update the devmanual and portage documentation to suggest dodir
> instead of keepdir in the new EAPI.
> 
>   * Change the PMS to remove "undefined behavior" and replace it with
> "empty directories must be tracked, and may only be removed once no
> installed package is using them," or something along those lines.
> That leaves the implementation up to the PM.

...and makes interoperability between different package managers
impossible, defeating the purpose of PMS in the first place.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/11/2017 02:26 PM, Michał Górny wrote:
>>
>> As far as the actual implementation goes, I'm not sure that
>> automatically-generated ".keep" files are better than having the package
>> manager maintain its own database. The latter would be more complex, but
>> would avoid littering everyone's filesystems with ".keep" files.
> 
> Do you care enough to spec this properly, introduce EAPI-conditional
> behavior for it and prepare patches for the package managers?
> 

Some day -- I'll add it to my list. For now I'll update the docs to
explain why you should use keepdir, and do a QA warning for empty
directories. Then how does this sound for EAPI=next?

  * Ban keepdir.

  * Have portage call its keepdir code on any empty directories in $D
between src_install and pkg_preinst.

  * Update the devmanual and portage documentation to suggest dodir
instead of keepdir in the new EAPI.

  * Change the PMS to remove "undefined behavior" and replace it with
"empty directories must be tracked, and may only be removed once no
installed package is using them," or something along those lines.
That leaves the implementation up to the PM.

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Brian Dolbec]

On Sat, 11 Nov 2017 12:31:15 -0500
Michael Orlitzky  wrote:


> Essentially,we have two commands to create a directory, "dodir" and
> "do-empty-dir" (which we call "keepdir"). The latter is only necessary
> due to an implementation detail, so it doesn't belong in the user
> interface -- the PM should figure out what to do.
> 
> As far as the actual implementation goes, I'm not sure that
> automatically-generated ".keep" files are better than having the
> package manager maintain its own database. The latter would be more
> complex, but would avoid littering everyone's filesystems with
> ".keep" files.
> 

Well, for:

1) using .keepdir files makes this package manager non-specific, ie:
using a different PM would mean it too sees that it is suppose to be
kept.

2) Most ebuilds don't need/or use .keepdir, so I doubt there are that
   many littering up your filesystem.

3) There already is a database of the files installed by a package.
   But, how does it know which other packages might need to install to
   that directory.  So, what does it do on unmerge of the package.
   Typically, the package manager will refuse to remove a non-empty
   directory after the files it is removing are removed.

4) Creating a single database for these will make the system more
   vulnerable to corruption and data loss.  It would save on disk usage
   and number of inodes used.  But there is a tradeoff between space and
   robustness.  If one .keepdir is lost, it may only affect a few
   packages.  If the database becomes corrupted.  It could potentially
   mean the loss of much more of your installed pkg data. Spanning a
   great deal of the installed pkgs.  In this case simplicity
   of .keepdir is in my opinion, much better than a single db.

-- 
Brian Dolbec 

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michał Górny]

W dniu sob, 11.11.2017 o godzinie 12∶31 -0500, użytkownik Michael
Orlitzky napisał:
> > > and a meta-question,
> > > 
> > >   c) Seriously, empty directories are undefined behavior?
> > 
> > ...and how could they be defined if a directory can be installed by
> > multiple packages and has no explicit ownership?
> 
> I see the problem, but the package manager knows which packages are
> using a given directory. (Portage does, and it is at least easy to
> record that information.)
> 
> Empty directories could be installed normally, and then during an
> unmerge, the package manager could check to see if the empty directory
> is used by any package. If it is, leave it -- if not, remove it. You
> might object that this would slow down the unmerge process, but a clever
> lookup scheme would let you map directory names to packages quickly.
> 
> In fact, such a lookup scheme is already implemented in the filesystem
> itself, leading me full circle to the following idea: if the package
> manager is about to install an empty directory, it could create the
> ".keep" file itself. Then "ls -a $dir" is your lookup function that
> determines whether or not a directory is in use by a package.

What about a directory that is installed empty by multiple different
packages, and non-empty by some other packages?

> Having the package manager handle empty directories solves two problems,
> 
>   1) Use of "keepdir" is inconsistent, because portage is happy to let
>  you create an empty directory without it (even though that
>  operation is illegal).

It is not. It is just not guaranteed to be meaningful.

> 
>   2) The build systems of many packages will create empty directories
>  during "make install", and it's unreasonable to expect developers
>  to "keepdir" them all.

Not all of those directories are really meaningful.

> Essentially,we have two commands to create a directory, "dodir" and
> "do-empty-dir" (which we call "keepdir"). The latter is only necessary
> due to an implementation detail, so it doesn't belong in the user
> interface -- the PM should figure out what to do.
> 
> As far as the actual implementation goes, I'm not sure that
> automatically-generated ".keep" files are better than having the package
> manager maintain its own database. The latter would be more complex, but
> would avoid littering everyone's filesystems with ".keep" files.

Do you care enough to spec this properly, introduce EAPI-conditional
behavior for it and prepare patches for the package managers?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/11/2017 02:58 AM, Michał Górny wrote:
>>
>> Certainly "keepdir" will make the directory non-empty, but with the
>> additional (unwanted) side-effect that the directory won't be removed
>> when the package is uninstalled.
> 
> Wrong. It creates a dotfile inside it, and removes it along with it.

Gotcha, I never tested my assumption that keepdir would keep the dir =P

FWIW, `man 5 ebuild` says keepdir "Tells portage to leave directories
behind..." It's not at all apparent that the "left behind" refers to the
unmerge of some other, unrelated, package.


>>   a) When would you want to use keepdir?
> 
> Because it works.

Makes sense now, thanks.



>> and a meta-question,
>>
>>   c) Seriously, empty directories are undefined behavior?
> 
> ...and how could they be defined if a directory can be installed by
> multiple packages and has no explicit ownership?

I see the problem, but the package manager knows which packages are
using a given directory. (Portage does, and it is at least easy to
record that information.)

Empty directories could be installed normally, and then during an
unmerge, the package manager could check to see if the empty directory
is used by any package. If it is, leave it -- if not, remove it. You
might object that this would slow down the unmerge process, but a clever
lookup scheme would let you map directory names to packages quickly.

In fact, such a lookup scheme is already implemented in the filesystem
itself, leading me full circle to the following idea: if the package
manager is about to install an empty directory, it could create the
".keep" file itself. Then "ls -a $dir" is your lookup function that
determines whether or not a directory is in use by a package.

Having the package manager handle empty directories solves two problems,

  1) Use of "keepdir" is inconsistent, because portage is happy to let
 you create an empty directory without it (even though that
 operation is illegal).

  2) The build systems of many packages will create empty directories
 during "make install", and it's unreasonable to expect developers
 to "keepdir" them all.

Essentially,we have two commands to create a directory, "dodir" and
"do-empty-dir" (which we call "keepdir"). The latter is only necessary
due to an implementation detail, so it doesn't belong in the user
interface -- the PM should figure out what to do.

As far as the actual implementation goes, I'm not sure that
automatically-generated ".keep" files are better than having the package
manager maintain its own database. The latter would be more complex, but
would avoid littering everyone's filesystems with ".keep" files.

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michał Górny]

W dniu pią, 10.11.2017 o godzinie 19∶21 -0500, użytkownik Michael
Orlitzky napisał:
> On 11/10/2017 04:36 PM, Damo Brisbane wrote:
> > 
> > Re for...keepdir, I found removing it then the /var/log/fabio folders
> > were not getting created, so keeping it in there.
> 
> You need to tell the ebuild to create that directory one way or another.
> The "dodir" function will create the directory, but without the ".keep"
> file inside of it. However that may be "illegal" in this case; see below.
> 
> 
> > http://www.calculate-linux.org/main/en/using_ebuild, says this of *keepdir*:
> > 
> > *Creates (if necessary) a |.keep| file in the given directory so that it
> > isn't auto-cleaned. Never create a |.keep| file yourself. If Portage
> > changes how |keepdir| works, then creating the file yourself will break
> > the package.*
> 
> To my knowledge, no package manager will remove a non-empty directory,
> nor will it remove anything that the package manager did not itself
> create. To me that raises a question: why would I ever want to keep
> around an (otherwise empty) directory that was created by the package
> manager?
> 
> I found this,
> 
>   https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-15100013.2.2
> 
> which states
> 
>   Behaviour upon encountering an empty directory is undefined. Ebuilds
>   must not attempt to install an empty directory.
> 
> Certainly "keepdir" will make the directory non-empty, but with the
> additional (unwanted) side-effect that the directory won't be removed
> when the package is uninstalled. Thus "keepdir" doesn't seem like it was
> intended to address that technicality. So, I have two questions now...

Wrong. It creates a dotfile inside it, and removes it along with it.

> 
>   a) When would you want to use keepdir?

Because it works.

> 
>   b) What's the right way to prevent a directory from being empty? Touch
>  a dummy file?

Use keepdir.

> 
> and a meta-question,
> 
>   c) Seriously, empty directories are undefined behavior?

...and how could they be defined if a directory can be installed by
multiple packages and has no explicit ownership?

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/10/2017 04:36 PM, Damo Brisbane wrote:
> 
> Re for...keepdir, I found removing it then the /var/log/fabio folders
> were not getting created, so keeping it in there.

You need to tell the ebuild to create that directory one way or another.
The "dodir" function will create the directory, but without the ".keep"
file inside of it. However that may be "illegal" in this case; see below.


> http://www.calculate-linux.org/main/en/using_ebuild, says this of *keepdir*:
> 
> *Creates (if necessary) a |.keep| file in the given directory so that it
> isn't auto-cleaned. Never create a |.keep| file yourself. If Portage
> changes how |keepdir| works, then creating the file yourself will break
> the package.*

To my knowledge, no package manager will remove a non-empty directory,
nor will it remove anything that the package manager did not itself
create. To me that raises a question: why would I ever want to keep
around an (otherwise empty) directory that was created by the package
manager?

I found this,

  https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-15100013.2.2

which states

  Behaviour upon encountering an empty directory is undefined. Ebuilds
  must not attempt to install an empty directory.

Certainly "keepdir" will make the directory non-empty, but with the
additional (unwanted) side-effect that the directory won't be removed
when the package is uninstalled. Thus "keepdir" doesn't seem like it was
intended to address that technicality. So, I have two questions now...

  a) When would you want to use keepdir?

  b) What's the right way to prevent a directory from being empty? Touch
 a dummy file?

and a meta-question,

  c) Seriously, empty directories are undefined behavior?

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Damo Brisbane]

Cheers Michael,

I've made most those changes, including USER/GROUP*, that confuses me too;
copied pattern from another ebuild. Also removed creating separate folder
/etc/fabio.d; re this, I noticed the fabio configuration accepts either
folder path or *URL* for configuration file; not sure how this works,
though it does seem to underlie some type of arbitrariness in including
such a /etc/fabio.d folder within this ebuild.

Re for...keepdir, I found removing it then the /var/log/fabio folders were
not getting created, so keeping it in there.

http://www.calculate-linux.org/main/en/using_ebuild, says this of *keepdir*:

*Creates (if necessary) a .keep file in the given directory so that it
isn't auto-cleaned. Never create a .keep file yourself. If Portage changes
how keepdir works, then creating the file yourself will break the package.*

regards,
Damon

On Fri, Nov 10, 2017 at 10:59 PM, Michael Orlitzky <m...@gentoo.org> wrote:

> On 11/09/2017 11:08 PM, Damo Brisbane wrote:
> > I've run up a couple of golang based ebuilds - for the fabio load
> > balancer. My first run at it, not completely sure of any follow up
> > process, mentor? other posting, overlap with existing work? Anyway,
> > would appreciate the feedback.
>
> Your $VERSION variable can probably be replaced with "${PV}" to save a
> line.
>
> Your init script takes care of the permissions on /var/lib/fabio and
> /var/log/fabio/fabio.log...
>
>   start_pre() {
> checkpath -q -d -o ${FABIO_USER}:${FABIO_GROUP} ${FABIO_HOMEDIR}
> checkpath -q -f -o ${FABIO_USER}:${FABIO_GROUP} ${FABIO_LOGFILE}
>   }
>
> so the following in the ebuild might be redundant?
>
>   for x in /var/{lib,log}/${PN}; do
> keepdir "${x}"
> fowners fabio:fabio "${x}"
>   done
>
> (warning: I have never understood what keepdir is supposed to
> accomplish, so maybe I'm wrong here).
>
> On the other hand, if you've created a dedicated user and group for the
> daemon, I don't think there's much benefit to letting the end user
> switch them via FABIO_USER and FABIO_GROUP (it just makes the
> permissions harder to get right). That's a judgment call though.
>
> Finally, if the stanza above *does* turn out to be redundant, then
> there's another small improvement that can be made. Since the "fabio"
> user and group are used nowhere else in the ebuild, you could create
> them in pkg_preinst() instead of pkg_setup(). Doing that has one main
> benefit -- namely that if the installation fails, the user and group
> won't be created.
>
> Overall, looks good.
>
> For testing help, you'll probably have the best luck in #gentoo-user on
> IRC. For ebuild reviews, we have a dedicated mailing list,
> gentoo-devh...@lists.gentoo.org and an associated IRC channel,
> #gentoo-dev-help (yes, they're hyphenated differently...)
>
>

Re: [gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Michael Orlitzky]

On 11/09/2017 11:08 PM, Damo Brisbane wrote:
> I've run up a couple of golang based ebuilds - for the fabio load
> balancer. My first run at it, not completely sure of any follow up
> process, mentor? other posting, overlap with existing work? Anyway,
> would appreciate the feedback.

Your $VERSION variable can probably be replaced with "${PV}" to save a line.

Your init script takes care of the permissions on /var/lib/fabio and
/var/log/fabio/fabio.log...

  start_pre() {
checkpath -q -d -o ${FABIO_USER}:${FABIO_GROUP} ${FABIO_HOMEDIR}
checkpath -q -f -o ${FABIO_USER}:${FABIO_GROUP} ${FABIO_LOGFILE}
  }

so the following in the ebuild might be redundant?

  for x in /var/{lib,log}/${PN}; do
keepdir "${x}"
fowners fabio:fabio "${x}"
  done

(warning: I have never understood what keepdir is supposed to
accomplish, so maybe I'm wrong here).

On the other hand, if you've created a dedicated user and group for the
daemon, I don't think there's much benefit to letting the end user
switch them via FABIO_USER and FABIO_GROUP (it just makes the
permissions harder to get right). That's a judgment call though.

Finally, if the stanza above *does* turn out to be redundant, then
there's another small improvement that can be made. Since the "fabio"
user and group are used nowhere else in the ebuild, you could create
them in pkg_preinst() instead of pkg_setup(). Doing that has one main
benefit -- namely that if the installation fails, the user and group
won't be created.

Overall, looks good.

For testing help, you'll probably have the best luck in #gentoo-user on
IRC. For ebuild reviews, we have a dedicated mailing list,
gentoo-devh...@lists.gentoo.org and an associated IRC channel,
#gentoo-dev-help (yes, they're hyphenated differently...)

[gentoo-dev] Help testing ebuilds? golang/Fabio load balancer

[Damo Brisbane]

I've run up a couple of golang based ebuilds - for the fabio load balancer.
My first run at it, not completely sure of any follow up process, mentor?
other posting, overlap with existing work? Anyway, would appreciate the
feedback.

FYI, custom overlay at * https://github.com/damobrisbane/damo-overlay *.

Tried to follow ?prior art? - but first run at it, probably dumb stuff in
there, of note:

* Followed "consul" ebuild for template, specifically adds users/openrc
init and confd files and logging. Not a systemd fan so please dont ask
unless you want to do it yourself..

* I think installs ok?:

>>> emerge -aq fabio

[ebuild  N] dev-go/govendor-1.0.9
[ebuild  N] dev-go/vendorfmt-
[ebuild  N] net-proxy/fabio-1.5.3

Would you like to merge these packages? [Yes/No] y

>>> Verifying ebuild manifests
>>> Emerging (1 of 3) dev-go/govendor-1.0.9::damo-overlay
>>> Installing (1 of 3) dev-go/govendor-1.0.9::damo-overlay
>>> Emerging (2 of 3) dev-go/vendorfmt-::damo-overlay
>>> Installing (2 of 3) dev-go/vendorfmt-::damo-overlay
>>> Emerging (3 of 3) net-proxy/fabio-1.5.3::damo-overlay
>>> Installing (3 of 3) net-proxy/fabio-1.5.3::damo-overlay
>>> Recording net-proxy/fabio in "world" favorites file...

>>>

Thanks in advance
Damon

Re: [gentoo-dev] Help maintaining dev-erlang and ejabberd

[R0b0t1]

On Tue, Aug 22, 2017 at 3:50 PM,   wrote:
> Hi,
>
> Some time ago I've made an effort to split ejabberd into proper
> dependencies handled by portage rather than repackaging bundle produced
> by rebar.  While I've found that easier to maintain, my lack of
> knowledge about Erlang makes maintenanace quite difficult. I'd
> appreciate if someone who actually has some experience in Erlang helps
> maintaining it.
>
> Kind regards,
>

Hello friend,

I would like to see Erlang receive continued maintenance and may be
able to help (note I am not as experienced as some). However this
would be my first time working with portage at such a level.

I apologize if my post is too forward for this list.

Regards,
 R0b0t1

[gentoo-dev] Help maintaining dev-erlang and ejabberd

[aidecoe]

Hi,

Some time ago I've made an effort to split ejabberd into proper
dependencies handled by portage rather than repackaging bundle produced
by rebar.  While I've found that easier to maintain, my lack of
knowledge about Erlang makes maintenanace quite difficult. I'd
appreciate if someone who actually has some experience in Erlang helps
maintaining it.

Kind regards,

-- 
Amadeusz Żołnowski


signature.asc
Description: PGP signature

Re: [gentoo-dev] Help wanted with www-client/chromium

[J. Roeleveld]

On December 14, 2016 2:40:45 PM GMT+01:00, Andrey Utkin 
 wrote:
>On Tue, Dec 13, 2016 at 06:00:25PM -0500, Mike Gilbert wrote:
>> Keeping up with the frequent Chromium releases is quite a chore.
>> Recently, phajdan.jr has been slacking on the masked dev channel
>> updates due a hardware problem, so I have been spending additional
>> time on them.
>> 
>> If there are any developers with relatively fast hardware that could
>> take on the stable and/or beta channel updates, that would be most
>> appreciated. This is also something that could be done by a trusted
>> user.
>> 
>> Help with the masked dev channel is also welcome -- especially
>testing
>> the various USE flags and unbundling libraries.
>
>Have reasonably powerful amd64 hardware, can try nightly runs.
>
>Not an affiliated gentoo developer.
>
>I guess it would be best to make up collectively a tiny git repo with
>scripts which do exactly what is needed?
>
>First of all it could be a set of chromium builds with different use
>flags (a set of such configurations needs to be defined), saved as
>binary packages, so that all the builds could be tested at once by
>unpacking every build, in turn. All build logs must be saved for
>review,
>and failures should be reported. Makes sense? Ideas? Comments?

I could run this automatically evey night.
Inside a set of different chroots which sync against the tree then try to 
install and package the latest ~amd64 version with a USE combination set per 
chroot.

The resulting build logs can be emailed automatically and binary packages 
uploaded to a specified location. I also have reasonably fast hardware 
available.

If similar activities would be useful for other packages. That should be 
possible as well.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Help wanted with www-client/chromium

[Andrey Utkin]

On Tue, Dec 13, 2016 at 06:00:25PM -0500, Mike Gilbert wrote:
> Keeping up with the frequent Chromium releases is quite a chore.
> Recently, phajdan.jr has been slacking on the masked dev channel
> updates due a hardware problem, so I have been spending additional
> time on them.
> 
> If there are any developers with relatively fast hardware that could
> take on the stable and/or beta channel updates, that would be most
> appreciated. This is also something that could be done by a trusted
> user.
> 
> Help with the masked dev channel is also welcome -- especially testing
> the various USE flags and unbundling libraries.

Have reasonably powerful amd64 hardware, can try nightly runs.

Not an affiliated gentoo developer.

I guess it would be best to make up collectively a tiny git repo with
scripts which do exactly what is needed?

First of all it could be a set of chromium builds with different use
flags (a set of such configurations needs to be defined), saved as
binary packages, so that all the builds could be tested at once by
unpacking every build, in turn. All build logs must be saved for review,
and failures should be reported. Makes sense? Ideas? Comments?

Re: [gentoo-dev] Help wanted with www-client/chromium

[J. Roeleveld]

On Tuesday, December 13, 2016 06:00:25 PM Mike Gilbert wrote:
> Keeping up with the frequent Chromium releases is quite a chore.
> Recently, phajdan.jr has been slacking on the masked dev channel
> updates due a hardware problem, so I have been spending additional
> time on them.
> 
> If there are any developers with relatively fast hardware that could
> take on the stable and/or beta channel updates, that would be most
> appreciated. This is also something that could be done by a trusted
> user.
> 
> Help with the masked dev channel is also welcome -- especially testing
> the various USE flags and unbundling libraries.

I don't use chromium often, but if it's simply bumping the ebuild and testing 
if it builds and runs, then that is something I can help with.
If there also is a quick method to check if the browser actually renders pages 
correctly (a few test-sites) then that can be added to the test-cycle.

Please contact me off-list if this is sufficient.

--
Joost

[gentoo-dev] Help wanted with www-client/chromium

[Mike Gilbert]

Keeping up with the frequent Chromium releases is quite a chore.
Recently, phajdan.jr has been slacking on the masked dev channel
updates due a hardware problem, so I have been spending additional
time on them.

If there are any developers with relatively fast hardware that could
take on the stable and/or beta channel updates, that would be most
appreciated. This is also something that could be done by a trusted
user.

Help with the masked dev channel is also welcome -- especially testing
the various USE flags and unbundling libraries.

Re: [gentoo-dev] help needed: net-irc/weechat

[Tim Harder]

On 2014-11-12 06:31, Andreas K. Huettel wrote:
 [Sending this out for scarabeus since the gmail conspiracy is keeping him 
 from 
 posting to the -dev mailing list...]

 Hello people,

 I stopped using weechat and it is slowly piling bugs, so if someone wants to 
 take over, it would be lovely.

 net-irc/weechat

Since nothing appeared to be happening in this case, I took it over. As
usual anyone should feel free to help out if they're interested.

Thanks,
Tim


pgp0XEHP_KsAO.pgp
Description: PGP signature

[gentoo-dev] help needed: net-irc/weechat

[Andreas K. Huettel]

[Sending this out for scarabeus since the gmail conspiracy is keeping him from 
posting to the -dev mailing list...]


Hello people,

I stopped using weechat and it is slowly piling bugs, so if someone wants to 
take over, it would be lovely.

net-irc/weechat

Thanks

Tom

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

Re: [gentoo-dev] help needed: net-irc/weechat

[Alice Ferrazzi]

i use weechat everyday :)
glad to help

On Wed, Nov 12, 2014 at 8:31 PM, Andreas K. Huettel
dilfri...@gentoo.org wrote:
 [Sending this out for scarabeus since the gmail conspiracy is keeping him from
 posting to the -dev mailing list...]


 Hello people,

 I stopped using weechat and it is slowly piling bugs, so if someone wants to
 take over, it would be lovely.

 net-irc/weechat

 Thanks

 Tom

 --
 Andreas K. Huettel
 Gentoo Linux developer
 kde, council





-- 
アリス フェッラッシィ
Alice Ferrazzi

Gentoo,  If it moves, compile it!
My_overlay: https://github.com/aliceinwire/overlay
Gentoo Euscan: http://goo.gl/JUVyTN
Mail: Alice Ferrazzi alice.ferra...@gmail.com
PGP: 0EE4 555E 3AAC B4A4 798D 9AC5 8E31 1808 C553 2D33

Re: [gentoo-dev] help needed: net-irc/weechat

[Tomáš Chvátal]

2014-11-12 12:39 GMT+01:00 Alice Ferrazzi alice.ferra...@gmail.com:

 i use weechat everyday :)
 glad to help

 Great, just take look on the bugs, and sent me patches.
I shall gladly include them in cvs :)

Tom

[gentoo-dev] help on lxqt

[Michael Vetter]

Hello there,

Last night I decided to join the LXQT project.

So I was checking our their their repo: git clone
http://github.com/lxde/lxqt ~/src/lxqt

Cretaed a build directory in there and ran cmake.

It appeared that my version of liblxqt(0.8.0) was too old and I needed
the current one from git. So I added the Gentoo Qt overlay and installed
that version.

However when running CMake I get:
$ cmake ..
-- The C compiler identification is GNU 4.8.2
-- The CXX compiler identification is GNU 4.8.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at compton-conf/CMakeLists.txt:11 (include):
  include could not find load file:

LXQtTranslateTs


CMake Error at compton-conf/CMakeLists.txt:12 (include):
  include could not find load file:

LXQtTranslateDesktop


-- Looking for Q_WS_X11
-- Looking for Q_WS_X11 - found
-- Looking for Q_WS_WIN
-- Looking for Q_WS_WIN - not found
-- Looking for Q_WS_QWS
-- Looking for Q_WS_QWS - not found
-- Looking for Q_WS_MAC
-- Looking for Q_WS_MAC - not found
-- Found Qt4: /usr/bin/qmake (found version 4.8.5)
-- Building with Qt4.8.5
-- Found PkgConfig: /usr/bin/pkg-config (found version 0.28)
-- checking for module 'libconfig'
--   found libconfig, version 1.4.9
CMake Error at compton-conf/CMakeLists.txt:74 (lxqt_translate_ts):
  Unknown CMake command lxqt_translate_ts.

It seems like LXQtTranslateTs (which is supposed to be in git version of
liblxqt) didn't get installed.

To check if that was correct I ran equery f liblxqt which showed
(among others):

/usr/share/cmake/lxqt-qt5/modules/LXQtTranslate.cmake
/usr/share/cmake/lxqt-qt5/modules/LXQtTranslateDesktop.cmake
/usr/share/cmake/lxqt-qt5/modules/LXQtTranslateTs.cmake
/usr/share/cmake/lxqt-qt5/modules/LXQtTranslationLoader.cmake

Now I have no idea what to do and why this error persists. I also
contacted the LXDE guys, but they said they have no idea as this might
be Gentoo specific.

Maybe I should also add that the newest version of lxqt only supports
Qt5, which is why I unmasked it in /etc/portage/profiles/base/use.mask
and added it to global USE flags.

I hope somebody can help me with this.

regards,
Michael

[gentoo-dev] Help with EAPI bumps

[Chris Reffett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,
It's been a QA team objective for some time to help get rid of older
EAPI ebuilds in-tree. I personally will be spending some time in the
next couple weeks working on this, but I we on the QA team would
appreciate it if the developer community in general could contribute,
especially with packages that are either maintainer-needed or in herds
which have low activity. To play things safe, please revbump and file
stable requests when doing the EAPI change (rather than directly
bumping EAPI). Thanks in advance for the help!

Chris Reffett
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPhekUACgkQ23laikJhg1Q12ACfZgY5sei2KvpBbimA5QTaT85K
etIAnA1AbRs2AsrqFKiaVWgvtxAERaxe
=chii
-END PGP SIGNATURE-

[gentoo-dev] Help needed with ebuilds for pear.horde.org

[J. Roeleveld]

Hi All,

I am trying to create an ebuild for Egroupware 14.1. (released this month)

To find out the dependencies, I am going through the setup check and am stuck 
with the following:
**
Checking PEAR pear.horde.org/Horde_Imap_Client (2.16.0) is installed: False
PEAR::Horde_Imap_Client is needed by: EMailAdmin. You can install it by 
running: pear channel-discover pear.horde.org ; pear install 
pear.horde.org/Horde_Imap_Client
**

If I run those commands, it works, however, I prefer to use ebuilds for the 
dependencies.
I tried to create some based on existing ebuilds from the kolab overlay (they 
also use the pear.horde.org channel), but even though the install seems to 
work, it still isn't found.

I also tried to adjust an existing PEAR ebuild to:
**
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit php-pear-r1

LICENSE=LGPL-3
SLOT=0
KEYWORDS=amd64
PHP_PEAR_CHANNEL=pear.horde.org
SRC_URI=http://pear.horde.org/get/${PEAR_PN}.tgz;
DEPEND=dev-php/PEAR-Horde_Channel
**

But I am unable to properly change the PEAR-channel.

I am certain I am missing something simple, but my google-fu is coming short.

If anyone is able to point me in the right direction, I would be very 
grateful.

--
Joost Roeleveld

[gentoo-dev] help

[slepnoga]

-- 
andrei vinogradov

[gentoo-dev] Help needed on maintaining media-gfx/k3d

[Pacho Ramos]

media-gfx/k3d is not buildable for a long time in the tree due boost
update (also in stable), it also has some important pending bugs:
https://bugs.gentoo.org/buglist.cgi?quicksearch=k3dlist_id=2093406

Is anyone interested on it to try to solve some of the most important
bugs?

Thanks a lot

[gentoo-dev] Help on adapting cman init scripts to kernels with things built in instead of modules

[Pacho Ramos]

Hello

Looks like cman stabilization (that is needed to stabilize newer lvm2,
that is needed to stabilize newer udev...) is blocked by its init.d
script wanting to load modules even on kernels without modules:
https://bugs.gentoo.org/show_bug.cgi?id=442512#c5

Arch team people think that this should be handled before but... how
should it be handled? Do you know about some similar case that I could
look for possible solutions to it?

Thanks a lot for your help


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

Re: [gentoo-dev] Help on adapting cman init scripts to kernels with things built in instead of modules

[Tony Chainsaw Vroon]

On Sun, 2012-12-02 at 23:10 +0100, Pacho Ramos wrote:
 Arch team people think that this should be handled before but... how
 should it be handled? 

I agree with the arch teams here. You can do something as mundane as:
if [ -e /proc/modules ]; then
COMPLICATED MODULE MADNESS
fi

Regards,
Tony V.


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

Re: [gentoo-dev] Help on adapting cman init scripts to kernels with things built in instead of modules

[Peter Stuge]

Pacho Ramos wrote:
 Looks like cman stabilization (that is needed to stabilize newer lvm2,
 that is needed to stabilize newer udev...) is blocked by its init.d
 script wanting to load modules even on kernels without modules:
 https://bugs.gentoo.org/show_bug.cgi?id=442512#c5
 
 Arch team people think that this should be handled before but... how
 should it be handled? Do you know about some similar case that I could
 look for possible solutions to it?

Don't know about similar cases.

Anyway, the init script seems to only have one real problem; it tries
to unconditionally load dlm as a module.

If configfs has been compiled-in, no module will be loaded.
If configfs has been mounted, the script doesn't try to mount it.

I don't know what the dlm module does, but the init script would have
to probe for it at runtime and only try to load a module when the
module isn't already available.

Of course it might be nice to also add some nicer error messages to
the init script. And probably there should be some pkg_postinst (or?)
einfo about how cman requires certain things enabled in the kernel.

There are several of those in the tree to look at for inspiration.


//Peter


pgpjJB27SHnf8.pgp
Description: PGP signature

[gentoo-dev] Help required with getting new media-gfx/graphviz in tree.

[Samuli Suominen]

We are behind with graphviz and 2.28.x series has been out for quite a 
while.


However working on the ebuild will require quite a work and then 
backtracking the bugs that come after it as a result (believe me, there 
will be ones)


It seems graphics@ is currently a bit understaffed and I really don't 
see anyone working on this anytime soon without sending this mail.


Thanks ahead

- Samuli

Re: [gentoo-dev] Help on getting media-libs/svgalib fixed

[Michael Sterrett]

Maybe it's time to just punt svgalib?  There are only 46 ebuilds that
use it (some, optionally).

On Sun, Feb 19, 2012 at 6:30 AM, Pacho Ramos pa...@gentoo.org wrote:
 Hello

 You can see current opened bugs for svgalib here:
 https://bugs.gentoo.org/buglist.cgi?quicksearch=media-libs%
 2Fsvgalib;list_id=812773

 Most of them already contain a patch that is supposed to fix each bug
 report, the problem is that svgalib doesn't build at all on amd64 and,
 then, would be interesting if anybody with a x86 system could check if
 patches fix the problems and commit them.

 Thanks a lot :-)

Re: [gentoo-dev] Help on getting media-libs/svgalib fixed

[Pacho Ramos]

El lun, 20-02-2012 a las 13:09 -0500, Michael Sterrett escribió:
 Maybe it's time to just punt svgalib?  There are only 46 ebuilds that
 use it (some, optionally).
 
 On Sun, Feb 19, 2012 at 6:30 AM, Pacho Ramos pa...@gentoo.org wrote:
  Hello
 
  You can see current opened bugs for svgalib here:
  https://bugs.gentoo.org/buglist.cgi?quicksearch=media-libs%
  2Fsvgalib;list_id=812773
 
  Most of them already contain a patch that is supposed to fix each bug
  report, the problem is that svgalib doesn't build at all on amd64 and,
  then, would be interesting if anybody with a x86 system could check if
  patches fix the problems and commit them.
 
  Thanks a lot :-)
 
 

The problem is that users CCed on their bug reports have provided
patches and fixes for them and would probably get angry if we punt them
without even applying the patches to the tree (but I don't want to
commit them as I cannot even test them at build time due being x86
specific). 

Also, looks like upstream is dead, but some distributions are still
providing it :-/


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

Re: [gentoo-dev] Help on getting media-libs/svgalib fixed

[Rich Freeman]

On Mon, Feb 20, 2012 at 2:38 PM, Pacho Ramos pa...@gentoo.org wrote:
 The problem is that users CCed on their bug reports have provided
 patches and fixes for them and would probably get angry if we punt them
 without even applying the patches to the tree (but I don't want to
 commit them as I cannot even test them at build time due being x86
 specific).

It seems to me that the package still needs a maintainer.  That could
be a developer, or a proxy-maintainer if one of those users wants to
commit to tending it.  If nobody wants to step up, and the package is
buggy, then treecleaning is the only recourse.

Rich

[gentoo-dev] Help on getting media-libs/svgalib fixed

[Pacho Ramos]

Hello

You can see current opened bugs for svgalib here:
https://bugs.gentoo.org/buglist.cgi?quicksearch=media-libs%
2Fsvgalib;list_id=812773

Most of them already contain a patch that is supposed to fix each bug
report, the problem is that svgalib doesn't build at all on amd64 and,
then, would be interesting if anybody with a x86 system could check if
patches fix the problems and commit them.

Thanks a lot :-)


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

Re: [gentoo-dev] Help on f-spot-0.8 problem

[Peter Volkov]

Hi, Pacho.

В Птн, 01/10/2010 в 20:14 +0200, Pacho Ramos пишет:
 Since Calchan doesn't have much time for f-spot and dotnet team is 
 conformed basically by me, I would welcome any help for trying to
 bump f-spot to its 0.8 version. The problem is that eautoreconf doesn't
 run, even running autoreconf on unpacked upstream sources fails with
 the following error:
 $ autoreconf
 /usr/share/aclocal/sigc++.m4:8: warning: underquoted definition of
 AM_PATH_SIGC
 /usr/share/aclocal/sigc++.m4:8:   run info '(automake)Extending aclocal'
 /usr/share/aclocal/sigc++.m4:8:   or see
 http://sources.redhat.com/automake/automake.html#Extending-aclocal
 help/Makefile.am:1: HAVE_GNOME_DOC_UTILS does not appear in
 AM_CONDITIONAL

$ cd f-spot-0.8.0
$ grep -r HAVE_GNOME_DOC_UTILS . | grep m4

will help you to see that this conditional is defined
in  ./build/m4/shamrock/gnome-doc.m4.

 build/build.rules.mk:37: ENABLE_ATK does not appear in AM_CONDITIONAL

this on is defined in ./build/m4/f-spot/gtk-sharp.m4. This problem can
be fixed with correct include pathes:

autoreconf -f -I build/m4/shamrock/ -I build/m4/f-spot/

thus I think

AT_M4DIR=-I build/m4/shamrock/ -I build/m4/f-spot/ eautoreconf

should work.

 I have already installed app-text/gnome-doc-utils-0.20.1, I have also 
 verified /usr/share/gnome-doc-utils/gnome-doc-utils.make is the same as
 f-spot provided one, and that sources doesn't seem to be shipping any 
 gnome-doc-utils.m4 file
 
 Thanks a lot for your help and ideas :-)

Thank you for taking care about this package! I really appreciate f-spot
version bump :)

-- 
Peter.

[gentoo-dev] Help on f-spot-0.8 problem

[Pacho Ramos]

Hello

Since Calchan doesn't have much time for f-spot and dotnet team is 
conformed basically by me, I would welcome any help for trying to
bump f-spot to its 0.8 version. The problem is that eautoreconf doesn't
run, even running autoreconf on unpacked upstream sources fails with
the following error:
$ autoreconf
/usr/share/aclocal/sigc++.m4:8: warning: underquoted definition of
AM_PATH_SIGC
/usr/share/aclocal/sigc++.m4:8:   run info '(automake)Extending aclocal'
/usr/share/aclocal/sigc++.m4:8:   or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
help/Makefile.am:1: HAVE_GNOME_DOC_UTILS does not appear in
AM_CONDITIONAL
gnome-doc-utils.make:63: HAVE_GNOME_DOC_UTILS does not appear in
AM_CONDITIONAL
help/Makefile.am:2:   `gnome-doc-utils.make' included from here
gnome-doc-utils.make:143: ENABLE_SK does not appear in AM_CONDITIONAL
help/Makefile.am:2:   `gnome-doc-utils.make' included from here
gnome-doc-utils.make:192: ENABLE_SK does not appear in AM_CONDITIONAL
help/Makefile.am:2:   `gnome-doc-utils.make' included from here
build/build.rules.mk:32: ENABLE_TESTS does not appear in AM_CONDITIONAL
lib/Hyena/Hyena.Data.Sqlite/Makefile.am:29:   `build/build.mk' included
from
here
build/build.mk:2:   `build/build.rules.mk' included from here
build/build.rules.mk:37: ENABLE_ATK does not appear in AM_CONDITIONAL
lib/Hyena/Hyena.Data.Sqlite/Makefile.am:29:   `build/build.mk' included
from
here
build/build.mk:2:   `build/build.rules.mk' included from here
build/build.rules.mk:32: ENABLE_TESTS does not appear in AM_CONDITIONAL
lib/Hyena/Hyena.Gui/Makefile.am:121:   `build/build.mk' included from
here
build/build.mk:2:   `build/build.rules.mk' included from here
build/build.rules.mk:37: ENABLE_ATK does not appear in AM_CONDITIONAL
lib/Hyena/Hyena.Gui/Makefile.am:121:   `build/build.mk' included from
here
build/build.mk:2:   `build/build.rules.mk' included from here
...

I have already installed app-text/gnome-doc-utils-0.20.1, I have also 
verified /usr/share/gnome-doc-utils/gnome-doc-utils.make is the same as
f-spot provided one, and that sources doesn't seem to be shipping any 
gnome-doc-utils.m4 file

Thanks a lot for your help and ideas :-)



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

[gentoo-dev] Help: How to handle multi svn sources

[Dennis.Yxun]

HI Folks:
I'm not a ebuild guru, so I ask here directly.
Here I'm trying to update kicad package to support live svn repos.
But the problem I face here is, kicad seperate different sources base on
different USE flags
   I slightly modified the ebuild files, but it simply doesn't work.
   Any suggestion or advice, really appreciate!

  Following is offended code, attached file is the ebuild file:

ESVN_REPO_URI=https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad
!minimal? (
https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad-library )
doc? ( https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad-doc)

Dennis


kicad-.ebuild
Description: Binary data

Re: [gentoo-dev] Help: How to handle multi svn sources

[Zac Medico]

Dennis.Yxun wrote:
 HI Folks:
 I'm not a ebuild guru, so I ask here directly.
 Here I'm trying to update kicad package to support live svn repos.
 But the problem I face here is, kicad seperate different sources base on
 different USE flags
I slightly modified the ebuild files, but it simply doesn't work.
Any suggestion or advice, really appreciate!
 
   Following is offended code, attached file is the ebuild file:
 
 ESVN_REPO_URI=https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad
 !minimal? (
 https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad-library )
 doc? (
 https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad-doc )
 
 Dennis

You can't embed USE conditionals inside ESVN_REPO_URI, since USE
conditionals like those are only supported in specific variables:
*DEPEND, RESTRICT, SRC_URI, PROPERTIES, and PROVIDE.

A brief examination of the subversion_fetch() function inside
/usr/portage/eclass/subversion.eclass suggests that ESVN_REPO_URI is
expected to be single-valued. So, I suspect that you will want to
define your own src_unpack() function (overriding
subversion_src_unpack) which will call subversion_fetch() as many
times as necessary. See the attached code for example.
-- 
Thanks,
Zac
src_unpack() {
subversion_fetch 
https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad
use minimal || subversion_fetch 
https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad-library
use doc  subversion_fetch 
https://kicad.svn.sourceforge.net/svnroot/kicad/trunk/kicad-doc
}

Re: [gentoo-dev] Help offered - Portage tree

[Luca Barbato]

Robin H. Johnson wrote:

- What I am asking Gentoo Foundation is, let me fix them
Apply to be a developer, then you can fix them. I don't personally have
any opinion (positive or negative) about Sabayon, but a former coworker
of mine was a big fan.


Addendum, the Foundation cannot do anything about that.

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Luca Barbato]

Natanael Copa wrote:

IIRC thread starter complained about too many wrong RDEPEND.


No, the thread started with an attitude problem, still unsolved btw.


Problem is not that devs are not willing to fix. Problem is that its to
easy to inject wrong RDEPEND in the tree in the first place and only way
to get it out from there is to wait for someone to report it. Since
many/most devs dont use binpkgs its expected that errors in RDEPEND are
there.


That could/will be solved with tinderbox checking or other means of 
automated checks. We need your help since we don't have enough resources 
to do that by ourselves.



Might be i have ideas how to fix but I need to gain some experience with
repoman before I present those.


Thank you for your offer, I'm looking forward to heard back from you =)

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Jan Kundrát]

Natanael Copa wrote:
So since I build a distro where size does matter (uclibc) I realised 
that even if I submit bugs for broken RDEPEND, there will never be an 
end to those bug reports. Looking at this thread, it seems i was right.


I wonder what you are looking at :(. You've been told by multiple 
developers that we do care about dep correctness and are willing to fix 
bugs when we hear about them.


Cheers,
-jkt

--
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Help offered - Portage tree

[Natanael Copa]

On Fri, 2008-03-14 at 10:09 +0100, Jan Kundrát wrote:
 Natanael Copa wrote:
  So since I build a distro where size does matter (uclibc) I realised 
  that even if I submit bugs for broken RDEPEND, there will never be an 
  end to those bug reports. Looking at this thread, it seems i was right.
 
 I wonder what you are looking at :(. 

IIRC thread starter complained about too many wrong RDEPEND.

 You've been told by multiple 
 developers that we do care about dep correctness and are willing to fix 
 bugs when we hear about them.

Problem is not that devs are not willing to fix. Problem is that its to
easy to inject wrong RDEPEND in the tree in the first place and only way
to get it out from there is to wait for someone to report it. Since
many/most devs dont use binpkgs its expected that errors in RDEPEND are
there.

Might be i have ideas how to fix but I need to gain some experience with
repoman before I present those.

-nc

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Denis Dupeyron]

On Thu, Mar 13, 2008 at 12:35 AM, Fabio Erculiani
[EMAIL PROTECTED] wrote:
  After having discussed with one of your dev about it, he suggested me
  to ask here looking for a mentor. If there's anything I can do, I'm
  ready.

On Thu, Mar 13, 2008 at 12:57 AM, Fabio Erculiani
[EMAIL PROTECTED] wrote:
  I know what you mean, but take into account I don't have much time
  left for the reporting. What I ask is [...]  getting me able to fix stuff

So you don't have time to file bugs but you would have time to fix
them ? Interesting...

In any case, we require users to have a consistent history of helping
the project before they are considered for recruitment. What you are
doing for Sabayon is great but it can't be taken into account. Please
find below some information that may be useful to get you started.

There are many ways you can help. Two good ways to start helping out
are proposing solutions for bugs [1] and contributing to an overlay
[2] like Sunrise for example [3]. There is more information on how to
get involved with overlay development at [4]. When your contributions
become significant enough, developers may contact you (or you can
contact them). You may also want to have a look at the staffing needs
page [5].

You will need to read the Gentoo Documentation Resources [6], and more
specifically the Gentoo Developer Handbook [7] and the Gentoo
Development Guide [8].

Another way to help, especially for non-technical projects, is to
contact people directly [9]. Be aware that they can be away though, so
be patient, try others on the same project, and finally get back to us
in case you fail to reach anybody.

Do not hesitate to contact recruiters in the future in case you need
more information.

Best regards,
Denis.

[1] http://bugs.gentoo.org/
[2] http://overlays.gentoo.org/
[3] http://overlays.gentoo.org/proj/sunrise/
[4] http://www.gentoo.org/proj/en/overlays/userguide.xml#doc_chap3
[5] http://www.gentoo.org/proj/en/devrel/staffing-needs/
[6] http://www.gentoo.org/doc/en/index.xml?catid=gentoodev
[7] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
[8] http://devmanual.gentoo.org/
[9] http://www.gentoo.org/proj/en/index.xml?showlevel=2
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Thilo Bangert]

 end up copying the ebuild from the tree into our overlay and fix.

great! where is it? does it have a webvc or trac interface?
thanks

Thilo




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

Re: [gentoo-dev] Help offered - Portage tree

[Fabio Erculiani]

media-libs/x264-svn - dev-lang/yasm
dev-libs/lzo - dev-lang/nasm
sys-apps/attr - sys-devel/autoconf
x11-libs/qt:3 (I reported it a while ago and it got fixed, it was a real mess)
net-dialup/capisuite - sys-devel/autoconf
dev-libs/xmlsec - sys-devel/autoconf
x11-misc/fluxbg - sys-devel/autoconf
media-video/effectv - dev-lang/nasm
net-voip/linphone - dev-lang/nasm
media-sound/gogo - dev-lang/nasm
sys-boot/lilo - sys-devel/bin86
app-text/iso-codes - sys-devel/automake

These depend on sys-devel/bison, are they correct?
app-office/mdbtools-0.6_pre1-r1
www-servers/boa-0.94.14_rc21
media-video/sswf-1.8.0-r1
net-firewall/itval-1.0
app-office/openoffice-2.3.1-r1
sci-geosciences/grass-6.0.1
sci-geosciences/grass-6.2.1
media-gfx/gliv-1.9.6

These depend on sys-devel/make
sci-geosciences/grass-6.0.1
sci-geosciences/grass-6.2.1

These depend on sys-devel/gcc (remember, only RDEPENDs here)
app-text/pdftk-1.41
net-irc/inspircd-1.1.14
app-benchmarks/piozone-1.0-r2
sci-chemistry/xdrawchem-1.9.9
sci-geosciences/grass-6.0.1
dev-lang/mono-1.2.6-r1
sci-geosciences/grass-6.2.1
www-apache/anyterm-1.1.16
dev-lang/ghc-6.8.2
sci-libs/hdf5-1.6.6

x11-proto/xineramaproto:
gnome-extra/gnome-screensaver-2.18.2-r1
media-video/ogle-0.9.2-r1

sabayon server # python reagent database query depends --quiet
x11-proto/printproto
x11-libs/libXp-1.0.0
app-editors/nvu-1.0-r4
x11-libs/openmotif-2.3.0
x11-libs/openmotif-2.2.3-r9

sabayon server # python reagent database query depends --quiet x11-proto/xproto
x11-libs/libXevie-1.0.2
x11-libs/libXdmcp-1.0.2
x11-plugins/asclock-2.0.12-r1
dev-libs/libstroke-0.5.1
sys-devel/gcc-3.4.6-r2
x11-libs/libXv-1.0.3
sys-devel/gcc-4.2.2
x11-libs/libXcomposite-0.4.0
x11-plugins/wmmixer-2.0_beta4-r1
x11-plugins/fsviewer-0.2.5
net-www/gnash-0.8.1-r1
x11-libs/libSM-1.0.3
dev-lang/ocaml-3.10.1
x11-libs/libXt-1.0.5
x11-libs/libXaw-1.0.4
x11-libs/libXcursor-1.1.9
gnome-base/nautilus-2.20.0-r1
media-gfx/gifsicle-1.44
x11-libs/xforms-1.0.90-r1
x11-libs/dnd-1.1-r1
x11-libs/libICE-1.0.4
x11-libs/libXft-2.1.12-r90
x11-terms/eterm-0.9.4
media-gfx/tgif-4.1.45
x11-libs/libFS-1.0.0
x11-libs/libXdamage-1.1.1
x11-libs/libXres-1.0.3
x11-libs/libXrandr-1.2.2
x11-libs/libXfont-1.3.1-r1
x11-libs/libXrender-0.9.4
x11-libs/libXau-1.0.3
app-editors/xvile-9.4d-r1
x11-libs/libast-0.7
media-plugins/vdr-xineliboutput-1.0.0_rc2_p20080120
x11-libs/libXvMC-1.0.4
x11-libs/libxsettings-client-0.10
net-dialup/isdn4k-utils-3.11_pre20071003
x11-libs/libX11-1.1.3
x11-libs/libXmu-1.0.3
x11-misc/slim-1.3.0-r1
net-mail/gnubiff-2.2.5
x11-libs/libXfixes-4.0.3
sci-mathematics/snns-4.2-r7

^^^ do they need x11-proto/xproto as RDEPEND?

My time on it for today is over. I'm busy preparing a release, sorry.
Probably some of them are ok, but I don't think all.
Using http://packages.sabayonlinux.org interface you can query all our bins.

-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Robin H. Johnson]

On Thu, Mar 13, 2008 at 10:24:23AM +0100, Fabio Erculiani wrote:
 media-libs/x264-svn - dev-lang/yasm
 dev-libs/lzo - dev-lang/nasm
I responded to you on IRC about these two, please see my message there,
as from everything I can see, the DEPs are actually correct.
(The config.log for lzo-1 indicates other reasons that it isn't using
nasm, which should probably get fixed for both x86 and amd64).

 sys-apps/attr - sys-devel/autoconf
autoconf is in the DEPEND already.
Do you want it not there?

Not reviewing the rest right now, I'm going to bed instead (03h26 here).

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpPnlmirUp7Z.pgp
Description: PGP signature

Re: [gentoo-dev] Help offered - Portage tree

[Fabio Erculiani]

Hi Robin,
first of all.
What I need is _basic_ respect on #gentoo-dev
You here seem all polite, but there you like playing me.
This is not a good start.

On 3/13/08, Robin H. Johnson [EMAIL PROTECTED] wrote:
 On Thu, Mar 13, 2008 at 10:24:23AM +0100, Fabio Erculiani wrote:
   media-libs/x264-svn - dev-lang/yasm
   dev-libs/lzo - dev-lang/nasm

 I responded to you on IRC about these two, please see my message there,
  as from everything I can see, the DEPs are actually correct.
  (The config.log for lzo-1 indicates other reasons that it isn't using
  nasm, which should probably get fixed for both x86 and amd64).


   sys-apps/attr - sys-devel/autoconf

 autoconf is in the DEPEND already.
  Do you want it not there?

  Not reviewing the rest right now, I'm going to bed instead (03h26 here).


  --
  Robin Hugh Johnson
  Gentoo Linux Developer  Infra Guy
  E-Mail : [EMAIL PROTECTED]
  GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85




-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Fabio Erculiani]

[02:31] Halcy0n lxnay: we offer all of our work that you base your
distribution off, and you don't contribute back at all, in any way.

^^ This is a really stupid sentence. It seems some of you don't even
realize how many users we brought to Gentoo, and this is really sad.
You see, people like Halcy0n, agaffney, zlin keep us away from
interacting with you. What we do is just trying to do our best, on the
desktop, aggregating new technologies and bringing them to users.
If you want to stop bad press, you (all) should firstly become more
gentle with users and external contributors. I am not talking to you
directly Robin, but to whom are quite annoying and provocative. I know
that the majority of you have been always kind, but I will never hang
on #gentoo-dev anymore just to be played around giving me voice until
I annoy someone with my POV. This is not a democratic way, let's talk
publicly here, without hiding in a development channel, we probably
get more visibility, don't we?

I will review your stuff on lzo probably tomorrow, hope won't be a problem.

On 3/13/08, Fabio Erculiani [EMAIL PROTECTED] wrote:
 Hi Robin,
  first of all.
  What I need is _basic_ respect on #gentoo-dev
  You here seem all polite, but there you like playing me.
  This is not a good start.


  On 3/13/08, Robin H. Johnson [EMAIL PROTECTED] wrote:
   On Thu, Mar 13, 2008 at 10:24:23AM +0100, Fabio Erculiani wrote:
 media-libs/x264-svn - dev-lang/yasm
 dev-libs/lzo - dev-lang/nasm
  
   I responded to you on IRC about these two, please see my message there,
as from everything I can see, the DEPs are actually correct.
(The config.log for lzo-1 indicates other reasons that it isn't using
nasm, which should probably get fixed for both x86 and amd64).
  
  
 sys-apps/attr - sys-devel/autoconf
  
   autoconf is in the DEPEND already.
Do you want it not there?
  
Not reviewing the rest right now, I'm going to bed instead (03h26 here).
  
  
--
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
  
  



 --
  Fabio Erculiani
  Information and Communication Technologies Consultant
  Sabayon Linux Chief Architect
  http://www.sabayonlinux.org



-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Natanael Copa]

On Thu, 2008-03-13 at 00:35 +0100, Fabio Erculiani wrote:

 I offer my help to fix DEPEND/RDEPEND split issues which is causing me
 a lot of headaches (along with localizations).
 For reference, please have a look here: http://planet.sabayonlinux.org/?p=105

I'm another distro builder that uses the Gentoo framework. I can only
agree. I had to roll my own binary package format and after a short
while I had to do the dependencies myself and just ignore RDEPEND since
it was close to useless.

While Gentoo is fantasitc to build stuff, the binary packagement has
some serious issues. It would be really nice if Gentoo could be better
on supporting other binary only package managers.

-nc

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Petteri Räty]

Natanael Copa kirjoitti:

On Thu, 2008-03-13 at 00:35 +0100, Fabio Erculiani wrote:


I offer my help to fix DEPEND/RDEPEND split issues which is causing me
a lot of headaches (along with localizations).
For reference, please have a look here: http://planet.sabayonlinux.org/?p=105


I'm another distro builder that uses the Gentoo framework. I can only
agree. I had to roll my own binary package format and after a short
while I had to do the dependencies myself and just ignore RDEPEND since
it was close to useless.



http://bugs.gentoo.org



While Gentoo is fantasitc to build stuff, the binary packagement has
some serious issues. It would be really nice if Gentoo could be better
on supporting other binary only package managers.

-nc



Expected as devs rarely use bin pkgs at all and the Portage support is 
what it is.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Help offered - Portage tree

[Petteri Räty]

Fabio Erculiani kirjoitti:

[02:31] Halcy0n lxnay: we offer all of our work that you base your
distribution off, and you don't contribute back at all, in any way.

^^ This is a really stupid sentence. It seems some of you don't even
realize how many users we brought to Gentoo, and this is really sad.



Nope it's not. I already told you on IRC that you weren't understanding 
Halcy0n properly, at least from my POV. You say you have to maintain 
many local changes in your overlay and that you don't have the time to 
send them back upstream (via the official contribution method, 
bugs.gentoo.org). For me that means that you aren't contributing back 
upstream.


Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Help offered - Portage tree

[Rémi Cardona]

Natanael and Fabio,

Petteri Räty a écrit :

Natanael Copa kirjoitti:


I'm another distro builder that uses the Gentoo framework. I can only
agree. I had to roll my own binary package format and after a short
while I had to do the dependencies myself and just ignore RDEPEND since
it was close to useless.



http://bugs.gentoo.org


I know that we (in the Gnome Herd) will try to fix things when they are 
reported and I have no doubt other devs will do so as well.


But a proper bug report is the way to go if you things to move in any 
direction.


Expected as devs rarely use bin pkgs at all and the Portage support is 
what it is.


+1 on that and if people who use binary pkgs don't tell us what breaks, 
we won't know.


Cheers

--
Rémi Cardona
LRI, INRIA
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Steve Dibb]

Fabio Erculiani wrote:

media-libs/x264-svn - dev-lang/yasm
dev-libs/lzo - dev-lang/nasm
sys-apps/attr - sys-devel/autoconf


*snip*

Some of those aren't broken, and I just fixed a few media ones in the 
tree, but that list is similiar to what I was asking for earlier, and a 
good way to contribute.


Thanks

Steve
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Denis Dupeyron]

On Thu, Mar 13, 2008 at 2:10 PM, Fabio Erculiani [EMAIL PROTECTED] wrote:
 [02:31] Halcy0n lxnay: we offer all of our work that you base your
  distribution off, and you don't contribute back at all, in any way.

  ^^ This is a really stupid sentence.

While I would agree Halcy0n's statement is slightly exaggerated, it's
somewhat true. There are exactly 26 non-duplicates in our bugzilla
that you either filed or commented on. You have to admit that for
somebody who's been a user for 7 years and who's been architecting
(your word) a distribution based on Gentoo for 3 years (or more ?
can't remember) this is a ridiculously low number. How do you want us
to help you if you don't give us any feedback on what you need ? We're
not very good at communicating but we have at least set up some tools
for you to use, and the most important of them in your particular case
is I believe bugzilla. And don't ask us to read you blog, we can't
possibly read everybody's blog. Feedback is part of the game in the
open source world. Gentoo itself gives a lot of feedback to upstream
projects using upstream's communications tools. If you don't play the
game, one thing is sure is that you'll never win.

 It seems some of you don't even
  realize how many users we brought to Gentoo, and this is really sad.

I'm not sure we should thank you for this. Not that we don't care, but
our aim isn't really to compete against say Ubuntu in the users
department. Some of us are really happy of the success of Sabayon,
there's a place for everybody. We don't make any money out of Gentoo,
and do not intend to. We're only a bunch of volunteers who waste their
free time doing something they think may be needed. It seems you don't
even realize how many users we brought to Sabayon, and this is really
sad.

  You see, people like Halcy0n, agaffney, zlin keep us away from
  interacting with you.

I wouldn't agree with you here. But even if you were right, we live in
stupid world and Gentoo doesn't claim to be better than what it's made
of. Note that we're trying to though. But in the end there are always
going to be obnoxious people everywhere. If you give up on the nice
guys because of the bad guys, you lose and the bad guys win. That's
life.

  If you want to stop bad press, you (all) should firstly become more
  gentle with users and external contributors.

I'm trying to believe you are not threatening here because *that*
would be stupid. We'd love to be gentle with you. You've just got to
make it happen.

Denis.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Caleb Tennis]

 +1 on that and if people who use binary pkgs don't tell us what breaks,
 we won't know.

I'll kick it off, then.

The binpkg format needs some way to store the actual versions of the 
dependencies as
they were on the machine the package was compiled on.  Then, when emerging the
binpkg, someway to force those dependencies on the new install machine would be
nice.

I'll give an example.  Package A was built on machine 1, and has a dep on
=openssl-0.9.7.  Machine 1 has openssl-0.9.8 already installed.  Binary package
built, no problem.

Now, we attempt to install binary package A on machine 2, which has 
openssl-0.9.7. 
It installs fine, deps met.  But, whoops, there's some symbols missing when we 
go to
use package A on machine 2.  After some time, we finally realize it's because we
need new openssl.

I use this example because it's actually hit me before, but it extends to lots 
of
other scenarios.  The obvious fix is to either use --deep, or just make sure you
need machine 2 up to date with machine 1, though that's difficult to do when 
you're
talking about machine 301 and machine 559.

If there was a way to tell the bin package installer to make sure you met all 
of the
same minimum verisons of the deps as they were on the original compiling 
machine,
that would be fantastic.

Now, I'm happy to file a bug and assign it (to the portage team?), but I view 
this
really as a wishlist item, and since admittedly very few devs use the binpkg 
stuff,
I didn't see it as something that would probably get acted upon anyway.  I'm not
complaining about that either, just merely stating a fact.

Caleb

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Fabian Groffen]

(I experimented with binpkgs a little while ago in Prefix)

On 13-03-2008 10:15:33 -0400, Caleb Tennis wrote:
  +1 on that and if people who use binary pkgs don't tell us what breaks,
  we won't know.
 
 I'll kick it off, then.
 
 The binpkg format needs some way to store the actual versions of the
 dependencies as they were on the machine the package was compiled on.
 Then, when emerging the binpkg, someway to force those dependencies on
 the new install machine would be nice.
 
 I'll give an example.  Package A was built on machine 1, and has a dep on
 =openssl-0.9.7.  Machine 1 has openssl-0.9.8 already installed.  Binary 
 package
 built, no problem.
 
 Now, we attempt to install binary package A on machine 2, which has
 openssl-0.9.7.  It installs fine, deps met.  But, whoops, there's some
 symbols missing when we go to use package A on machine 2.  After some
 time, we finally realize it's because we need new openssl.

Isn't that stored in the NEEDED file?

 I use this example because it's actually hit me before, but it extends
 to lots of other scenarios.  The obvious fix is to either use --deep,
 or just make sure you need machine 2 up to date with machine 1, though
 that's difficult to do when you're talking about machine 301 and
 machine 559.
 
 If there was a way to tell the bin package installer to make sure you
 met all of the same minimum verisons of the deps as they were on the
 original compiling machine, that would be fantastic.

I guess ideally the SLOTs should match, as for instance libpcre 7.5 and
7.6 work fine as long as libpcre.so.0 is there.  (No guarantees)
But even, for platforms that need libgcc_s.so.1, any gcc that provides it
should be fine.  Though luckily gcc is almost never in DEPEND/RDEPEND.

 Now, I'm happy to file a bug and assign it (to the portage team?), but
 I view this really as a wishlist item, and since admittedly very few
 devs use the binpkg stuff, I didn't see it as something that would
 probably get acted upon anyway.  I'm not complaining about that
 either, just merely stating a fact.

I think binpkgs store more information than you think.  It's just that
Portage doesn't fully use it (yet).


-- 
Fabian Groffen
Gentoo on a different level
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Gilles Dartiguelongue]

Le jeudi 13 mars 2008 à 10:15 -0400, Caleb Tennis a écrit :
  +1 on that and if people who use binary pkgs don't tell us what breaks,
  we won't know.
 
 I'll kick it off, then.
 
 The binpkg format needs some way to store the actual versions of the 
 dependencies as
 they were on the machine the package was compiled on.  Then, when emerging the
 binpkg, someway to force those dependencies on the new install machine would 
 be
 nice.
 
 I'll give an example.  Package A was built on machine 1, and has a dep on
 =openssl-0.9.7.  Machine 1 has openssl-0.9.8 already installed.  Binary 
 package
 built, no problem.
 
 Now, we attempt to install binary package A on machine 2, which has 
 openssl-0.9.7. 
 It installs fine, deps met.  But, whoops, there's some symbols missing when 
 we go to
 use package A on machine 2.  After some time, we finally realize it's because 
 we
 need new openssl.
 
 I use this example because it's actually hit me before, but it extends to 
 lots of
 other scenarios.  The obvious fix is to either use --deep, or just make sure 
 you
 need machine 2 up to date with machine 1, though that's difficult to do when 
 you're
 talking about machine 301 and machine 559.
 
 If there was a way to tell the bin package installer to make sure you met all 
 of the
 same minimum verisons of the deps as they were on the original compiling 
 machine,
 that would be fantastic.
 
 Now, I'm happy to file a bug and assign it (to the portage team?), but I view 
 this
 really as a wishlist item, and since admittedly very few devs use the binpkg 
 stuff,
 I didn't see it as something that would probably get acted upon anyway.  I'm 
 not
 complaining about that either, just merely stating a fact.

I think remi was more speaking about incorrect deps (say misplaced in
RDEPEND) than problems concerning the package manager.

In any case, openssl is the perfect example of what can go wrong because
of upstream's behavior. The problem is that program A compiled against
version X of openssl won't work with version YX. Currently we need to
keep X's libs around and run revdep-rebuild to fix this.

Most librairies don't cause this problem though so I don't really see
this as a bug on the gentoo side even if it's annoying.

Anyway, to keep machines using binary in sync without much headache, my
current solution is to use a squashfsed portage tree with --deep. It
works pretty well.
-- 
Gilles Dartiguelongue [EMAIL PROTECTED]
Gentoo

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Caleb Tennis]

 Isn't that stored in the NEEDED file?

It very well might be, I'm not much of an expert here :)

 I think binpkgs store more information than you think.  It's just that
 Portage doesn't fully use it (yet).

This is good information to know.  Thanks!

Caleb

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Caleb Tennis]

 I think remi was more speaking about incorrect deps (say misplaced in
 RDEPEND) than problems concerning the package manager.

 In any case, openssl is the perfect example of what can go wrong because
 of upstream's behavior. The problem is that program A compiled against
 version X of openssl won't work with version YX. Currently we need to
 keep X's libs around and run revdep-rebuild to fix this.

Right, my example was mildly contrived.  But I've run into this same issue with
packages like ruby and glibc, where the build system had newer versions and you 
run
into symbol issues (or errors like invalid binary format) because you need to
upgrade underlying libraries.

 Most librairies don't cause this problem though so I don't really see
 this as a bug on the gentoo side even if it's annoying.

It's not really Gentoo's fault, no, but it's a problem that could be somewhat 
fixed.

 Anyway, to keep machines using binary in sync without much headache, my
 current solution is to use a squashfsed portage tree with --deep. It
 works pretty well.

Agreed, but the problem is (at least in my case) we're talking about production
machines that are actively running, and the customer needs an upgrade of a 
package
but we don't want to take a chance at ruining something else by upgrading 
--deep if
we can help it.

From their perspective, they just want it to work (and don't care about what 
has to
be upgraded), but from a sysadmin perspective it's a difficult problem to solve 
over
time, especially when you have 10+ other sysadmins, who all may not know that 
when
you upgrade package X be sure to remember to also upgrade packages Y and Z at 
the
same time or you'll run into problems.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Jan Kundrát]

Fabio Erculiani wrote:

^^ This is a really stupid sentence. It seems some of you don't even
realize how many users we brought to Gentoo, and this is really sad.


I'm not sure I understand how exactly you bring people to Gentoo. You 
bring people to your distribution which is a binary rebuilt of Gentoo, 
AFAIK. Or do you have a steady stream of users drifting away from 
Sabayon to Gentoo?



You see, people like Halcy0n, agaffney, zlin keep us away from
interacting with you. 


Us being you or who exactly? Halcy0n was just trying to understand 
what exactly are you going to improve.



If you want to stop bad press, you (all) should firstly become more
gentle with users and external contributors. I am not talking to you
directly Robin, but to whom are quite annoying and provocative. I know
that the majority of you have been always kind, but I will never hang
on #gentoo-dev anymore just to be played around giving me voice until
I annoy someone with my POV.


Well, I was trying pretty hard last night to hear interesting 
suggestions from you which could be actually implemented. I have even 
asked the same questions as Halcy0n did, yet you call him a bad guy 
and not me. That's strange. Anyway, please take your time to read the 
following and think about it. Perhaps you'll find out that we aren't a 
group of lazy and angry morons, but a group of people that respect each 
other and wants to get technical issues solved, but with limited time at 
hand.


All you said yesterday was I don't have time to wait till my bugs are 
fixed, gimme access so that I can fix them myself. As we have been 
trying to tell you in more than two hours, this is not how things work. 
In Gentoo, we respect other developers' work, so if we see a flaw in 
their code, we speak to them about it and don't go blindly fixing stuff 
without prior chat with maintainers.


Having more than 13k packages in the three, no single person can be 
expected to know the whole tree well. That's why we are organized into 
groups and generally talk to each other before fixing bugs. A change you 
make might have huge impact on packages you haven't ever heard of.


During the chat, you proposed various things like having a mailing 
lists where child distributions could send bugreports they find. This 
is not the way to go. We already have a support channel, the Bugzilla. 
There is really no way to speed up maintainers' reactions. That doesn't 
depend on how they get the reports, but entirely on their spare time and 
motivation.


If you don't like working with bugzilla's web interface, you've been 
already offered another access vectors to the bugzilla database.


But let me repeat it once again -- if you are worried about maintainers 
taking long time to respond (where long time is, by your definition, 
at about more than two hours, if I understand you correctly), there's 
no way I'm aware of that this could be changed. We are just humans who 
have to sleep, eat, work, date beautiful girls and drink beer. We are 
not going to abandon any of these just to make the child distributions 
happy, sorry.


I have quite a mixed feelings about your offer, too -- you said you're 
willing to fix stuff, yet you refuse to file bugs, giving a reason that 
it takes time. That doesn't make much sense to me, sorry. If you don't 
file the bug, the same error will stay in the package, it will propagate 
to each and every next release and you'll have to fix it over and over 
again in your code.



This is not a democratic way, let's talk
publicly here, without hiding in a development channel, we probably
get more visibility, don't we?


I'm afraid I don't fully understand your point here -- Gentoo is not 
about democracy as in what majority wants, that happens. If it was 
such kind of democracy, we'd have reiser4 as a default filesystem for 
three years now. In Gentoo, things that happen are things that 
developers want. If you're bored with that, hey, become a developer and 
change stuff. Asking us to change the way we work, the process that has 
worked for many years and that we are happy with, just because it might 
give some benefits to your distribution, while also causing more work 
for us, that simply won't happen.


Please, try to think about our reasons.

Cheers,
-jkt

--
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Help offered - Portage tree

[Chris Gianelloni]

On Thu, 2008-03-13 at 17:48 +0100, Fabio Erculiani wrote:
 On 3/13/08, Chris Gianelloni [EMAIL PROTECTED] wrote:
  I'm a distro builder, too, and I haven't been hitting any of these
   problems.  Would you care to point out the actual problems, or will the
   close to useless comment be our only indication of the perceived
   problems?

 Yeah, but IIRC you are a SOURCE distro builder. Arent't you? (I am just 
 asking!)

No.  I build binary packages.  Hell, catalyst uses the binary package
support *heavily* for its caching.

Do people really think that a pre-compiled stage tarball is source?  How
about a pre-compiled LiveCD?  Anyone?

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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

Re: [gentoo-dev] Help offered - Portage tree

[Chris Gianelloni]

On Thu, 2008-03-13 at 14:48 -0400, Caleb Tennis wrote:
  As much as I hate to say it, your example was rather bunk, because
  openssl changed SONAME during that time.  Keeping the package
 
 You're right here.  After review, the problem was the difference between 
 0.9.8e and
 0.9.8g, the latter of which provided some form of newer symbol that wasn't in 
 e. 
 But the concept is the same.

Correct.  That would not have been caught and would be an issue, still.

  Uhh... = in RDEPEND does that, already... Also, this wouldn't have
  resolved your openssl issue, at all.  Your machine scenario above would
  have still failed, since the minimum version was 0.9.7 on your build
  host.
 
 I'm not talking about meeting the minimum required by the ebuild, I'm talking 
 about
 the minimum that were installed at the time of the emerge.
 
  Well, I sincerely hope that you do not file such a bug, as it would
  royally screw over the one team in Gentoo that *does* consistently use
  our binary package support.
 
 I don't plan on filing the bug, but if it was an optional emerge option to 
 use the
 actual version deps vs. the DEPEND of the ebuild, it wouldn't affect you 
 would it?

If it were optional, it wouldn't affect us.  I'd have no issue with some
kind of optional support for this sort of thing.

  I would definitely like to see the support improved, but not at the
  expense of doing very stupid things like locking to specific
  versions/revisions of packages.  No offense, but that screams of RPM
  hell.
 
 I'm not trying to lock to any specific version.  I'm trying to reproduce on 
 machine
 2 the same state of packages that package A was compiled against on machine 
 1.  And
 even make it optional to do so, via an emerge flag.

This is likely usually done by controlling the binrepo.  At least,
that's how I do it.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Games Developer


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

Re: [gentoo-dev] Help offered - Portage tree

[René 'Necoro' Neumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm not a gentoo-dev - and I did not read the whole thread, because it
was too political for me (do I really have to read all these IRC quotes?).

But I just had an idea for this topic (don't know if anyone had this
already - or if it is not applicable here), that I want to share:

Why not try to find someone, who does all the bug filing? - So lxnay can
find and fix the bugs - and someone else files the bugs and does the
discussing with the gentoo-devs. Then both sides have what they want. Of
course, it still takes time to get things into the tree, but this
shouldn't be a problem :) (I think).

Just an idea - please don't eat me, if it's a silly one ^^

Regards,
Necoro
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH2X6a4UOg/zhYFuARAhiWAJ0WzGC6jzRODv9pjezsygRBAUoTWQCfQZro
eCQ/dsAY+OZsMvg+ffLGCAc=
=NqLb
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Robin H. Johnson]

On Thu, Mar 13, 2008 at 01:53:34PM +0100, Fabio Erculiani wrote:
 Hi Robin,
 first of all.
 What I need is _basic_ respect on #gentoo-dev
 You here seem all polite, but there you like playing me.
 This is not a good start.
Excuse me? I have never spoken to you on the #gentoo-dev IRC channel,
and thus I cannot be 'playing you' there.

The only places I have thus communicated with you are this mailing list,
and a private IRC discussion.

You still haven't responded either to the private IRC, or here, as to
what you see about media-libs/x264-svn, dev-libs/lzo or sys-apps/attr is
wrong, and I'd really like to know.

P.S. Please don't top post.

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpLBhTMG6t9f.pgp
Description: PGP signature

Re: [gentoo-dev] Help offered - Portage tree

[Natanael Copa]

Rémi Cardona wrote:

Natanael Copa a écrit :

But somethimes you just need to accept we don't live in a perfect world.
I understood early that nobody cares that much about binpkgs anyway and
moved on.


I'd say you're mistaken. A lot of people care about binpkg. It's not 
because a majority of devs don't _use_ them that they are not willing 
to fix bugs for other use cases.


If it would be practically possible I would still use RDEPEND. It worked 
alot better to build stuff around NEEDED.



Same thing can be said about other arches or other OSs Gentoo can run on.

and hardened.
As for the URL you've provided, I don't know what you were trying to 
demonstrate because about 3/4th of the bugs were marked as fixed, 
showing me that your patches got accepted. :) Which is good... isn't it?


I wanted to demonstrate that I do submit bugs and very often I submit a 
patch with it. (so I kinda know what bugs.g.o is)



I, for one, encourage you to keep opening bug reports.


Don't worry, I will.


Cheers

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Natanael Copa]

Chris Gianelloni wrote:

On Thu, 2008-03-13 at 14:34 +0100, Natanael Copa wrote:
  

On Thu, 2008-03-13 at 00:35 +0100, Fabio Erculiani wrote:



I offer my help to fix DEPEND/RDEPEND split issues which is causing me
a lot of headaches (along with localizations).
For reference, please have a look here: http://planet.sabayonlinux.org/?p=105
  

I'm another distro builder that uses the Gentoo framework. I can only
agree. I had to roll my own binary package format and after a short
while I had to do the dependencies myself and just ignore RDEPEND since
it was close to useless.



I'm a distro builder, too, and I haven't been hitting any of these
problems.  Would you care to point out the actual problems, or will the
close to useless comment be our only indication of the perceived
problems?
  
Regarding the RDPEND's, there is nothing in the framework protecting the 
RDEPENDS from be wrong. If its wrong, package still compiles and 
installs and (almost) everyone is happy. It pulls in unnecessary stuff 
but who cares? Disk space is cheap.


So since I build a distro where size does matter (uclibc) I realised 
that even if I submit bugs for broken RDEPEND, there will never be an 
end to those bug reports. Looking at this thread, it seems i was right.


That doesn't mean i dont submit bugreports. I do and I very often submit 
a patch. But there is a limit on how much you can fix in upstream before 
you need to go other ways. (That applies to fixing package splitting 
upstream as well btw...)


-nc
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Qian Qiao]

On Thu, Mar 13, 2008 at 8:44 PM, Natanael Copa [EMAIL PROTECTED] wrote:
  Regarding the RDPEND's, there is nothing in the framework protecting the
  RDEPENDS from be wrong. If its wrong, package still compiles and
  installs and (almost) everyone is happy.

Just because it compiles and installs, doesn't mean it runs.

 It pulls in unnecessary stuff but who cares? Disk space is cheap.

Not always the case.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[joshua jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fabio Erculiani wrote:
| Hi all,
| snip
| Cheers

interestingly enough ixnay...I've tried contacting you about working 
together with Gentoo and on things related to eapi as sabayon is one of 
the more popular distributions that has somewhat of a basis on Gentoo 
(I've tried approximately 3-4 times in the last year or so) . Every time 
I tried from 4 different domain accounts including my Gentoo one I was 
denied the ability to send you an email.


While I'm sure many comments are going to be a bit harsh if realistic 
please do feel free to talk to any of the developers.


Splitting isn't really realistic as that is getting away from upstream. 
As an organization we try to maintain the same way as upstream intends. 
If they say that mysql is not a collection of server, client then its 
just mysql. Xorg is a perfect example. It was a huge package, that got 
split up. It took Donnie and the rest of the X team a while to get 
everything ready for the tree but we followed upstream in having 
individual packages for the different aspects of the larger project.


Please feel free to contact me directly if you wish
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH2aop2ZWR0Jhg/EsRAkppAJ0e5u5LEfrdHP/FpsgghMm0kd07mQCfRmZP
3rMibnJCkKJih3bsz/VYGpY=
=c41u
-END PGP SIGNATURE-

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Fabio Erculiani]

Hi Joshua,
I never had issues with my emails. So I don't really know what to
answer you regarding to your issues :)
SPLIT: Although I think it can be a suboptimal thing for us, I can
understand your policy. Let me add that, to me, the biggest issue is
about (R)DEPEND. Splitting packages and maintaining in an overlay it's
not that hard.


On 3/13/08, joshua jackson [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1

  Fabio Erculiani wrote:
  | Hi all,
  | snip
  | Cheers

  interestingly enough ixnay...I've tried contacting you about working
  together with Gentoo and on things related to eapi as sabayon is one of
  the more popular distributions that has somewhat of a basis on Gentoo
  (I've tried approximately 3-4 times in the last year or so) . Every time
  I tried from 4 different domain accounts including my Gentoo one I was
  denied the ability to send you an email.

  While I'm sure many comments are going to be a bit harsh if realistic
  please do feel free to talk to any of the developers.

  Splitting isn't really realistic as that is getting away from upstream.
  As an organization we try to maintain the same way as upstream intends.
  If they say that mysql is not a collection of server, client then its
  just mysql. Xorg is a perfect example. It was a huge package, that got
  split up. It took Donnie and the rest of the X team a while to get
  everything ready for the tree but we followed upstream in having
  individual packages for the different aspects of the larger project.

  Please feel free to contact me directly if you wish
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v2.0.7 (GNU/Linux)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

  iD8DBQFH2aop2ZWR0Jhg/EsRAkppAJ0e5u5LEfrdHP/FpsgghMm0kd07mQCfRmZP
  3rMibnJCkKJih3bsz/VYGpY=
  =c41u
  -END PGP SIGNATURE-


  --
  gentoo-dev@lists.gentoo.org mailing list




-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[joshua jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fabio Erculiani wrote:
| Hi Joshua,
| I never had issues with my emails. So I don't really know what to
| answer you regarding to your issues :)
| SPLIT: Although I think it can be a suboptimal thing for us, I can
| understand your policy. Let me add that, to me, the biggest issue is
| about (R)DEPEND. Splitting packages and maintaining in an overlay it's
| not that hard.
|
|
|
I personally have no desire to follow the redhat/debian/other binary
packaging systems which split up infinitesimally small packages. It
causes a lot more busywork in my opinion then any potential benefits
that it gains you.

As far as the depend issue you mentioned: Having both Rdepends and
Depends isn't as far as I'm aware part of any EAPI currently (Correct me
if I'm wrong people). Rdepends are needed for the builds so you will
often see either RDEPENDS=${DEPEND} or vice versa. If its not there then
its more of a matter of accounting then anything. I would think, and
correct me if I'm wrong again, that it would make sense that if you only
have RDEPENDS or DEPEND, then those same applications are required in
the runtime of the application. Does it need to be explicitly stated? So
far the three package manager that I'm aware of all manage this fine.
Those being portage, paludis, and pkgcore. If there are other package
managers out there that might have issues Its a perfect example of a
reason to be involved in the EAPI discussions to help define what is
needed and where.

So what I suggest to you is perhaps looking over the EAPI=0 draft
documentation and proposing some additions and or modifications that
benefit everyone (not just one person), as its designed to be a standard
for anyone who makes use of ebuilds and beyond.

http://dev.gentoo.org/~spb/pms.pdf

Is the current form, but halcy0n is working on an updated version of it
for the next council meeting.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH2bL22ZWR0Jhg/EsRAkduAJsGBKKl5HgR5YXziPn9yOLbi5F5MwCfacIC
b/aqsokP3A6JFJ7hO4LGNXY=
=BGqi
-END PGP SIGNATURE-
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Ciaran McCreesh]

On Thu, 13 Mar 2008 09:25:17 -0700
Chris Gianelloni [EMAIL PROTECTED] wrote:
 On Thu, 2008-03-13 at 13:53 +0100, Fabio Erculiani wrote:
  What I need is _basic_ respect on #gentoo-dev
 
 I guess you don't understand that respect has to be earned.

Mmm, funny, when I said that, certain people disagreed very loudly...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Help offered - Portage tree

[Fabio Erculiani]

Joshua,
I know that draft quite well, I used as reference for writing Entropy,
our binary package manager which only uses {R,P}DEPEND and not DEPEND.
So here comes the issue, when *DEPEND are not declared properly
Entropy pulls in unneeded packaged.
What you are saying is something I am already aware of :) zmedico has
been really helpful :)

On 3/14/08, joshua jackson [EMAIL PROTECTED] wrote:
 -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1

  Fabio Erculiani wrote:

 | Hi Joshua,
  | I never had issues with my emails. So I don't really know what to
  | answer you regarding to your issues :)
  | SPLIT: Although I think it can be a suboptimal thing for us, I can
  | understand your policy. Let me add that, to me, the biggest issue is
  | about (R)DEPEND. Splitting packages and maintaining in an overlay it's
  | not that hard.
  |
  |
  |

 I personally have no desire to follow the redhat/debian/other binary
  packaging systems which split up infinitesimally small packages. It
  causes a lot more busywork in my opinion then any potential benefits
  that it gains you.

  As far as the depend issue you mentioned: Having both Rdepends and
  Depends isn't as far as I'm aware part of any EAPI currently (Correct me
  if I'm wrong people). Rdepends are needed for the builds so you will
  often see either RDEPENDS=${DEPEND} or vice versa. If its not there then
  its more of a matter of accounting then anything. I would think, and
  correct me if I'm wrong again, that it would make sense that if you only
  have RDEPENDS or DEPEND, then those same applications are required in
  the runtime of the application. Does it need to be explicitly stated? So
  far the three package manager that I'm aware of all manage this fine.
  Those being portage, paludis, and pkgcore. If there are other package
  managers out there that might have issues Its a perfect example of a
  reason to be involved in the EAPI discussions to help define what is
  needed and where.

  So what I suggest to you is perhaps looking over the EAPI=0 draft
  documentation and proposing some additions and or modifications that
  benefit everyone (not just one person), as its designed to be a standard
  for anyone who makes use of ebuilds and beyond.

  http://dev.gentoo.org/~spb/pms.pdf

  Is the current form, but halcy0n is working on an updated version of it
  for the next council meeting.

 -BEGIN PGP SIGNATURE-
  Version: GnuPG v2.0.7 (GNU/Linux)
  Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


 iD8DBQFH2bL22ZWR0Jhg/EsRAkduAJsGBKKl5HgR5YXziPn9yOLbi5F5MwCfacIC
  b/aqsokP3A6JFJ7hO4LGNXY=
  =BGqi

 -END PGP SIGNATURE-
  --
  gentoo-dev@lists.gentoo.org mailing list




-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Help offered - Portage tree

[Fabio Erculiani]

Hi all,
I'm sure I'll find some sabayon-hater here, but my purpose won't be
answering to them.
I offer my help to fix DEPEND/RDEPEND split issues which is causing me
a lot of headaches (along with localizations).
For reference, please have a look here: http://planet.sabayonlinux.org/?p=105

After having discussed with one of your dev about it, he suggested me
to ask here looking for a mentor. If there's anything I can do, I'm
ready.

Despite some of you might think, I love Gentoo since 2001 :)

Cheers
-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Help offered - Portage tree

[Jan Kundrát]

Fabio Erculiani wrote:

I offer my help to fix DEPEND/RDEPEND split issues which is causing me
a lot of headaches (along with localizations).
For reference, please have a look here: http://planet.sabayonlinux.org/?p=105


The name [EMAIL PROTECTED] is not a valid username. Either you 
misspelled it, or the person has not registered for a Bugzilla 
account., that's all what our bugzilla knows about you.


Either you're using a different e-mail address there or you really 
haven't reported a single bug to us in that seven years.


It would help if you file bugs against respective packages or provide a 
list of examples mentioning what exactly needs fixing. You can't 
reasonably expect us to act based on a post in $random_blog.


With love,
-jkt

--
cd /local/pub  more beer  /dev/mouth



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Help offered - Portage tree

[Fabio Erculiani]

Hi Jan,
I'm registered with lxnay at lxnaydesign dot net.
I know what you mean, but take into account I don't have much time
left for the reporting. What I ask is either build a communication
channel or getting me able to fix stuff, obviously after having
contacted the respective maintainers and talked about the issue. Well,
I am saying this utopic thing just because I don't even have time to
track down all the issues I found and then report, most of the time I
end up copying the ebuild from the tree into our overlay and fix. I
tried to report a few bugs, but the response time is quite big and I
always have to be quick.
So, to sum up, if we can build a better communication way it could be
useful for both sides.


On 3/13/08, Jan Kundrát [EMAIL PROTECTED] wrote:
 Fabio Erculiani wrote:
   I offer my help to fix DEPEND/RDEPEND split issues which is causing me
   a lot of headaches (along with localizations).
   For reference, please have a look here: 
 http://planet.sabayonlinux.org/?p=105


 The name [EMAIL PROTECTED] is not a valid username. Either you
  misspelled it, or the person has not registered for a Bugzilla
  account., that's all what our bugzilla knows about you.

  Either you're using a different e-mail address there or you really
  haven't reported a single bug to us in that seven years.

  It would help if you file bugs against respective packages or provide a
  list of examples mentioning what exactly needs fixing. You can't
  reasonably expect us to act based on a post in $random_blog.

  With love,
  -jkt


  --
  cd /local/pub  more beer  /dev/mouth





-- 
Fabio Erculiani
Information and Communication Technologies Consultant
Sabayon Linux Chief Architect
http://www.sabayonlinux.org
--
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Help for arch teams

[Christian Faulhammer]

Hi,

[CC some arch teams, too, as not all devs read -dev]

As promised [1] about two months ago, the template for Gatt, that
handles all the commit stuff for architecture developers, is now ready
to be used by the public. Some bugs in Gatt needed to be resolved and
heavy testing has been done. 

1. Emerge the package with Gatt
2. Test the software
3. Use the template named keywords shipped with Gatt to create a
script for stabilisation Execute it on the system you have commit
access from

All needed commands are given in the TUTORIAL file, so I concentrate on
what the script can do for you: 

* determine if it is a keywording or stabilisation request
* determine if it is a security stabilisation and set ChangeLog/commit
message plus Bugzilla handling correctly
* update of cvs tree before doing any work
* setting needed keyword 
* setting ChangeLog scan for QA errors (repoman)
* commit it to the repository
* uncc arch from bug including message arch stable 
* and close bug if needed (not when security related) always
with confirmation

Test it and report back.  Thanks.

V-Li

[1]
URL:http://www.faulhammer.org/index.php?option=com_contenttask=viewid=198

-- 
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode

URL:http://www.faulhammer.org/


signature.asc
Description: PGP signature

[gentoo-dev] Help with libflashsupport for amd64

[Jim Ramsay]

I have just added net-www/libflashsupport-1.2 for ~x86, and would like
to get the help of at least one amd64 dev to ensure it also works for
~amd64 before I add it as an optional dependency to
net-www/netscape-flash

So, any amd64 dev who can give me a hand, please do so, and/or contact
me! Thank you.

For those who do not know already, libflashsupport adds pulseaudio,
oss, esd, and/or ssl/gnutls support to the netscape-flash binary.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)


signature.asc
Description: PGP signature

Re: [gentoo-dev] help with gnutls-1.4.4 needed[FIXED] - helpers still very welcome.

[Daniel Black]

On Tuesday 19 September 2006 21:35, Daniel Black wrote:
 As reported
 https://bugs.gentoo.org/show_bug.cgi?id=147800 gnutls-1.4.4 links itself
 against an existing gnutls-1.2* version if installed. I haven't been able
 to find the cause of this.

Bug fixed in gnutls-1.4.4-r1.

Testers still welcome as below.

 If anyone missed my previous plea to do some preliminary testing with
 gnutls here it is again:
 ---
 To participate please:
 1. add
 ~net-libs/gnutls-1.4.4
 ~dev-libs/libtasn1-0.3.5
 to /etc/portage/package.unmask and /etc/portage/package.keywords files.

 2. emerge -1 ~net-libs/gnutls-1.4.4

 3. run revdep-rebuild

 4. and report bugs on bugs.gentoo.org making them block bug 147682

 revdep-rebuild may get the order of the rebuild incorrect so please watch
 out for this error.
 


 --
 Daniel Black [EMAIL PROTECTED]
 Gentoo Foundation

-- 
Daniel Black [EMAIL PROTECTED]
Gentoo Foundation
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] help

[Dan Podeanu]

help

Re: [gentoo-dev] help

[Michael Cummings]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dan Podeanu wrote:
 help

help: help [-s] [pattern ...]
 Display helpful information about builtin commands.  If PATTERN is
specified, gives detailed help on all commands matching PATTERN,
otherwise a list of the builtins is printed.  The -s option
restricts the output for each builtin command matching PATTERN to
a short usage synopsis.

(couldn't resist - send this to [EMAIL PROTECTED])

~mcummings
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEoZ/Sq1ztTp5/Ti4RAq9eAKCYn8wr+KEv7OzKiTIO+eYZAXDNLwCgjVYR
BgaFDZwDSP7JC0254RUglCo=
=dOOm
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] help

[Raphael Marichez]

/me gives some help to Dan


sorry   -- []
-- 

Raphael Marichez aka Falco


pgp2puNJzRcLr.pgp
Description: PGP signature