[gentoo-dev] pushing fixes to stable before closing bugs

[Paweł Hajdan, Jr.]

I noticed a general tendency to close bugs affecting stable before
pushing the fix to stable.

One recent example is ,
but there are more.

The idea is that if you only fix in ~arch, you risk a serious and
_known_ regression in stable, which could be easily avoided.

Do you have any ideas how do we:

1. Make as many developers (everyone?) as possible aware of this.

2. Handle already closed bugs with no fix in stable? I've seen people
closing the bugs again.

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Pacho Ramos]

El sáb, 12-05-2012 a las 12:34 +0200, "Paweł Hajdan, Jr." escribió:
> I noticed a general tendency to close bugs affecting stable before
> pushing the fix to stable.
> 
> One recent example is ,
> but there are more.
> 
> The idea is that if you only fix in ~arch, you risk a serious and
> _known_ regression in stable, which could be easily avoided.
> 
> Do you have any ideas how do we:
> 
> 1. Make as many developers (everyone?) as possible aware of this.
> 
> 2. Handle already closed bugs with no fix in stable? I've seen people
> closing the bugs again.
> 
> Paweł
> 

I guess it depends in how major is the fixed bug, if it's not too major,
I think we can wait for next stabilization round (we tend to do it in
gnome team)


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

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Rich Freeman]

On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr."
 wrote:
> The idea is that if you only fix in ~arch, you risk a serious and
> _known_ regression in stable, which could be easily avoided.

How can you have a regression in stable if stable has the bug already?
 A regression is when you have a stable package with a bug, then you
introduce a new stable package that doesn't have that bug, and then
you introduce yet another new stable package that has the same bug
back again.

While I can see some value in tracking whether bugs have made it to
stable yet, I think we need better tools if we want to do that.
Otherwise it is a big housekeeping mess tracking what is and isn't in
stable yet.

I see the value when we're talking about security bugs, or very
critical bugs, but for the run-of-the-mill minor issues that are the
majority of bug reports I don't see the value in keeping bugs open for
a month or two just to track that the inevitable hasn't happened yet.

Rich

[gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Samuli Suominen]

Example,

- Package is using autotools.
- The default phase like below works for the package:

src_install() {
emake DESTDIR="${D}" install
dodoc README
}

So when writing a new ebuild you would only add:

DOCS="README"

And be done with it. Then the next version of the package needs extra 
argument passed to emake install, for example:


src_install() {
emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
dodoc README
}

So you are /forced/ to write entire src_install() while you only want to 
append one argument to emake install.


The current workaround for this is to use EXTRA_EMAKE from ebuild, but I 
find this rather ugly (if not even forbidden by some PMS magic?)


Can we make econf in src_configure, emake in src_compile, and emake 
install in src_install accept arguments "$@" in EAPI=5, please?


Relavent bug is http://bugs.gentoo.org/364343

- Samuli

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Ulrich Mueller]

> On Sat, 12 May 2012, Samuli Suominen wrote:

> Example,
> - Package is using autotools.
> - The default phase like below works for the package:

> src_install() {
> emake DESTDIR="${D}" install
> dodoc README
> }

> So when writing a new ebuild you would only add:

> DOCS="README"

> And be done with it. Then the next version of the package needs extra 
> argument passed to emake install, for example:

> src_install() {
> emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
> dodoc README
> }

> So you are /forced/ to write entire src_install() while you only want to 
> append one argument to emake install.

> The current workaround for this is to use EXTRA_EMAKE from ebuild, but I 
> find this rather ugly (if not even forbidden by some PMS magic?)

EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
support this variable? Portage does since 2004 at least.

> Can we make econf in src_configure, emake in src_compile, and emake 
> install in src_install accept arguments "$@" in EAPI=5, please?

I'd rather document EXTRA_EMAKE and EXTRA_ECONF in the spec, either
retroactively (in case all package managers support these variables
already), or for EAPI 5. It would accomplish the same as your
proposal, even without the need to add an explicit src_install
function.

> Relavent bug is http://bugs.gentoo.org/364343

Ulrich

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Michał Górny]

On Sat, 12 May 2012 19:57:07 +0200
Ulrich Mueller  wrote:

> > The current workaround for this is to use EXTRA_EMAKE from ebuild,
> > but I find this rather ugly (if not even forbidden by some PMS
> > magic?)
> 
> EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
> support this variable? Portage does since 2004 at least.

EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
variable for users who need to pass something specific to make.

> > Can we make econf in src_configure, emake in src_compile, and emake 
> > install in src_install accept arguments "$@" in EAPI=5, please?
> 
> I'd rather document EXTRA_EMAKE and EXTRA_ECONF in the spec, either
> retroactively (in case all package managers support these variables
> already), or for EAPI 5. It would accomplish the same as your
> proposal, even without the need to add an explicit src_install
> function.

As above. Otherwise, we'll end up reimplementing just another variable
to let users pass their custom arguments.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Samuli Suominen]

On 05/12/2012 09:09 PM, Michał Górny wrote:

On Sat, 12 May 2012 19:57:07 +0200
Ulrich Mueller  wrote:


The current workaround for this is to use EXTRA_EMAKE from ebuild,
but I find this rather ugly (if not even forbidden by some PMS
magic?)


EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
support this variable? Portage does since 2004 at least.


EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
variable for users who need to pass something specific to make.


Can we make econf in src_configure, emake in src_compile, and emake
install in src_install accept arguments "$@" in EAPI=5, please?


I'd rather document EXTRA_EMAKE and EXTRA_ECONF in the spec, either
retroactively (in case all package managers support these variables
already), or for EAPI 5. It would accomplish the same as your
proposal, even without the need to add an explicit src_install
function.


As above. Otherwise, we'll end up reimplementing just another variable
to let users pass their custom arguments.



Yeah, I think we should keep these EXTRA_* for users only and have 
something else for the ebuilds


(And I'm sure I don't remember wrong by saying some people have quite 
passionately resisted using EXTRA_ECONF within an ebuild in the past for 
this exact reasoning)


- Samuli

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[Ulrich Mueller]

> On Sat, 12 May 2012, Michał Górny wrote:

> On Sat, 12 May 2012 19:57:07 +0200
> Ulrich Mueller  wrote:

>> > The current workaround for this is to use EXTRA_EMAKE from ebuild,
>> > but I find this rather ugly (if not even forbidden by some PMS
>> > magic?)
>> 
>> EXTRA_EMAKE isn't mentioned by the PMS. Do all package managers
>> support this variable? Portage does since 2004 at least.

> EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use
> variable for users who need to pass something specific to make.

You are right, of course. (And this had been clarified before:
)

I guess the following ebuilds should be fixed then:

   eclass/bsdmk.eclass
   eclass/python.eclass
   eclass/scons-utils.eclass
   dev-db/redis/redis-2.2.12.ebuild
   dev-db/redis/redis-2.4.4-r1.ebuild
   dev-db/redis/redis-2.4.7.ebuild
   dev-db/redis/redis-2.4.8.ebuild
   dev-db/redis/redis-2.4.10.ebuild
   dev-db/redis/redis-2.4.13.ebuild
   gnome-base/gconf/gconf-2.32.4.ebuild
   net-misc/mico/mico-2.3.13-r5.ebuild
   sci-chemistry/ccp4-apps/ccp4-apps-6.1.3-r10.ebuild
   sys-fs/udev/udev-171-r5.ebuild

Ulrich

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[julian]

On 05/12/2012 06:50 PM, Samuli Suominen wrote:
> Example,
> 
> - Package is using autotools.
> - The default phase like below works for the package:
> 
> src_install() {
> emake DESTDIR="${D}" install
> dodoc README
> }
> 
> So when writing a new ebuild you would only add:
> 
> DOCS="README"
> 
> And be done with it. Then the next version of the package needs extra
> argument passed to emake install, for example:
> 
> src_install() {
> emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
> dodoc README
> }
> 
> So you are /forced/ to write entire src_install() while you only want to
> append one argument to emake install.
> 
> The current workaround for this is to use EXTRA_EMAKE from ebuild, but I
> find this rather ugly (if not even forbidden by some PMS magic?)
> 
> Can we make econf in src_configure, emake in src_compile, and emake
> install in src_install accept arguments "$@" in EAPI=5, please?
> 
> Relavent bug is http://bugs.gentoo.org/364343
> 
> - Samuli
> 

I find this a good idea and since it's optional it does not add
unnecessary complexity.

Re: [gentoo-dev] Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)

[hasufell]

On 05/12/2012 06:50 PM, Samuli Suominen wrote:
> Example,
> 
> - Package is using autotools.
> - The default phase like below works for the package:
> 
> src_install() {
> emake DESTDIR="${D}" install
> dodoc README
> }
> 
> So when writing a new ebuild you would only add:
> 
> DOCS="README"
> 
> And be done with it. Then the next version of the package needs extra
> argument passed to emake install, for example:
> 
> src_install() {
> emake DESTDIR="${D}" init_d_path="/usr/share/doc/${PF}/examples" install
> dodoc README
> }
> 
> So you are /forced/ to write entire src_install() while you only want to
> append one argument to emake install.
> 
> The current workaround for this is to use EXTRA_EMAKE from ebuild, but I
> find this rather ugly (if not even forbidden by some PMS magic?)
> 
> Can we make econf in src_configure, emake in src_compile, and emake
> install in src_install accept arguments "$@" in EAPI=5, please?
> 
> Relavent bug is http://bugs.gentoo.org/364343
> 
> - Samuli
> 

I find this a good idea and since it's optional it does not add
unnecessary complexity.

[gentoo-dev] Re: License groups in ebuilds

[Torsten Veller]

* Kent Fredric :
> I'd welcome groups so we can have a "Perl_5" group. The lions share of
> modules published on CPAN are licensed "Under the same license as Perl
> 5 Itself", which implies "|| ( GPL-2 Artistic-1 )"

Perl is licensed as

| This program is free software; you can redistribute it and/or modify
| it under the terms of either:
|
|   a) the GNU General Public License as published by the Free
|   Software Foundation; either version 1, or (at your option) any
|   later version, or
|
|   b) the "Artistic License" which comes with this Kit.

The perl-module.eclass offers a default LICENSE as
LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}"

So if a distribution uses "the same license as Perl 5 itself" you can
just drop the LICENSE from the ebuild (as long no former eclass sets its
own LICENSE).

I've further added comments to the LICENSE in the ebuilds if it does not
use "the same terms as the Perl 5 programming language system itself"
but "or-later" group of licenses (like GPL-2+ or Artistic+...).
-- 
Regards

Re: [gentoo-dev] Re: License groups in ebuilds

[Ciaran McCreesh]

On Sat, 12 May 2012 21:05:06 +0200
Torsten Veller  wrote:
> The perl-module.eclass offers a default LICENSE as
> LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}"
> 
> So if a distribution uses "the same license as Perl 5 itself" you can
> just drop the LICENSE from the ebuild (as long no former eclass sets
> its own LICENSE).

That's definitely not going to work if the 'inherit' comes at the top
of the ebuild, and is severely dodgy if it doesn't...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] Re: RFC: Add new remote-id types in metadata.dtd

[Torsten Veller]

* Corentin Chary :
> On Sat, Apr 21, 2012 at 03:33:18PM +1200, Kent Fredric wrote:
> > { "term": { "status":"latest"} },
> > { "term": { "module.authorized":"true"}}

What does this mean?
- "latest"? this term looks like maintenance work.
- what is "authorized"?

It doesn't even list "Moose" for Moose?
02packages.details.txt.gz lists 72 package names for Moose-2.0602.

> --- a/dev-perl/Moose/metadata.xml
> +++ b/dev-perl/Moose/metadata.xml
> @@ -3,6 +3,17 @@
>  
>perl
>
> +Class::MOP
> + type="cpan-module">Moose::Meta::Attribute::Native::Trait::Counter
> + type="cpan-module">Moose::Meta::Attribute::Native::Trait::String
> +Moose::Meta::Method::Delegation
> + type="cpan-module">Moose::Meta::TypeConstraint::Role
> + type="cpan-module">Moose::Meta::Attribute::Custom::Moose
> +Moose::Meta::Attribute
> +Moose::Meta::Method
> +Moose::Error::Croak
> +Moose::Util::MetaRole
> +Moose::Role
>  Moose
>
>  

[gentoo-dev] Re: License groups in ebuilds

[Torsten Veller]

* Ciaran McCreesh :
> On Sat, 12 May 2012 21:05:06 +0200
> Torsten Veller  wrote:
> > The perl-module.eclass offers a default LICENSE as
> > LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}"
> > 
> > So if a distribution uses "the same license as Perl 5 itself" you can
> > just drop the LICENSE from the ebuild (as long no former eclass sets
> > its own LICENSE).
> 
> That's definitely not going to work if the 'inherit' comes at the top
> of the ebuild, and is severely dodgy if it doesn't...

What doesn't work?
-- 
Regards

Re: [gentoo-dev] Re: License groups in ebuilds

[Ulrich Mueller]

> On Sat, 12 May 2012, Ciaran McCreesh wrote:

> On Sat, 12 May 2012 21:05:06 +0200
> Torsten Veller  wrote:
>> The perl-module.eclass offers a default LICENSE as
>> LICENSE="${LICENSE:-|| ( Artistic GPL-1 GPL-2 GPL-3 )}"
>> 
>> So if a distribution uses "the same license as Perl 5 itself" you can
>> just drop the LICENSE from the ebuild (as long no former eclass sets
>> its own LICENSE).

> That's definitely not going to work if the 'inherit' comes at the top
> of the ebuild, and is severely dodgy if it doesn't...

I have to agree with Ciaran. The eclass should simply assign LICENSE
unconditionally. Ebuilds can override it if necessary.

And if an ebuild inherits two eclasses that both define LICENSE, then
it's probably better if the ebuild contains its own explicit
definition.

Ulrich

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Paweł Hajdan, Jr.]

On 5/12/12 6:28 PM, Rich Freeman wrote:
> On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr."
>  wrote:
>> The idea is that if you only fix in ~arch, you risk a serious and
>> _known_ regression in stable, which could be easily avoided.
> 
> How can you have a regression in stable if stable has the bug already?

Let me explain in more detail. Suppose you have package foo, and you fix
a compile error with say qt-4.8, but the fix stays in ~arch. Now qt-4.8
is getting stabilized, and if we don't also grab the ~arch foo, stable
foo becomes broken.

Similar thing applies to e.g. gcc updates. I remember a reminder to use
gcc tracker bugs and include precise info which version of a package
works with more recent gcc, to make sure ~arch has the fixes when given
gcc version goes ~arch, and same for stable.

> I see the value when we're talking about security bugs, or very
> critical bugs, but for the run-of-the-mill minor issues that are the
> majority of bug reports I don't see the value in keeping bugs open for
> a month or two just to track that the inevitable hasn't happened yet.

Agreed. I'm talking about compile errors or crashes here. I've really
seen arches stabilizing packages with known problems, just having closed
bugs because "the fix is in ~arch".

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Rich Freeman]

On Sat, May 12, 2012 at 4:01 PM, "Paweł Hajdan, Jr."
 wrote:
> Agreed. I'm talking about compile errors or crashes here. I've really
> seen arches stabilizing packages with known problems, just having closed
> bugs because "the fix is in ~arch".

We might already be on the same page, but I think the bar to set for
stable is that the new build must be overall at least as good as the
previous one.  Having known issues isn't necessarily a problem as long
as overall the level of quality is maintained (all software has bugs -
some teams are just better about knowing about them).

If foo-3 is stable, and foo-4.1 introduces a bug, and foo-4.2 fixes
that bug, then I agree that stablizing foo-4.1 might be a mistake.  On
the other hand, if foo-3 has 30 bugs, and foo-4.1 has 20 bugs, and
foo-4.2 has 25 bugs (just not that one in particular), then it might
still make sense to go with 4.1 in the short term.  Obviously not all
bugs are equal.

This is why maintainers in general should be controlling what packages
get STABLEREQ'ed, and for important packages it is best to make this
decision as a team.  Is there really a sense that this is a big
problem?  I'm sure it happens - but AFAICT the effort required to
prevent this might not be worth it except in isolated cases.

Rich

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Andreas K. Huettel]

> I noticed a general tendency to close bugs affecting stable before
> pushing the fix to stable.
> 
> One recent example is ,
> but there are more.

Not about the general question, but about this specific bug... I never really 
expected the Calligra release to take so long. KOffice is basically dead code, 
and will be removed as soon as Calligra goes stable (and I intend to file the 
stablerequest tomorrow). 

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfri...@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Andreas K. Huettel]

> I noticed a general tendency to close bugs affecting stable before
> pushing the fix to stable.
> 
Right.

> The idea is that if you only fix in ~arch, you risk a serious and
> _known_ regression in stable, which could be easily avoided.
>
As already detailed by others, most of the time these bugs involve problems 
that existed in stable all the time and were fixed in a newer ~arch version. 
So, no regression.

While I understand and applaud your intentions, I dont really intend to keep 
gazillions of bugs open until the last arch has closed the last stablerequest. 
Just for the simple reason that this is dead wood in bugzilla, and blocking 
the view to bugs that actually still need fixing. Also, we dont necessarily 
know from the beginning which revision will go stable.

(BTW, x86 is a bit behind at the moment. :)

We might think about a dedicated application for tracking stabilizations, 
instead of using bugzilla. Alternatively, one could extend bugzilla in a way 
that each closed bug report MUST contain an affected package version *range*.

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfri...@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-dev] RFC: check for enewuser, enewgroup outside of pkg_setup

[Michael Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/19/2011 11:44 PM, Mike Frysinger wrote:
> this is why we allow people to pick the appropriate step.  ebuilds
> should be using pkg_{pre,post}inst unless the user/group is needed
> at src_* time. -mike

I noticed a rather annoying test inside enewuser for existence of the
provided "shell" path in the filesystem ( user.eclass lines 153-156 ).

If you want to create an user and set the shell variable to an program
you just emerge, you have to call it from pkg_postinst.

(The example was a trivial desktop manager x11-misc/trivdm in [1])

[1]
http://git.overlays.gentoo.org/gitweb/?p=dev/xmw.git;a=tree;f=x11-misc/trivdm

- -- 
- --
Gentoo Dev
http://xmw.de/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk+u6KAACgkQknrdDGLu8JA+awD+K7HLWLkd+6eF+uNteODtIJxC
rM46lOPUc7WDf3TXkHoA/job97V3eGMSamAHKp2+kgh7nz1z0VmmNqKxxyD26UE7
=zq6G
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Walter Dnes]

On Fri, May 11, 2012 at 12:59:22AM +, Duncan wrote

> It may very well be that a fork is thus required.  I guess we wait and 
> see.  But I don't see the kde folks being willingly subsumed into a 
> gnomeos black hole, and time and again, floss history has demonstrated 
> that when there's an immediate need, forks do occur.  Both gnome and kde 
> have their forks in recent history, xorg is a fork, there's the glibc and 
> gcc history, etc.  If integration gets too close, a fork /will/ happen.

  There already is a lightweight udev implementation ("mdev") included
in busybox.  Given busybox's philisophy and goals, we can be certain
that mdev will remain lightweight.  I'm not a programmer or developer,
but I was annoyed enough to start what became
https://wiki.gentoo.org/wiki/Mdev  BTW, there is a sort of "udev rules"
equivalant.  See http://git.busybox.net/busybox/plain/docs/mdev.txt

-- 
Walter Dnes