Re: [gentoo-portage-dev] [PATCH v2] Support different compressors for binary packages

[Michał Górny]

On nie, 2017-07-30 at 00:56 +0200, Manuel Rüger wrote:
> Pushed as:
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=cff2c0149142843316e1851c2e73bcec30f08471
> 
> Thanks for the patient reviews, Zac!
> 

I'm sorry for noticing this only now when I'm enabling it but we have
already:

PORTAGE_COMPRESS
PORTAGE_COMPRESS_FLAGS
^^

and you've added:

BINPKG_COMPRESSION
   ^^^
BINPKG_COMPRESSION_ARGS
   

Wouldn't it be better to at least try having consistent variable naming?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-portage-dev] [PATCH v2] Support different compressors for binary packages

[Zac Medico]

On Sat, Jul 29, 2017 at 3:56 PM, Manuel Rüger  wrote:
> Pushed as:
> https://gitweb.gentoo.org/proj/portage.git/commit/?id=cff2c0149142843316e1851c2e73bcec30f08471
>
> Thanks for the patient reviews, Zac!
>
> Cheers,
> Manuel

I've added an early warning for invalid BINPKG_COMPRESSION here:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=fa1ba6318e114cd9f3bb5b4e61ed3dab7521bc19

I guess it might be annoying to make it fatal, since people might have
BINPKG_COMPRESSION before their desired compressor is installed?
-- 
Thanks,
Zac

[gentoo-dev] [PATCH] toolchain.eclass: Remove kludge that blocks gcc-6+ on sys-libs/uclibc-ng systems

[Joshua Kinard]

The following kludge is present in toolchain.eclass, in 
toolchain_pkg_pretend():

[[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
die "Sorry, this version does not support uClibc"

The below patch removes this.  I've been running a gcc-6-built,
sys-libs/uclibc-ng in chroot for some time now, have completed several
catalyst runs, and am at the tail end of a fresh install of a
sys-libs/uclibc-ng userland on actual MIPS hardware.

Signed-off-by: Joshua Kinard 
---
 eclass/toolchain.eclass |3 ---
 1 file changed, 3 deletions(-)

--- a/eclass/toolchain.eclass.orig  2017-07-29 19:06:30.894211203 -0400
+++ b/eclass/toolchain.eclass   2017-07-29 19:06:40.514211133 -0400
@@ -375,9 +375,6 @@ toolchain_pkg_pretend() {
"in your make.conf if you want to use this version."
fi
 
-   [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
-   die "Sorry, this version does not support uClibc"
-
if ! use_if_iuse cxx ; then
use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled 
due to USE="-cxx"'
use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler, 
disabled due to USE="-cxx"'

Re: [gentoo-portage-dev] [PATCH v2] Support different compressors for binary packages

[Manuel Rüger]

Pushed as:
https://gitweb.gentoo.org/proj/portage.git/commit/?id=cff2c0149142843316e1851c2e73bcec30f08471

Thanks for the patient reviews, Zac!

Cheers,
Manuel

On 28.07.2017 18:24, Zac Medico wrote:
> The patch is looking really good now. Thanks for working on this!
> 
> On Fri, Jul 28, 2017 at 2:59 AM, Manuel Rüger  wrote:
>> @@ -518,6 +526,26 @@ def doebuild_environment(myebuild, mydo, myroot=None, 
>> settings=None,
>> mysettings["KV"] = ""
>> mysettings.backup_changes("KV")
>>
>> +   binpkg_compression = mysettings.get("BINPKG_COMPRESSION", 
>> "bzip2")
>> +   try:
>> +   compression = _compressors[binpkg_compression]
>> +   except KeyError as e:
>> +   writemsg("Warning: Invalid or unsupported 
>> compression method: %s" % e.args[0])
>> +   else:
>> +   try:
>> +   compression_binary = 
>> shlex_split(varexpand(compression["compress"], mydict=settings))[0]
>> +   except IndexError as e:
>> +   writemsg("Warning: Invalid or unsupported 
>> compression method: %s" % e.args[0])
>> +   else:
>> +   if find_binary(compression_binary) is None:
>> +   missing_package = 
>> compression["package"]
>> +   writemsg("Warning: File compression 
>> unsupported %s. Missing package: %s" % (binpkg_compression, missing_package))
> 
> It's going to be very helpful if we add some code to detect this case
> in emerge's action_build function, and exit unsuccessfully if the
> global BINPKG_COMPRESSION setting is invalid or the required package
> is missing. This will ensure that people don't build a bunch of binary
> packages, only to find out later that their BINPKG_COMPRESSION setting
> was ineffective.
> 




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Walter Dnes]

On Fri, Jul 28, 2017 at 05:56:25PM -0400, William L. Thomson Jr. wrote

> If upstream does a new release, fixes bugs. Gentoo marks a previous
> release stable. It is stabilizing a package with issues fixed upstream.
> That does not make sense. Gentoo issues maybe good, but not upstreams.
> 
> I maintained packages like iText which used to have a 30 day release
> cycle. Up till recently Jetty was about the same. As a end user, I
> needed the bug fixes. Not the delay for it be marked stable.
> 
> I stopped running Redhat long ago due to time to vet updates. I run
> Gentoo for the speed of being able to package and test out new code.

  What I get out of this discussion is that some people prefer to run
~arch versus stable arch.  I have no problem with that.  But I do object
to dropping "stable" altogether.  I personally run stable with the rare
occasional unstable package, where it's either not available as stable,
or the unstable version fixes a bug in the stable version.  And just for
kicks I'm running gcc 6.3.0.

  It's one thing to rush-stabilize a new package that fixes a security
hole.  But I don't see the point of rush-stabilizing everything "just
because".  I recommend mostly keeping our current setup, with one
change, i.e. allowing security-fix ebuilds to go "stable" immediately.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[David Seifert]

On Sat, 2017-07-29 at 19:41 +0300, Mart Raudsepp wrote:
> > why take away the stable choice?
> 
> I think it is rather clear that stable keywords aren't going anywhere
> for architectures like amd64. I suggest we drop all of the subthreads
> on this topic and get back to other interesting thoughts (which may
> include dropping stable for some other arches of course; I mean doing
> it for all doesn't deserve e-mails imo).
> 
> 
> Mart
> 

I demand you stop asking for dropping stable for "some other arches",
otherwise I might have to stop arch testing on ppc and sparc.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Christopher Head]

On Tue, 25 Jul 2017 09:22:08 +0200
Dirkjan Ochtman  wrote:

> Second, I believe a lot of the value in our stable tree comes *just*
> from the requirement that stabilization is only requested after 30
> days without major bugs/changes in the unstable tree. Assuming there
> are enough users of a package on unstable, that means important bugs
> can be shaken out before a version hits stable. This could mean that
> potentially, even if we inverted our entire model to say we
> "automatically" stabilize after a 30-day period without major bugs,
> we hit most of the value of the stable tree with again drastically
> reduced pain/work.

I’m a stable user when I can be. I use Gentoo for the configurability,
not for instant access to the newest versions of things.

I think this is a fairly reasonable proposal if stabilization is
otherwise happening too slowly right now. If 30 days with no bugs plus
an automated successful build against an otherwise-stable set of
dependencies led to an automatic stabilization, I’d be fine with that.
Some clarification would be needed on what bugs block stabilization,
and of course there would need to be a flag that maintainers could add
to specific ebuilds to indicate whether or not they’re stabilization
candidates (though I wonder if it would be better to flag the ones that
*aren’t* candidates, rather than the ones that *are*).
-- 
Christopher Head


pgpnLOp9yoUTL.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andrew Savchenko]

On Fri, 28 Jul 2017 12:44:20 +0200 Andreas K. Huettel wrote:
> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> > 
> > I hold a perhaps radical view: I would like to simply remove stable.
> > 
> > I continue to feel that maintaining two worlds (stable+unstable)
> > carries with it an unneccessary cost.
> > 
> 
> That's not feasible. It would kill off any semi-professional or professional 
> Gentoo use, where a minimum of stability is required. 
> 
> (Try keeping ~10 machines on stable running without automation. That's 
> already 
> quite some work. Now try the same with ~arch. Now imagine you're talking 
> about 
> 100 or 1000 machines.)
 
~50 hosts here on ~arch. Stable vs unstable is not an issue for
production. The main problem (at least in my case) is upgrade path,
especially with hosts not that often updated.

Upgrade of Gentoo-based production hosts takes considerable time,
not just due to compilation time and issues, but due to the need to
update dozens (sometimes hundreds) of config files properly and
this process can't be fully automated.

Another problem is short support time: only update path for systems
up to one year old is supported more or less. IRL even half year
old system may be PITA for a full update. To make it worse there
are cases when people deliberately make such updates harder: some
developers are refusing to set minimal version requirements for
dependencies if dependency versions below minimal were below latest
stable 1 year age. While such behaviour is within established
policies I frankly do not understand such devs: having
>=cat/foo-1.2.3 instead of cat/foo doesn't hurt, but makes life of
fellow users much easier.

Best regards,
Andrew Savchenko


pgplBwoP5YPz9.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Mart Raudsepp]

> why take away the stable choice?

I think it is rather clear that stable keywords aren't going anywhere
for architectures like amd64. I suggest we drop all of the subthreads
on this topic and get back to other interesting thoughts (which may
include dropping stable for some other arches of course; I mean doing
it for all doesn't deserve e-mails imo).


Mart

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andreas K. Huettel]

Am Freitag, 28. Juli 2017, 23:12:26 CEST schrieb A. Wilcox:
> 
> At least I have a good reason to unsubscribe now.
> 
> 
> Farewell,
> --arw
> 

Please don't take William as a typical Gentoo developer. He isn't.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andrew Savchenko]

On Thu, 27 Jul 2017 18:12:52 -0500 Denis Dupeyron wrote:
> On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich 
> wrote:
> 
> > TL;DR;TL;DR:
> >
> [...]
> 
> Here's a data point you may, or may not, find relevant. in 16 years of
> using Gentoo exclusively, the only one time I used stable on one machine
> for about 2 years it ended up being much more of a pain than unstable.
> Actually, I can't say I have anything to complain about unstable. On my
> critical machines I snapshot the system subvolume before I update. I can't
> remember the last time I had to roll back.

+1
I do not use stable, even in production. Too few packages, too old
versions, too long time to stabilize newer versions. I'm just OK
with ~arch.

> I'm sure most will disagree with me but since you're indirectly asking for
> my opinion here it is: I think people working on stable are wasting their
> time. But who am I to stop them...

I support stable in my packages, but mostly because I have to. One
of the real benefits from the stable for me is stabilization
process which sometimes uncovers otherwise undetected problems.

Of course there are people who use stable, I respect their opinion;
they have different use cases, practices, experience. So I'm not
asking to abandon stable, just explaining that for me and my cases
it is mostly useless.

Best regards,
Andrew Savchenko


pgprrqrPZspmA.pgp
Description: PGP signature