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

[Daniel Campbell]

On 07/28/2017 12:44 PM, Alec Warner wrote:
> 
> 
> On Fri, Jul 28, 2017 at 3:44 AM, 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.
> 
> 
> So my argument (for years) has been that this is the right thing all along.
> 
> If people want a stable Gentoo, fork it and maintain it downstream of
> the rambunctious rolling distro. 
>  
> 
> 
> (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.)
> 
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org 
> Gentoo Linux developer (council, perl, libreoffice)
> 
> 
Why would we replicate that when Arch has been in that cavalier role for
over a decade? Stability is important to all users; some simply have a
lower tolerance for faults. It also gives us a reliable "product" for
others to rely on or even dogfood. I personally run on ~arch, but if I
were to put a friend on Gentoo, I'd want something that will be pretty
easy-going until they learn the skills to take on ~arch, bug reports, etc.

For many -- especially developers -- stable is only a letter away from
"stale", and that's fine. Some run mixed keywords, or go full ~arch. One
of the core values of Gentoo is choice; why take away the stable choice?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

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

[Rich Freeman]

On Fri, Jul 28, 2017 at 3:44 PM, Alec Warner  wrote:
>
> On Fri, Jul 28, 2017 at 3:44 AM, 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.
>
>
> So my argument (for years) has been that this is the right thing all along.
>
> If people want a stable Gentoo, fork it and maintain it downstream of the
> rambunctious rolling distro.
>

What is the difference between forking the repository, and just
maintaining a keyword inside the same repository, besides the former
being easier to integrate into QA/etc?

People who are interested in working on stable already do so, and
people who are not for the most part shouldn't be bothered by it.  In
the cases where stable has caused issues with maintainers the council
has generally dropped arches from stable support so that repoman won't
complain when packages are removed.

I won't say that having stable costs us nothing, but I think the cost
is pretty low.  Asking people who want stable to leave isn't going to
make things any better.

-- 
Rich

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

[William L. Thomson Jr.]

On Fri, 28 Jul 2017 21:45:57 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:

> William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
> excerpted:
> 
> > It seems odd that upstream will release a package. Just for
> > downstream to consider it not stable. Did it get messed up during
> > packaging? Did it get messed up by the distro? The whole lag thing
> > does not make sense for Gentoo. Sooner released and tested on
> > Gentoo. Sooner bugs can be founded, reported back to upstream, etc.
> > Speeds up development. That is Gentoo's role in FOSS IMHO.  
> 
> Not so odd.  Gentoo's arch-stable has a different meaning than
> upstream's stable.  As a long time gentooer I'm surprised you weren't
> aware of this already.

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.

-- 
William L. Thomson Jr.


pgpjA1gvTVSJQ.pgp
Description: OpenPGP digital signature

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

[Duncan]

William L. Thomson Jr. posted on Fri, 28 Jul 2017 16:10:42 -0400 as
excerpted:

> It seems odd that upstream will release a package. Just for downstream
> to consider it not stable. Did it get messed up during packaging? Did it
> get messed up by the distro? The whole lag thing does not make sense for
> Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be
> founded, reported back to upstream, etc. Speeds up development. That is
> Gentoo's role in FOSS IMHO.

Not so odd.  Gentoo's arch-stable has a different meaning than upstream's 
stable.  As a long time gentooer I'm surprised you weren't aware of this 
already.

In general (individual packages may differ somewhat on a case-by-case 
basis, one variant being packages where gentoo /is/ upstream and ~arch is 
thus used for upstream unstable testing to some degree)...

Gentoo's stable doesn't really relate to upstream stable except that 
upstream betas and the like (well, short-term ones, not the ones that 
last years without a non-beta release...) aren't normally considered 
stable candidates because they're not released by upstream as such.  
Instead, gentoo's stable means that the packaging -- the ebuild script, 
the eclasses it calls, and the eapi as encoded in pms and deployed by the 
pm -- is considered tested and stable on a particular arch.  Gentoo-
stable also includes proper integration, making sure the header files, 
libs, configuration, documentation, etc, all end up in the place gentooers 
expect them to be, that they build with our particular toolset, etc.

Similarly, upstream-unstable isn't supposed to be a candidate for ~arch 
either, because ~arch is supposed to be upstream stable that simply 
hasn't yet had enough testing of its gentoo packaging and integration in 
ordered for that particular package to be declared stable.

That's one reason why ~arch normally works so well for those prepared to 
manually deal with the occasional packaging or integration hiccup, missed 
or incorrect dependency, failed merge due to conflict with existing files 
because upstream moved something and the package hasn't yet adapted to 
it, etc -- it's releases that upstream has already declared reasonably 
stable, that simply aren't yet sufficiently tested in terms of the gentoo 
packaging and integration, and if a user's willing to deal with the 
occasional hiccup there it should otherwise be as stable as the upstream 
declaration.

Which is why people like me find ~arch quite stable -- it /should/ be for 
us, as it's upstream stable, and we're prepared to deal with the minor 
dependency and integration issues, etc, that the process of gentoo 
stabilization is intended to fix.

The problem this thread is seeking to at least incrementally tweak toward 
the better is that the above only works for people on stable, when people 
actually declare a package stable when there's no serious bugs left after 
the testing period.  Sometimes they forget, packages drop thru the 
cracks, etc, and stable users get further behind than they would be if 
policies were actually being followed.

And perhaps more to the point, on the minor archs which tend to be the 
bottleneck, sometimes there's simply not the resources, either 
sufficiently interested people with the time (who are volunteers after 
all, so interest and time can't be commanded) or arch hardware or both, 
available to do those stabilizations.  The proposal here hopes to 
automate much of the process as well as standardize it, hopefully 
alleviating that bottleneck.

Tho as I've said before, as one who /is/ prepared to deal with the 
occasional packaging or integration issue and thus finds ~arch perfectly 
usable, I'd personally have no problem with dropping stable, it's just 
that I know it to be a practical impossibility, because were we to do so, 
instead of freeing that time to work on what's now ~arch, we'd simply 
lose most of the volunteers who have a major interest in stable.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

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

[William L. Thomson Jr.]

On Fri, 28 Jul 2017 16:12:26 -0500
"A. Wilcox"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 28/07/17 15:10, William L. Thomson Jr. wrote:
> > Gentoo is as stable as YOU make it  
> 
> And by "YOU", that would be the people writing ebuilds and committing
> them without test suites or integration testing of any kind.  

I am not one of those. I am an outsider. A user, outside ebuilder :)

Having packaged hundreds of Java packages. I do not bother with the
tests. They can take just as long if not longer to get running than the
package itself. I find best testing is real world usage.

>The devs
> who yell and complain all day about "standards" and "not breaking the
> tree" then go and break the tree and violate any standard ever set.

In most any project, breaking the tree/master is frowned on, but
happens. Long as its speedily fixed, all is well.

> This attitude of "the user is to blame" is the reason I moved Adélie's
> upstream elsewhere.  

I did not mean to imply the user was to blame per se. If you buy a car,
do not maintain it, and it falls apart. Is it the manufacturers fault?

Gentoo is not your average "car" or distro. It requires considerable
more work. The result can be better and save considerable time. Yes I
know I just contradicted myself. 

When I was racing, they said
"A fast lap around the track is a slow lap in the cockpit".

The time saving in Gentoo in part is the rolling aspect, and gained
over long periods of time. Upfront you spend considerable time.
The more time spent, the smoother and faster things go.

In part why I tell many not to run it.  They are not going to put in
the time upfront to ensure it works for them in the long run. If the
are not going to put in the time. They likely should not own high end
car, that require abnormal maintenance in ways.

> I am still running Gentoo on a few production
> servers, but this whole thread and /especially/ this message has made
> me realise I'm probably better off with Fedora until Adélie is ready.

For many other distros maybe better suited. There are quite many.
FYI Enlightenment.org runs everything on Gentoo. They have had
discussions of moving away etc. I stay out of it.

What works for one is not the best for other. Gentoo is not the best
distro for everyone. It is really up to each to decide. Gentoo to me is
a Development distro. Which should not be seen the same as many others.

-- 
William L. Thomson Jr.


pgpz0HU8poHZG.pgp
Description: OpenPGP digital signature

[gentoo-dev] Project:Bazaar has no members now!

[Michał Górny]

Hi, everyone.

It seems that recently the last member has left the Bazaar project [1].
FWICS, the project was focused on maintaining packages related to Bazaar
VCS (list below). I'm not sure if that's really a worthwhile reason to
run a whole project -- we don't have git, Mercurial and so on projects
after all.

If you're interested in the Bazaar project as-is, please feel free to
join it (and reply here). If nobody joins the project in 14 days, I will
disband it and drop the packages to maintainer-needed or their other
maintainers.

The packages include:

a. packages maintained only by bazaar@ (-> maintainer-needed):

dev-vcs/bzr-explorer
dev-vcs/bzr-git
dev-vcs/bzr-gtk
dev-vcs/bzr-rewrite
dev-vcs/bzr-xmloutput
dev-vcs/bzr
dev-vcs/bzrtools
dev-vcs/qbzr

b. packages maintained by tetromino + bazaar@:

// note that tetromino has a very low activity and did not reply to any
// of my mails about it, so it's practically maintainer-needed

dev-python/python-fastimport
dev-vcs/bzr-fastimport
dev-vcs/git-bzr-ng

c. packages maintained by bazaar@ + python (+ openstack):

// (we can take them)

dev-python/subunit
dev-python/subvertpy
dev-python/testtools

[1]:https://wiki.gentoo.org/wiki/Project:Bazaar

-- 
Best regards,
Michał Górny


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

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

[William Hubbs]

On Thu, Jul 27, 2017 at 07:03:25PM -0500, Denis Dupeyron wrote:
> On Thu, Jul 27, 2017 at 6:41 PM, Rich Freeman  wrote:
> >
> > When in the last 16 years was this 2 year period of running stable?
> > The general state of QA has varied quite a bit over that time.
> >
> 
> I would say 3 or 4 years ago, roughly.
> 
> 
> > running unstable systemd has been
> 
> 
> Running unstable doesn't mean being stupid.
 
Exactly. If you are running unstable, you are expected to know how to
pick up the pieces if something breaks. Unstable is not meant for
people who aren't comfortable with occasional breakage.

> > If unstable never breaks chances are we aren't actually using it for its
> > intended purpose, not that we
> > should be deliberately breaking things.
> 
> There's this idea that unstable should break. But the initial idea was that
> unstable is what should be sent straight to stable, barring the occasional
> mistake. Unstable was never meant for ebuilds in development and very much
> in flux because of that. That's what package masks are for.

package masks are specifically for things that are known to cause major
system breakages.

Maintainers test things to the best of their
ability before putting them in the tree, but may not cover all possible
test cases, so packages go to the ~arch tree to get much wider coverage
before they are deamed stable. That is why there is a  recommended delay
of 30 days before the package moves to stable.

William



signature.asc
Description: Digital signature

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

[David Seifert]

On Fri, 2017-07-28 at 15:59 -0400, William L. Thomson Jr. wrote:
> On Fri, 28 Jul 2017 23:10:35 +1000
> "Sam Jorna (wraeth)"  wrote:
> 
> > On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"
> >  wrote:
> > 
> > > 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.)  
> > 
> > And further, try proposing that to management - that you'll be
> > managing hosts on a platform that has no "stable" to speak of.
> 
> The professional/management argument is silly. Most avoid Gentoo.
> Most companies, want to be able to pay for support. Not to mention
> certifications and such for those they hire. None of which Gentoo has
> regardless of stability. Not to mention reputation...
> 
> Those that tend to run Gentoo have their own interest in such.  I
> have
> seen many migrate from rather than to Gentoo. Large companies, who's
> names we would all know. One of the few left is Meetup.com. They run
> Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google,
> Sony, etc. Some tend to hire Gentoo devs...
> 

Seriously, can you please stop your diatribes. I am so absolutely fed
up by your DoS'ing of the ML with your pointless points.

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

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/07/17 15:10, William L. Thomson Jr. wrote:
> Gentoo is as stable as YOU make it

And by "YOU", that would be the people writing ebuilds and committing
them without test suites or integration testing of any kind.  The devs
who yell and complain all day about "standards" and "not breaking the
tree" then go and break the tree and violate any standard ever set.

With the possible exception of mgorny and pacho, I'm not sure if I
have any faith in anyone left in Gentoo.  I knew the political climate
in Gentoo was always yearning for better days, but I could never have
foreseen how bad the technical aspects could become.

This attitude of "the user is to blame" is the reason I moved Adélie's
upstream elsewhere.  I am still running Gentoo on a few production
servers, but this whole thread and /especially/ this message has made
me realise I'm probably better off with Fedora until Adélie is ready.

At least I have a good reason to unsubscribe now.


Farewell,
- --arw


- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJZe6i2AAoJEMspy1GSK50U9MYP/2RhhrDBTaOa11DE5IC5rkSj
1iDYX8m3hr4kFgbHMTtIf+crYaELnZXr5uR5rFTb56q2vgrTs7xHN802W9a8GJV/
uRH1R/FzT3nZ3X0tS5Yz2wq+H7SICd5WQ8241BrkPyXgXcHy7/s2ubmewKnwoQHv
sdUlA0/XCHItTApItmhOosCxaHcuAhQhbynfbSDKW5gN4dtxrnZq03xzNZL3dazh
j23gNjUEaefLb9NlxbEZIxeOqrBbeaMnKjIMjPbPdV4RUqoQup43fognKJ2TPij3
LnN52HmY/ZLgD8RYQwyBui/WuqV62i/vdi/Iy4uPNDZnOMr1va2Wscj5mawnOXcB
hpOEYrhSNykiGT1hyg1LPZqgjfw8ovAuwNU84An9vVAPkvqVGS0fCGN0W2lCT/oV
o2SYJy2IKhkxTay7R2wklCeKTmXqo1yoQjp/zuGMD/pzAgln2h5Pc/9KjiDSo6pn
mPsHOeWINjHqsUHdPeJAGjMkJaksA/my0tpzWyxkCmpxc/CVNa7HDt0HWWd5KkIO
SFv33Cyj7NYVVs+E6c8+C7BCh7XgIB1DoexicFT9vDR7ThiTNU3PJMoYjxv+t3Tp
Z7mUK19z/TQZNVst396AcujrhvyQC2zLbg03sGwRZR6m2GjlcYLeuIbZL6eS43Mc
Pf2A1DrXM6tr4MMtOQXn
=i0I9
-END PGP SIGNATURE-

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

[William L. Thomson Jr.]

Gentoo is as stable as YOU make it

I have run Gentoo exclusively as well for 14+ years, since ~2003. While
my production servers are all mostly stable, none are 100%. All
production systems have some ~arch packages, usually mine. Development
network and desktops/laptops have always been ~arch. I rarely if ever
have issues. I have long felt and state stability on such a
distro/platform is a misnomer.

If your system is unstable, it could be due to the lack of time you
spent making it stable. With some exceptions. Many time stable is more
unstable and has issues, sometimes fixed in ~arch. ~arch can be more
stable than stable.

That being said having been bit recently by a udev update that wanted a
file from /usr/lib, which I have on lvm, so it broke udev and booting
on ~arch. I reverted back, I did not file a bug.

Maybe the core profile/base system is maintained as stable and not, and
all the rest, packages are not stable or unstable, They are masked or
not. Things like tool chain, and base system should be stable. Beyond
that up to a package maintainer to mask or not. Masking new stuff is
underused.

It seems odd that upstream will release a package. Just for downstream
to consider it not stable. Did it get messed up during packaging? Did
it get messed up by the distro? The whole lag thing does not make sense
for Gentoo. Sooner released and tested on Gentoo. Sooner bugs can be
founded, reported back to upstream, etc. Speeds up development. That is
Gentoo's role in FOSS IMHO.

There are other distros if you want rock solid stability all the
way through with minimal effort. Though ever system admin I know has
changed their personal distro a few times due to one issue or another.
Even ones who work for vendors who sell Linux, and they carry 2 laptops.
While I remain on Gentoo, but telling them to avoid Gentoo. Many ran it
before and did not put in the effort. Not why I tell them to avoid.

Gentoo should get back to having the latest of all packages, and
testing integration. It is more a development distro, than mission
critical deployment. That possible and it can be rock solid for
mission critical uses. If the administrators make it such.

Gentoo is as stable as YOU make it

-- 
William L. Thomson Jr.


pgpi2cn00a1i5.pgp
Description: OpenPGP digital signature

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

[William L. Thomson Jr.]

On Fri, 28 Jul 2017 23:10:35 +1000
"Sam Jorna (wraeth)"  wrote:

> On 28 July 2017 8:44:20 PM AEST, "Andreas K. Huettel"
>  wrote:
>
> >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.)  
> 
> And further, try proposing that to management - that you'll be
> managing hosts on a platform that has no "stable" to speak of.

The professional/management argument is silly. Most avoid Gentoo.
Most companies, want to be able to pay for support. Not to mention
certifications and such for those they hire. None of which Gentoo has
regardless of stability. Not to mention reputation...

Those that tend to run Gentoo have their own interest in such.  I have
seen many migrate from rather than to Gentoo. Large companies, who's
names we would all know. One of the few left is Meetup.com. They run
Gentoo as do some others. Seems Tivo does stuff with Gentoo, Google,
Sony, etc. Some tend to hire Gentoo devs...

-- 
William L. Thomson Jr.


pgp8mvKMErOs_.pgp
Description: OpenPGP digital signature

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

[Alec Warner]

On Fri, Jul 28, 2017 at 3:44 AM, 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.
>

So my argument (for years) has been that this is the right thing all along.

If people want a stable Gentoo, fork it and maintain it downstream of the
rambunctious rolling distro.


>
> (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.)
>
> --
> Andreas K. Hüttel
> dilfri...@gentoo.org
> Gentoo Linux developer (council, perl, libreoffice)

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

[Zac Medico]

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.
-- 
Thanks,
Zac

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

[Sam Jorna (wraeth)]

On 28 July 2017 8:44:20 PM AEST, "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.)

And further, try proposing that to management - that you'll be managing hosts 
on a platform that has no "stable" to speak of.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Marek Szuba]

On 2017-07-28 12:43, Andreas K. Huettel wrote:

>> 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.
This. VERY much this. I do not care about having all the latest stuff on
work machines, what I want them is to a) remain up to date
security-wise, and b) actually survive updates. In fact, problems with
the latter was what led us a couple of years ago to quickly conclude
evaluation of a certain other rolling-upgrade operating system.

-- 
MS



signature.asc
Description: OpenPGP digital signature

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

[Andreas K. Huettel]

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.)

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

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

Re: [gentoo-dev] [RFC pre-GLEP] Gentoo Git Workflow

[Andreas K. Huettel]

Am Dienstag, 25. Juli 2017, 10:05:06 CEST schrieb Michał Górny:
> Hi, everyone.
> 
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 
> The basic idea is that the GLEP provides basic guidelines for using git,
> and then we write a proper manual on top of it (right now, all the pages
> about it end up as a mix of requirements and a partial git manual).
> 
> What do you think about it? Is there anything else that needs being
> covered?

TL;DR: I like it; minor comments on the commit message format (surprise). We 
should strive to provide consistent standards for it.


> ===Commit messages===
[...]
> If a bug is associated
> with a change, then it should be included in the summary line as
> #nn or likewise. 

..., for practical reasons in a format that is recognized by willikins. 
So, please DON'T do "... fixes #234987".

I suggest we recommend a plain "... bug 234567 ..."

So far, "bug x" in our repository by default refers to the Gentoo bugzilla, 
and it makes sense to stick with that.


> The tag part is included in the full commit log as an extension to the
> body. It consists of one or more lines consisting of key, followed by a
> colon and a space, followed by value. Git does not enforce any
> standardization of the keys, and the tag format is ''not'' meant for
> machine processing.
> 
> A few tags of common use are:
[...]
> ** Bug: https://bugs.gentoo.org/NN; — to
> reference a bug,
> ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request,
> ** Fixes: https://bugs.gentoo.org/NN; —
> to indicate a fixed bug,

I would like to suggest that *if* such tags are used, we require that they 
should always contain a full URL to an issue tracker or code source.

This allows generic referencing of other bug trackers, leaves developers the 
option to auto-handle github-specific things, and still (for the purists) 
doesn't require mentioning Github in the GLEP.



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

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

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

[Manuel Rüger]

This patch allows to set the compressor for binary packages via a
BINPKG_COMPRESSION variable. BINPKG_COMPRESSION_ARGS allows to specify
command-line arguments for the chosen compressor.
---
 bin/misc-functions.sh  |  6 ++-
 bin/quickpkg   | 62 --
 man/make.conf.5| 25 +
 pym/_emerge/BinpkgExtractorAsync.py| 43 +--
 pym/portage/dbapi/bintree.py   |  8 +--
 .../package/ebuild/_config/special_env_vars.py |  2 +-
 pym/portage/package/ebuild/doebuild.py | 34 ++--
 pym/portage/util/compression_probe.py  | 45 +---
 8 files changed, 186 insertions(+), 39 deletions(-)

diff --git a/bin/misc-functions.sh b/bin/misc-functions.sh
index 58755a1e1..079369313 100755
--- a/bin/misc-functions.sh
+++ b/bin/misc-functions.sh
@@ -453,7 +453,7 @@ __dyn_package() {
# Make sure $PWD is not ${D} so that we don't leave gmon.out files
# in there in case any tools were built with -pg in CFLAGS.
 
-   cd "${T}"
+   cd "${T}" || die
 
if [[ -n ${PKG_INSTALL_MASK} ]] ; then
PROOT=${T}/packaging/
@@ -478,8 +478,10 @@ __dyn_package() {
[ -z "${PORTAGE_BINPKG_TMPFILE}" ] && \
die "PORTAGE_BINPKG_TMPFILE is unset"
mkdir -p "${PORTAGE_BINPKG_TMPFILE%/*}" || die "mkdir failed"
+   [ -z "${PORTAGE_COMPRESSION_COMMAND}" ] && \
+die "PORTAGE_COMPRESSION_COMMAND is unset"
tar $tar_options -cf - $PORTAGE_BINPKG_TAR_OPTS -C "${PROOT}" . | \
-   $PORTAGE_BZIP2_COMMAND -c > "$PORTAGE_BINPKG_TMPFILE"
+   $PORTAGE_COMPRESSION_COMMAND -c > "$PORTAGE_BINPKG_TMPFILE"
assert "failed to pack binary package: '$PORTAGE_BINPKG_TMPFILE'"
PYTHONPATH=${PORTAGE_PYTHONPATH:-${PORTAGE_PYM_PATH}} \
"${PORTAGE_PYTHON:-/usr/bin/python}" 
"$PORTAGE_BIN_PATH"/xpak-helper.py recompose \
diff --git a/bin/quickpkg b/bin/quickpkg
index 4f26ee912..750400592 100755
--- a/bin/quickpkg
+++ b/bin/quickpkg
@@ -8,6 +8,7 @@ import argparse
 import errno
 import math
 import signal
+import subprocess
 import sys
 import tarfile
 
@@ -22,11 +23,13 @@ from portage.dbapi.dep_expand import dep_expand
 from portage.dep import Atom, use_reduce
 from portage.exception import (AmbiguousPackageName, InvalidAtom, InvalidData,
InvalidDependString, PackageSetNotFound, PermissionDenied)
-from portage.util import ConfigProtect, ensure_dirs, shlex_split, _xattr
+from portage.util import ConfigProtect, ensure_dirs, shlex_split, varexpand, 
_xattr
 xattr = _xattr.xattr
 from portage.dbapi.vartree import dblink, tar_contents
 from portage.checksum import perform_md5
 from portage._sets import load_default_config, SETPREFIX
+from portage.process import find_binary
+from portage.util.compression_probe import _compressors
 
 def quickpkg_atom(options, infos, arg, eout):
settings = portage.settings
@@ -50,16 +53,16 @@ def quickpkg_atom(options, infos, arg, eout):
" ".join(e.args[0]))
del e
infos["missing"].append(arg)
-   return
+   return 1
except (InvalidAtom, InvalidData):
eout.eerror("Invalid atom: %s" % (arg,))
infos["missing"].append(arg)
-   return
+   return 1
if atom[:1] == '=' and arg[:1] != '=':
# dep_expand() allows missing '=' but it's really invalid
eout.eerror("Invalid atom: %s" % (arg,))
infos["missing"].append(arg)
-   return
+   return 1
 
matches = vardb.match(atom)
pkgs_for_arg = 0
@@ -108,16 +111,16 @@ def quickpkg_atom(options, infos, arg, eout):
in settings.features))
def protect(filename):
if not confprot.isprotected(filename):
-   return False
+   return 1
if include_unmodified_config:
file_data = contents[filename]
if file_data[0] == "obj":
orig_md5 = 
file_data[2].lower()
cur_md5 = 
perform_md5(filename, calc_prelink=1)
if orig_md5 == cur_md5:
-   return False
+   return 1
excluded_config_files.append(filename)
-   return True
+