Re: [gentoo-dev] Deprecating repoman

2022-03-11 Thread Peter Stuge
Matt Turner wrote:
> repoman is inferior to other tooling mentioned. The other tooling is
> actually run in CI.

The problem seems to be that CI is running something other than
developers run, not the other way around.


> Developers should get the same warnings locally as in CI.

I agree. And developers and their tools should not have to bend to
whatever CI does, I think the other way around makes more sense.


CI doesn't use repoman because of performance issues.

What if pkgcore evolves to provide a portage-compatible API?

Then CI could use repoman without performance problems, and
developers would also enjoy improved performance, without spending
time on replacing tooling which already works for them.

Looking into the future then maybe portage could even come to use
pkgcore for the low-level things that pkgcore does, then even users
could enjoy improved performance.


Right?

//Peter



Re: [gentoo-dev] Maintainer needed: dev-db/sqlite

2022-01-14 Thread Peter Stuge
Mike Gilbert wrote:
> The current (proxied) maintainer is somewhat difficult to work with

Why is Arfrever being treated so bad here? To me, it looks like
you're the one who is difficult to work with. :\


Jakov Smolić wrote:
> From what I've investigated, other major distributions don't apply
> any similar patches which means that we are likely to stop carrying
> most (or even all) of the current patches.

What kind of silly groupthink is this? I expect Gentoo to champion choice.


Mike Gilbert wrote:
> There is an open QA bug [1] regarding the large set of undocumented
> patches that are being applied in the stable ebuilds.

Arfrever is active in the bug you linked, has provided explanations
for the patches and prepared to restructure the patches so that they
can be gated by local USE flags, has made several different concrete
suggestions for possible implementations and requested feedback, but
has received no reply in the bug and instead there's now this
backstabbing discussion on this list.

Really?


//Peter



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Peter Stuge
Mike Gilbert wrote:
> > > It's a waste of time and effort to pepper random ebuilds with checks
> > > for options that everyone should have enabled in the first place.
> >
> > It's not for you to say what everyone should have enabled in their kernel.
> 
> Do you not agree that there are some options that should always be
> enabled, or at least that we can assume are enabled?

"Should be enabled" no, but I agree with the latter - some assumed set
should be fine. I think it would be good if it's (somehow) documented
though.


> To use my earlier example, should every package that uses AF_INET
> check for CONFIG_INET in the kernel?

CONFIG_INET is a perhaps surprisingly tricky example!

A package could e.g. use getaddrinfo() with no address family hint
but because of USE=-ipv6 exclude all AF_INET6 address results and
so end up using AF_INET based on whether it's available in the
running kernel or even based on third party DNS entries.


I'm not sure about the best approach for very basic options,
CONFIG_NET could be another such candidate.

Thinking towards robbat2's proposal (which I like) it might make sense
to try to map requirements of packages, but there will probably be
cases where it can't really be done successfully.

Ultimately that work should not be the responsibility of distribution
package maintainers but something upstreams deliver, similar to systemd
units, but maybe we'll invent it (if noone else has)..


//Peter



Re: [gentoo-dev] moving kernel config checks forward: potential config checking tool

2021-09-27 Thread Peter Stuge
Robin H. Johnson wrote:
> We have some set of packages (A) which collectively depend on one or
> more kernel options being set in specific ways, and the options need to
> REMAIN set if you want the packages to continue work.
..
> Can we consider moving the checks for set A somewhere else, such that we
> don't check the kernel config during package compile & install time, but
> only check it later?

I only see one problem with this; that USE flags could influence which
kernel options are required, which would be useful to know at/before
compile time.


> It would need to keep long-term state about which packages want
> specific options set/unset/modular, as well as short-term state
> about the config from each boot.

It's a cool idea. A standardized solution would be quite nice for the
whole Linux ecosystem.


//Peter



Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-27 Thread Peter Stuge
Mike Gilbert wrote:
> It's a waste of time and effort to pepper random ebuilds with checks
> for options that everyone should have enabled in the first place.

It's not for you to say what everyone should have enabled in their kernel.

There's significant value in ebuilds documenting required kernel options in
a structured manner.

So I welcome simplifications in the checking to achieve millisecond
test times. But the benefit of structured requirements is given even
without any runtime checking at all, as long as required options
continue to be codified /somehow/.


Thank you for your work!

//Peter



Re: [gentoo-dev] Guidance on distributed patented software

2021-09-26 Thread Peter Stuge
Joshua Kinard wrote:
> > I'm not entirely sure what you'd like to ask the libtomcrypt authors.
> > "We think there may be patents, but we don't know. Did you consider
> > that?"
> 
> No, actually, I was thinking something more along the lines of "Hey, are you
> aware of these supposed patent claims about ECC/ECDSA implementations that
> Red Hat says exist, and if so, did you do any research on them that you
> could possibly share that led you to feeling confident to release your
> implementation into the public domain".
> 
> But I am open to better language.

There's not neccessarily a conflict between a patented idea and a
public domain implementation of that idea.

Take a fictional example:

You and I independently invent the same thing. You patent it, then
write and publish an LGPL implementation. I, ignorant of your
accomplishment, later write and publish a different implementation,
placing it in the public domain.

You having a patent doesn't neccessarily matter to me publishing my
implementation.

It can be problematic for *users*. They might violate your patent
terms (or not; it depends on your terms in the patent) if they use
*any* implementation without having licensed the right to use your
patented idea from you. (Of course only until your patent expires.)

What users have to do is determined by the terms set forth in the
patent. E.g.: the QR-code patent has (I believe) not expired yet but
has always permitted using the idea without any explicit license under
the condition that all use is actually spec conformant.

The license for a software isn't connected to patents unless it
explicitly states so, like GPL-3 Section 11 or Apache-2.0 Section 3.
Public domain has no license text, so can have no such language. :)

You seem to expect some due diligence from libtomcrypt authors before
having decided to publish their work and I don't find that reasonable.
I hope I've managed to explain why?


Kind regards

//Peter



Re: [gentoo-dev] Guidance on distributed patented software

2021-09-23 Thread Peter Stuge
Joshua Kinard wrote:
> Hmm, it looks like dropbear is relying heavily on the ecc/ecdsa functions
> provided in libtomcrypt, and that library's homepage states all its code is
> public domain.  Our ebuild has no bindist restrictions on that library.
> Perhaps that is how dropbear, and thus Red Hat, avoids the issues with
> licensing or patents?

Licenses apply to implementations and patents apply to inventions/ideas.

A software license can allow you to theoretically use an implementation
while a patent says no you can't without licensing that right separately.

The reverse is equally possible; an expired patent means that using the
invention/idea is not restricted by the patent anymore, but there may
still be no free/open source implementation (yet).


AIUI USE=-bindist is all three variants (swlicense_says_no || patent_says_no)
while USE=bindist promises that (swlicense_says_yes && patent_says_yes)
is guaranteed to be true at the cost of functionality?


//Peter



Re: [gentoo-dev] [PATCH] Add deblob support only for python3

2021-07-25 Thread Peter Stuge
Sam James wrote:
> > https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html
> > 
> > it seems that it may be possible to need only very simple tools for the
> > deblob program(s).
> 
> Instead of linking to a huge release announcement, could you summarise it?

Fair enough - though the relevant part is the short commentary preceding
the perhaps mechanical release announcement.

The deblob program(s) previously used sed and awk instead of python
or perl and seem to have switched more because of performance than
because of any features in either python or perl. A quick look into
the source code seems to confirm that there's no strong tie to Python.


//Peter



Re: [gentoo-dev] [PATCH] Add deblob support only for python3

2021-07-25 Thread Peter Stuge
Alice wrote:
> +++ b/eclass/kernel-2.eclass
..
> -   PYTHON_COMPAT=( python2_7 )
> +   PYTHON_COMPAT=( python3_{7..10} )

From

https://www.fsfla.org/pipermail/linux-libre/2020-August/003404.html

it seems that it may be possible to need only very simple tools for the
deblob program(s). I think that would be a worthwhile improvement and it
would probably also simplify integration of deblob not only in Gentoo.

That said, if python2_7 is not a thing in Gentoo anymore then the patch
makes sense to me.

I think the discussion on merits concluded well - kernel maintainers who
want can support it. Everyone who considers it pointless can ignore it.
All good.


Kind regards

//Peter



Re: [gentoo-dev] Packages up for grab

2021-07-22 Thread Peter Stuge
Marco Scardovi wrote:
> mail-filter/bogofilter

I'd like to proxy-maintain this.


//Peter



Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-12 Thread Peter Stuge
Ben Kohler wrote:
> Nobody is "disabling choice" here,

Fair! Sorry about the hyperbole.


> a change in defaults doesn't remove your ability to choose something else.

True. My argument is more specificically that setting USE flags by
default in a "low-level" profile goes in the wrong direction.


> And I understand your sentiment that adding more default-on flags goes 
> against YOUR goals of a minimal gentoo, but I'd like to remind you and 
> others that this minimalism is not the goal of every gentoo user.

It's important that this is a low-ish-level profile. Unfortunately Matt
didn't respond to my question/point about profile inheritance.

I don't expect a gentoo desktop system to be minimal. I would however
like being able to build upon a minimal profile (not a desktop one)
with nothing in it, as opposed to having to essentially create a new
profile for each of my configurations.


> I want to be clear that I'm not saying you are wrong, but remember that 
> your perspective is not the only correct one on this topic.

Maybe the discussion should focus on different kinds of profiles?

I'm not concerned about typical "user-facing" profiles here, it can
make plenty sense to enable these USE flags by default in those.


Michael Orlitzky wrote:
> all I personally want is to be reasonably sure what my configurations
> are going to do without having to list every individual package and
> USE flag explicitly.

Exactly this. Unfortunately I've had to give up on it, as USE flags
are set by default here and there, but I'd love to be able to rely
on a minimal starting point that will stay minimal.

Thank you for your mail Michael, you expressed my concern very well.


Kind regards

//Peter



Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-12 Thread Peter Stuge
Matt Turner wrote:
> > > If you can find a case where you wouldn't want to enable one of these
> > > USE flags, please let me know and I'll reconsider my position.
> >
> > My catalyst spec files all have  use: -* foo bar x y z
> > specifically because the defaults are never what I want for any given
> > system. I build desktops, servers, containers, VM appliance images and
> > embedded system, and I know what I want in each one. Especially the
> > latter frequently have only very few USE flags set and I want zero
> > extra dependencies.
> 
> I think you're making a great argument that you'd be completely
> unaffected by any of the suggestions in this thread.

I don't consider needing "use: -*" at all a desirable situation. This
catalyst warning might support that:

Warning!!!
The use of -* in $stage/use will cause portage to ignore
package.use in the profile and portage_confdir. You've been warned!


I see it as a shortcoming of the standard profiles that I have to
essentially create my own in order to get what I want, as opposed
to being able to build upon something truly minimal.


> > > I'd claim most of these packages' bzip2/lzma/zstd USE flags should
> > > be removed in favor of statically enabling them
> >
> > That is the direct opposite of Gentoo's single most core value: choice
> 
> Choice makes sense when there's a legitimate trade-off to be made.

I explained that and why I frequently do not want those USE flags set,
demonstrating that I want choice here.

You can of course dismiss any concern which disagrees with your opinion as
illegitimate. Please do not bother asking questions if that's your style.


> Choice isn't dogma.

Is there a difference between dogma and value? I understand choice to be
a core value in Gentoo. Maybe that's wrong (now)? Core values are more
important than pretty much anything else.

Choice isn't always possible. That's not this case. If choice is indeed
a core value then where choice is pretty easy (this case) in my mind
there needs to be an overwhelmingly strong argument to conciously and
intentionally disable choice.


> > Just don't do it. Kthx.
> 
> This kind of thing is nothing but irritating. Please don't do this.

I'm sorry if it wasn't clear that "Just don't do it. Kthx." meant
exactly what you wrote:

This kind of thing (increase default USE-flags) is nothing but irritating.
Please don't do this.


Kind regards

//Peter



Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-08 Thread Peter Stuge
Matt Turner wrote:
> If you can find a case where you wouldn't want to enable one of these
> USE flags, please let me know and I'll reconsider my position.

My catalyst spec files all have  use: -* foo bar x y z
specifically because the defaults are never what I want for any given
system. I build desktops, servers, containers, VM appliance images and
embedded system, and I know what I want in each one. Especially the
latter frequently have only very few USE flags set and I want zero
extra dependencies.

I completely agree that the default USEs should rather be reduced,
not increased. Isn't this what profile inheritance is for? It would
be great if I didn't essentially have to create my own profile when I
want a very minimal system.


Matt Turner wrote:
> I'd claim most of these packages' bzip2/lzma/zstd USE flags should
> be removed in favor of statically enabling them

That is the direct opposite of Gentoo's single most core value: choice

Just don't do it. Kthx.


//Peter



Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()

2021-06-17 Thread Peter Stuge
Rolf Eike Beer wrote:
> The previous algorithm would scan for all primes for a given number,
> which takes needlessly long.

Please also mention how this caused a problem for you in the commit
message, to help us understand why you're proposing to change this.


> +++ b/eclass/qmail.eclass
> -# @FUNCTION: is_prima
> +# @FUNCTION: is_prime
>  # @USAGE: 
>  # @DESCRIPTION:
>  # Checks wether a number is a prime number

Maybe name the algorithm? Looks like an optimization of the sieve of
Eratosthenes?


>  is_prime() {
>   local number=${1} i
> - for i in $(primes ${number} ${number})
> +
> + if [[ $[number % 2] == 0 ]]; then
> + return 1
> + fi

While 2 itself is prime the above returns 1 for any even number.


> + for ((i = 3; i * i <= number; i += 2))
>   do
> - [[ ${i} == ${number} ]] && return 0
> + if [[ $[number % i ] == 0 ]]; then

An inconsistent space after "% i" here. I don't know what style is correct.


//Peter



Re: [gentoo-dev] EAPI 8 is here!

2021-06-16 Thread Peter Stuge
Sam James wrote:
> * Brings IDEPEND, usev enhancements, --disable-static by default, and more!

How to undo that --disable-static ?

I'm asking both for my own ebuilds and as a regular portage user.


//Peter



Re: [gentoo-dev] Packages up for grabs

2021-06-15 Thread Peter Stuge
David Seifert wrote:
>   mail-filter/bogofilter

In principle I'm interested in proxy-maintaining this but do not have
cycles immediately.

The current ebuild has little special stuff so probably also works for
the #763024 bump without much change - though I'd like to rework the
rather messy database USE logic..


//Peter



Re: [gentoo-dev] Package up for grabs: sys-boot/lilo

2021-06-07 Thread Peter Stuge
Hi Joshua,

Joshua Kinard wrote:
> > The base system project is dropping LILO: it really needs to be
> > maintained by someone who actually uses it.
> 
> I'll claim it.

Awesome, thanks a lot.


> Never took a liking to GRUB.  Simpler is better

+1


> However, I am very time-limited, so I will defer to Hank or Peter if they
> wish to tackle any open bugs and I'll serve as final reviewer, tester, and
> committer.

Fair enough, I'll follow up in the bugs. I think my #741912 patch
works but I want to look closer at the clang/musl suggestions.
Thanks a lot for researching that issue!


//Peter



Re: [gentoo-dev] Package up for grabs: sys-boot/lilo

2021-06-01 Thread Peter Stuge
Mike Gilbert wrote:
> The base system project is dropping LILO: it really needs to be
> maintained by someone who actually uses it.

I also use it.

Hank Leininger wrote:
> I still use/prefer LILO; I'll take a look at the open bugs and
> consider submitting PRs for them & taking on p-m of it.

Hank, please feel free to ping me for another pair of eyes or Cc me on bugs.


//Peter



Re: [gentoo-dev] Gentoo 18th Anniversary Edition - Help Needed

2021-04-20 Thread Peter Stuge
Great idea and happy anniversary! :)

Roy Bamford wrote:
> Here's where I reed your help.

I can't help with that.


Roy Bamford wrote:
> I have a similar media problem with a pile of 5 1/4" floppies. A have a 
> drive that reads all the 5 1/4" formats and a motherboard to connect it 
> to ... until I replace this 12 year old system.
> 
> USB to Floppy interfaces won't do it as they are all made for the data 
> rate used in 3 1/2" floppies.

But with this. Look at these projects:

https://cowlark.com/fluxengine/
https://github.com/keirf/Greaseweazle

And these ready-to-buy products:

https://shop.deviceside.com/prod/FC5025
https://www.kryoflux.com/


Kind regards

//Peter



Re: [gentoo-dev] Idea: User centric kernel configuration

2021-03-11 Thread Peter Stuge
Hi,

Gerion Entrup wrote:
> the Linux kernel has _a lot of_ configuration options, way too many to 
> configure them by hand.

I actually disagree strongly with that; I think it's important to
actively decide what kernels include, and I routinely do, but of
course not everyone will. I've made sure to include a kernel build
when teaching systems administration courses and would again.

As the kernel becomes more complex the threshold for the first
configuration also rises, but it's still completely possible to learn
what you need in order to successfully configure your own kernel.
I guess it's on the order of a weekend project given some basic
understanding of computer architecture and programming.


> This requires a mapping between user oriented "features" and the kernel
> internal configuration options.

So the challenge here is that the kernel is disjoint from user space,
and while the kernel API remains stable over time consumer requirements
such as "docker" or "cryptsetup" will mean different things for
different versions of particular user space software.


> Do you think that it is useful and feasible to combine these two mechanisms?

AFAIK there's no generic method for formal kernel requirements in user
space packages and there's also no sanctioned method for quering
kernel capabilities. The only thing available is /proc/config if that
was enabled in the kernel build, and there are of course reasons to
leave it out, and it only applies to the particular running kernel,
e.g. useless for cross-compilation. There, it would be possible to
read the kernel configuration file if the kernel source code is
available when the userspace package is being built, but that's not
guaranteed.

In Gentoo, linux-info.eclass provides linux_config_exists() to do all
of this, but order to become a widespread success there would have to
be one method for upstreams to maintain these requirements as part of
their packages, rather than forcing the burden on package maintainers
to repeat the same detective task in every single distribution.

I think it would be very useful to create something generic for that,
but that's certainly no small task.

And realistically I only see it succeeding if Linux Foundation decides
to push it onto the world.


> A possible way could be to automatically extract the kernel config
> flags from the wiki pages and map them to Kconfig options.

At very best that will only be valid for some particular point in time,
like current CONFIG_CHECK in ebuilds using linux_config_exists() are
only valid for particular package versions. At worst it's plain wrong
because the requirements have to be reverse-engineered downstream.


//Peter



Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-10 Thread Peter Stuge
Mike Gilbert wrote:
> > > The first big blocker we're going to hit is trustme [3] package that
> > > relies on cryptography API pretty heavily to generate TLS certs for
> > > testing.
> >
> > For which testing? Could it be changed to generate certs differently?
> 
> He is probably referring to the test suite in dev-python/urllib3,
> which uses the python "trustme" package in several places.
> 
> https://github.com/urllib3/urllib3/search?q=trustme
> 
> Someone would need to convince the urllib3 developers to use something
> else to manage certificates in their unit tests.

Ah - non-Gentoo packages - thanks, I understand.

The trustme API isn't very large, so it seems doable to create a
different implementation of it without rust dependencies, add
virtual/trustme and be done?


//Peter



Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-10 Thread Peter Stuge
Michał Górny wrote:
> I'm seriously wondering why I'm wasting so much effort on open source.

Open source only ever works when taking responsibility for one's problems.


> I don't see a good way out of it.

I see a couple. Of course all require some effort.

One was already mentioned; move Gentoo package management from Python
to some compiled language. High effort but maximum independence/reward.

Another option, less effort and less reward, is to investigate how much
CPython portage in fact requires, and make that a special package in Gentoo.

This essentially means a special-purpose fork of CPython, only for running
portage. Obviously portage development must then be comfortable without
using the latest shiny Python language stuff that only future RustPython
will offer. I guess that's not a problem.

Yet another is a variant on the previous, but even less effort and
much less reward; freeze what language stuff is allowed in portage code
and always run portage with some chosen existing/later CPython version.


Like libressl and gtk2 this thread also converges on the common point in
my argumentation: it's not per se bad, and sometimes supremely wise, to
quit chasing the latest version, and rest on a known platform.

Coupled with independent efforts to place security-relevant parts in
isolated environments (see sandbox) - ongoing effort regardless of Python -
I don't see why portage couldn't depend on a CPython interpreter of its own,
some last version that works well and is then copied and renamed.

It seems like that would be rather straightforward.

It might also be a good thing to take portage out of the overall Gentoo
Python picture? I don't know here - this bit is just a guess.


> arrogant zealots who want to destroy everything in their path

LOL, priceless.


> The first big blocker we're going to hit is trustme [3] package that
> relies on cryptography API pretty heavily to generate TLS certs for
> testing.

For which testing? Could it be changed to generate certs differently?

CAs aren't magic. Attached is a basic script of mine.


//Peter


mkca.sh
Description: Bourne shell script


Re: [gentoo-dev] A script to pick next free UID/GID for your acct-* packages

2021-02-09 Thread Peter Stuge
Joonas Niilola wrote:
> There's a script by jkroon in data/api.git
> (https://gitweb.gentoo.org/data/api.git/) that prints the next available
> UID/GID pair for new acct-* packages.

This is super nice! Thanks a lot jkroon!


> It is not forbidden to mix and mash UID/GID between different packages,
> but I'd still suggest to find a new "pair" even if you push just an UID
> or GID. Since we don't seem to be in danger of running out any time soon.

Mh - so the obvious first feature request for the script is to also output
Free UID+GID pairs. Counting them manually in your screenshot I get 36.

That's not a whole lot; just 7% of 500.


//Peter



Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
John Helmert III wrote:
> > Until there's a relevant flaw that will remain unfixed or there is
> > significant incompatibility with infrastructure (recurse my argument)
> > no signs actually exist.
> 
> Waiting until such a problem pops up and bites everyone before doing
> anything about it doesn't sound like a good way to handle it.

I guess that's a matter of opinion. But more importantly, "anything"
can mean a lot, and removing gtk2 is the ultimate sledgehammer.

Deciding to certainly use it at an unknown point in the future seems
unneccessary and premature to me.


> If an application never ports, do you expect the distribution to
> maintain that package ad infinitum?

As always it depends on the required effort.

When keeping the package requires little or no effort I *do* expect it
to not be removed solely because there will be no more releases, which
is really what was stated in the announcement, and why I piped up.


Alec Warner wrote:
>  - I expect gtk2 (the library) to be around for a while. As written it
> gets at least one more release.

Ack. My point isn't about immediate action, rather about what drives decisions.


>  - I expect Gentoo to come after gtk2-only leaf packages pretty hard;
> either to get upstream to port, or to remove them.
>- This is true even if the packages are fully functional with gtk2,
> or don't have other bugs.
>- This is because we will eventually remove gtk2 from the tree
> (which will make these packages unbuildable, and cause their removal.)

That's indeed what I'm trying to give more perspective to.

If there's in fact no other reason to "come after packages hard" and
"remove gtk2" than "no more releases" then I'm strongly against doing so.


> I'm less clear why we would keep libgtk2 in the tree for years and
> years (just to keep nominally unmaintained gtk2 leaf packages buildable?)

This assumes that "maintained" neccessarily means "will port from gtk2"
which I don't agree with at all.

There are many reasons to not port from gtk2 to something else. As long
as there are no concrete problems, especially if one knows the relevant
parts of gtk2 well and is convinced that they are free of issues, there
is in fact no reason *to* port from gtk2. Except if distributions create
one.

It's awfully unneccessary to do that without good reason.


> > Assuming that there will be a significant maintenance burden which
> > affects all uses doesn't seem rational - hence my question.
> 
> I think you need to keep gtk2 (the library) for a fair bit (just like
> we kept python2.7; the interpreter; for a fair while after its EOL.)

I'd argue that python2.7 should remain until demonstrably untenable,
ideally indefinitely.

At some point probably no longer within Gentoo's Python infrastructure -
but at a minimum as a trivial package.


//Peter



Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
Hanno Böck wrote:
> > "It does mean, however, that GTK 2 has reached the end of its life. 
> > We will do one final 2.x release in the coming days, and we encourage
> > everybody to port their GTK 2 applications to GTK 3 or 4."
> 
> I read that as there will be one more gtk2 release and none after that.
> 
> This seems to imply:
> * When there's a security flaw in gtk2 there won't be a fix from
>   upstream.
> * When there's an incompatibility with new infrastructure (e.g. new gcc
>   version / new glibc / changing API of libraries gtk depends on) there
>   will be no updates from upstream.
> 
> This means in all those instances maintainers will have to get patches
> from somewhere. We'll likely end up with some form of
> gtk-2.x-r[largenumber] with a large patchset at some point.
> Maintaining that will be an increasing burden.
> 
> No urgency, but a sign to slowly move off gtk2.

Until there's a relevant flaw that will remain unfixed or there is
significant incompatibility with infrastructure (recurse my argument)
no signs actually exist.

Assuming that there will be a significant maintenance burden which
affects all uses doesn't seem rational - hence my question.

The blog post shouldn't be misunderstood. The intended audience seems
to be application developers, encouraging them to port applications,
not so much distributions.

Distributions quite often overlook that they wield much power, and
thus also have much responsibility.

Of course, GTK maintainers in Gentoo choose what to work on, and have
made many (only?) excellent choices.

I'm merely pleading for rational choices based on actual problems.


//Peter



Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
Peter Stuge wrote:
> We will do one final 2.x release in the coming days, and we encourage
> everybody to port their GTK 2 applications to GTK 3 or 4."
> 
> 
> The recommendation in the blog post is for application developers to
> port to 3 or 4, nothing more and nothing less.

Correction: It /encourages/ porting to 3 or 4. It's not even a recommendation.


> What's the reasoning for this driving "killing off GTK:2" in Gentoo?
> 
> Are there (presently or foreseeable) technical issues with GTK:2?
> 
> 
> Many thanks and kind regards


//Peter



Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread Peter Stuge
Aisha Tammy wrote:
> We are now in the process of cleaning up GTK:2 ebuilds and moving the
> packages to use GTK:3 and drop GTK:2 support.

Quoting the blog post you linked to: (thanks for including the link!)

"It does mean, however, that GTK 2 has reached the end of its life. 
We will do one final 2.x release in the coming days, and we encourage
everybody to port their GTK 2 applications to GTK 3 or 4."


The recommendation in the blog post is for application developers to
port to 3 or 4, nothing more and nothing less.

What's the reasoning for this driving "killing off GTK:2" in Gentoo?

Are there (presently or foreseeable) technical issues with GTK:2?


Many thanks and kind regards

//Peter



Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

2021-01-11 Thread Peter Stuge
Jaco Kroon wrote:
> > I can think of two ways of solving it:
> >
> > 1. We could patch system-installed libtool to respect environment
> >
> > 2. We could regenerate libtool and force local instance of libtool
> > in the packages needing it.
> 
> 3.  Have it always use some fixed compiler somewhere (ie, compile it

4. Make gcc-config regenerate libtool, otherwise as 2.


//Peter



Re: [gentoo-dev] Static libraries

2020-12-31 Thread Peter Stuge
Alessandro Barbieri wrote:
> > Obviously this will only be useful for packages wanting to statically link
> > with libressl lib{crypto,ssl}
> 
> There is an ongoing effort to remove static libraries from packages.

I know, and I couldn't disagree more with that effort.


> > but I think that's far better than removing libressl.
> 
> No, it's not better, it's more work for the security team.

The security team isn't be responsible for what people do.

Flip side: The security team is also not entitled to decide what people
can and can not do.

Security is a policy and technology generally needs to avoid forcing
policy onto humans, but enable human decisions. You can tell that I
value choice.

It's certainly a good default to use shared libraries, but it's no good at
all to hamper legitimate functionality under a guise of security. That's a
far too common and really diseased pattern throughout society, and it makes
me sad that it proliferates also in Gentoo.


//Peter



Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-31 Thread Peter Stuge
Hi Jaco,

Jaco Kroon wrote:
> So a few points that I picked up during this discussion.
> 
> 1.  Nobody is AGAINST libressl per sé,

Michał gives me a distinctly different impression.


> 2.  A number of people are AGAINTS the effort involved to make
> libressl work for various packages.

Yes, and I've written that I am as well.


> Without the latter, libressl is dead

On this I disagree.


> since it can't install concurrently with openssl.

Again, that need not be the case, and I'm looking into what's
possible with little to no effort:


Installing both openssl and libressl lib{crypto,ssl}.{a,so} in the same
directory is not possible since file names are the same.

Installing both openssl and libressl .so:s in different directories is
not extremely useful (but perhaps still worthwhile) since one dep for a
given package may pull in openssl and another dep may pull in libressl -
even if path stuff is resolved neatly this doesn't work at load time.
This is only useful for the case of packages explicity needing
libressl, e.g. because of (ab?)use of internals, which have no deps
which can not also use libressl without constant overhead in Gentoo.
Maybe openntpd actually falls in this category.

Installing both openssl and libressl .a files in different directories
seems both useful and straightforward. I don't object to openssl being
favored for /usr/lib here, libressl gets a directory of its own, but
libressl.pc goes into /usr/lib/pkgconfig so that it is found automatically.
Obviously this will only be useful for packages wanting to statically link
with libressl lib{crypto,ssl} but I think that's far better than removing
libressl.

Installing libressl libtls.{a,so} (built using libressl lib{crypto,ssl}
code of course) in /usr/lib also seems both useful and straightforward.
I expect this to be the default provider for (a new) virtual/libtls.


The latter two cause no conflicts and have no running overhead cost.


> Again, this will mean for libraries that they will need to have
> multi-implementation installations again

This is interesting; I suppose that this is supported very well by Nyx,
and I think it would be a great addition to Gentoo, but in any case it
will not be trivial, and I wouldn't want to make it a requirement for
having /some/ libressl code on Gentoo systems.

Hence I propose to redefine the meaning of "support for LibreSSL" to
what works well without causing lots of overhead. Again: It's not
reasonable for Gentoo to patch the world, but we should model it as
accurately as possible.


> So how do you deal with package-b-libressl vs package-b-openssl in terms
> of dependencies?

I've mentioned a couple of ideas in this thread but they're all
non-trivial and I propose to not solve this problem for now and
settle for less than a full install until someone finds a good,
manageable solution.


> Lots of very finicky risks that needs to be eliminated wih installing
> both openssl and libressl concurrently.

So again, the point is to redefine what "libressl installed" means
such that the problems are avoided, accepting that libressl
lib{crypto,ssl}.so may not get installed, at least for now,
until there's a good solution - which is really orthogonal to
libressl. Quite probably the same solution could then apply to the
other packages in similar situations (ffmpeg/libav, imagemagic, etc.).


> Someone (Michał?) mentioned it's more pain than gain currently.  And
> unless someone is willing to change that, I seriously doubt anything
> you say is going to carry much weight.

I hope it's becoming clear that what I am saying is about /how/ to
change that, and that should carry weight. Consider it brainstorming
solutions if you will.


> having written my fair share of code -

Same.


> the level of ask that you're asking for is much, much larger than I
> think you realise.

I hope what I am asking for is becoming clear. I wrote fairly early
in the thread that it's something other than the status quo.


> mysql and mariadb started out very similar, and now there are two major
> projects, and parts of it are installable separately (client libs).

Off-topic, but I'm really happy about MariaDB! I remember helping with
a MariaDB developer meeting in the early days and I was very excited
that most long-time developers decided to join Monty on MariaDB. Ever
since, MySQL is irrelevant to me. But I do appreciate that people who
are stuck with some Oracle support contract can still use it in Gentoo.


> I trust (hope) that this will give you a small amount of insight into
> what you're asking.

I thought it was clear for a good number of mails that I'm /not/ asking
to continue ensuring that openssl and libressl are interchangeable in
Gentoo;

I'm asking to ensure that libressl stays available /in some capacity/ even
if that can only be as a special case, and it looks like that would
require only very little upfront effort and zero recurring effort.


Thanks a lot for your thoughtful response! I hope I could clarify 

Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-31 Thread Peter Stuge
Mike Gilbert wrote:
> > It is important to me that you can choose dev-libs/libretls instead of
> > having any libretls code on your systems, but I reject you forcing that
> > choice of yours on everyone else.
> 
> I'm having trouble making sense of this sentence. Did you mean to
> write "libressl" instead of "libretls" somewhere?

Sorry, yes, that's right. "having any libressl code" is what I intended.


> Anyway, it seems like the people maintaining libressl in Gentoo are
> really not interested in keeping it going.

I don't know? There wasn't much discussion about my suggestion to keep
libressl code available in Gentoo in some ways causing no interference
with same SONAMEs openssl.

So again what I'm advocating for is creative ways to at the very least
not have to remove it completely, which I think becomes easy, by
redefining what a libressl ebuild installs for now. At the moment I'm
thinking about these two:

1. no-brainer: libtls .so with libressl implementation

2. more novel: lib{crypto,ssl} static-libs in non-standard location
with libressl.pc in default search path


> A libtls wrapper around openssl seems much more manageable to me,
> and that should probably be the default option for people.

I disagree on both points.

I'm still working on checking what 1. above requires. So far it looks like
the answer will be "nothing"; an ebuild wouldn't need any patch at all,
meaning zero overhead on bumps.

And I for one certainly expect libressl libtls to be the default - that
is the canonical upstream.


Thanks

//Peter



Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-30 Thread Peter Stuge
Michał Górny wrote:
> > > I think the three main ways forward from here would be to either:
> > > 
> > > 1. Keep LibreSSL for indefinite time (possibly masked)
> > > 2. Eventually move LibreSSL to libressl overlay.
> > > 3. Eventually remove LibreSSL.
> > 
> > 4. A libressl or libressl-libtls ebuild installs only libtls.
> 
> dev-libs/libretls already does that.

dev-libs/libretls doesn't install a libressl libtls.

This thread is obviously about how the libressl implementation remains
in use.

It's clear now that you want to hinder that in Gentoo at any cost to
the community, but that's not useful, so please take a step back unless
you are actually going to be constructive.

My proposition 4. (which I suggested already earlier - you shouldn't
have ignored it) is obviously not about having any libtls provider in
the tree, but to model reality accurately and ensure that libretls is
the primary and prefered libtls provider, since it is literally the
libtls upstream.

It is important to me that you can choose dev-libs/libretls instead of
having any libretls code on your systems, but I reject you forcing that
choice of yours on everyone else.


//Peter



Re: [gentoo-dev] [RFC] Recap: Discontinuing LibreSSL support?

2020-12-30 Thread Peter Stuge
Michał Górny wrote:
> let's summarize what was said so far.

Thanks for the good summary!


> I think the three main ways forward from here would be to either:
> 
> 1. Keep LibreSSL for indefinite time (possibly masked)
> 2. Eventually move LibreSSL to libressl overlay.
> 3. Eventually remove LibreSSL.

4. A libressl or libressl-libtls ebuild installs only libtls.


//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
We could clearly discuss forever, but since you refuse to engage with
my constructive proposition and my ask for feedback there's no point,
is there? It's super sad that you behave like that in Gentoo.


Michał Górny wrote:
> Choice for the sake of choice is meaningless.

Far from it.


> So far nobody has been able to find a strong argument for choosing
> LibreSSL.  There are strong arguments for using OpenSSL instead.

That's like your opinion, man. :)


> Maybe LibreSSL had promised a better taste in the beginning but today
> 9 out of 10 consumers say OpenSSL tastes much better.

It's usually harmful to optimize for popularity; smoking isn't a good
idea even if everyone in school does it.


> The only difference is that you don't have to pay
> for it (but we do!), so you think that it's free.

Please stop playing the victim and engage with my proposal instead.

I'd appreciate feedback from everyone.


Thanks a lot

//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
David Seifert wrote:
> > Maybe because it is so well-known that monoculture is harmful per se,
> > which is why the commitment to choice in Gentoo is very valuable.
> > 
> > Further, LibreSSL comes out of the OpenBSD project, which has a good
> > reputation on code quality.
> 
> Like strong-arming 99% of the users of OpenSSH because they were
> unwilling to port to the OpenSSL 1.1 API, fully well knowing that most
> of the OpenSSH consuming world doesn't actually use libressl? How is
> explicitly tying OpenSSH to libressl not a form of monoculture?

Now we're properly off-topic :) but considering that OpenSSH is developed
for OpenBSD and that openssh-portable is merely provided as a service to
other systems it's easy to understand why OpenSSH (remember, part of OpenBSD)
uses the libressl API for crypto, and why the -portable team is not so keen
on maintaining patches for other crypto providers. Another example is systemd
binding tightly to Linux. In both cases it's understandable, but also quite
unfortunate; better portability would be better.


> Case in point: Have you tried using the official libjpeg package instead
> of libjpeg-turbo? Go ahead, give it a try.

I'll take a look. I chose libjpeg-turbo for a project because it
cross-compiled better.


> "Monoculture"s are mostly a coincidence, not some sinister conspiracy.

I don't claim conspiracy, I just say that it's healthy to avoid them.


> Implementation-diversity-but-API-compatibility is mostly a
> pipe dream, as libav, imagemagick, libjpeg have shown.

I've been fortunate to have a different experience with other codebases.

It's completely possible, but takes (extra!) effort, meaning you have
to really want it. If there is some rivalry then it's also quite easy
to sabotage your colleagues.


//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
Michał Górny wrote:
> > I would be happier if some other developers were able and willing to
> > participate actively in the LibreSSL project.
> 
> But why would they do that?  What I'm really missing in all the replies
> is a single reason why LibreSSL would be better for anyone.

Maybe because it is so well-known that monoculture is harmful per se,
which is why the commitment to choice in Gentoo is very valuable.

Further, LibreSSL comes out of the OpenBSD project, which has a good
reputation on code quality.


> a real proper, verifiable argument 'LibreSSL is better in this regard'.

Choice is about enabling people to decide for themselves.

Choice is /not/ about forcing people to formally prove utility to yourself.


I acknowledge that what I suggest isn't immediately enabling libressl as
a choice either, but it is at least far less destructive than masking and
removal.


//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
Matt Turner wrote:
> > I think many mails in this thread suffer from some tunnel vision, expecting
> > that a libressl ebuild in the tree must continue to work exactly like the
> > openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.

To clarify, by "stop that" I mean "stop efforts to make libressl a
drop-in replacement".


> If they suffer from tunnel vision, it's because the intersection of
> "people who care about libressl" and "people who have patches in
> gentoo.git" is the empty set.

Tunnel vision refered not to people but what a libressl ebuild delivers,
which you seems to have turned into an ad hominem against me?

Who will do actual work is a separate question, of course if noone wants
to then nothing matters, but it seems that some people /do/ care about
libressl; I suppose the 61 patches mgorny found were committed by someone.

If you were somehow trying to belittle /me/ then it's certainly true that
I'm not a Gentoo developer, but there are some patches by me in gentoo.git.


> I think we all understand your points: libressl could be kept in-tree
> and allow people to play with it. Unfortunately that requires much
> more work than removing it, and I haven't seen evidence that you're
> prepared to contribute to the required effort.
> 
> I don't think you're going to convince a bunch of people with little
> interest in libressl per se to continue allowing the extra burden
> unless you do the work that's needed to keep it in-tree (e.g., to
> allow it to be installed beside openssl).

You seem to not understand my point at all.

As I've written I (like others) argue against "continue allowing extra burden"
and I've suggested and offered to help with one approach to keep a libressl
ebuild in the tree.


//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
Andreas K. Huettel wrote:
> > I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
> > to continuosly patch the entire world for libressel.
> > 
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches, even
> > if that's only openntpd and one other package.
> 
> a) The two cannot be installed concurrently. To fix that would require even 
> more hacks.

As we've discussed in another part of the thread, that's not really true.
Both can for sure be installed, just not in the same place and/or
with same names.


> -> all relevant ssl consumers on the user's system must be linked against
> the one selected

Also not the case. Considering the two installed in different paths
with same names it's still easy for consumers to use one or the other
with -rpath at link time.


I do agree that the two are not always 1:1 replacements for each other.
If they are API incompatible somewhere then for sure not.

I think many mails in this thread suffer from some tunnel vision, expecting
that a libressl ebuild in the tree must continue to work exactly like the
openssl ebuild - I'm saying to stop that but do keep a libressl ebuild.


> b) The libraries are not guaranteed to be binary compatible, so switching 
> implementation requires rebuilding consumers.

We can only consider ABI compatibility if we have API compatibility,
which might not even be a given.


> c) If a single package that the user wants to install is not "fixed" for
> one ssl library, it blocks that option for all packages.

Please think of a libressl ebuild in a new way.


> I guess if you can come up with a solution that
> * provides secure usage of the libraries,
> * provides choice to the user, and
> * doesn't lead to unupgradeable systems or unresolvable dependencies
> we'd all be happier. So far we haven't found one.

Right! I think letting a libressl ebuild install only libtls could be a
good start, because it provides a stable situation, without risking
conflicts. Would you agree?


Thanks

//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
David Seifert wrote:
> > > I mean, you have to explicitly support the choice in ebuilds,
> > > and this means making things even harder for newcomers.
> > 
> > pkg-config/pkgconf and .pc files can help with this part, taking care
> > of all abstraction if/when downstream uses a libressl.pc.
> 
> As we have learned from the ncurses[tinfo] debacle, 80% of build systems
> don't use the .pc files, and just guess "-lssl" flags and a bunch of
> include dirs.

Did the debacle actually involve -lssl ?

I guess that it depends on the particular library - with an old library
such as ncurses I can imagine that .pc is much less established, and
I have indeed seen pretty ugly OpenSSL detection in configure.acs,
they could still remain, and would then simply never catch libressl,
I think that would be fine.


> > > The big problem is that (unless I'm mistaken) we won't be able to
> > > load LibreSSL and OpenSSL to the same executable.
> > 
> > I'd suggest investigating whether symbol versioning could help with
> > this, or if the only way forward would indeed be to require some symbol
> > mangling/rewriting.
> 
> While this sounds like a theoretical solution, it isn't tractable because
> 1. We're inventing our own ABI that is incompatible with everyone else's

ABI for a given library doesn't neccessarily matter beyond the
individual system, does it?

For something like reproducible builds of course it does.


> 2. We'd have to maintain a huge swamp of downstream patches

Nono, no patches of course, it would have to be automatic, if only for the
local system.


> 3. ABI can still break even with perfect symbol versioning

Oh? This may be unrelated, but can you tell more or provide a pointer?


Thanks!

//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
Michał Górny wrote:
> > 2.  Install them into different prefixes (eg /usr/lib/openssl +
> > /usr/lib/libressl and have the linker link to a specific version,
> > /usr/include/{openssl,libressl} too).
> 
> For the record, this is something I've been wondering about for a long
> time.  However, there are two problems with that: a small one
> and a huge one.
> 
> The small problem is that this requires a lot of additional downstream
> work.  I mean, you have to explicitly support the choice in ebuilds,
> and this means making things even harder for newcomers.

pkg-config/pkgconf and .pc files can help with this part, taking care
of all abstraction if/when downstream uses a libressl.pc.


> The big problem is that (unless I'm mistaken) we won't be able to load
> LibreSSL and OpenSSL to the same executable.  So we'd actually have to
> enforce that the whole link chain links to the same SSL provider,
> and effectively land pretty close to where we are now.

I'd suggest investigating whether symbol versioning could help with this,
or if the only way forward would indeed be to require some symbol
mangling/rewriting.


//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
Michał Górny wrote:
> > net-misc/openntpd
> 
> I've just tested it and it builds fine against dev-libs/libretls.

I hope you're not planning to suggest that dev-libs/libretls should
be the only libtls on Gentoo, since that would be an arbitrary and
artificial limitation - the very opposite of choice. I'm strongly
against that.


Jaco Kroon wrote:
> > I'm asking to stop doing that, yet still enable the choice between
> > openssl and libressl where that is possible without patches, even
> > if that's only openntpd and one other package.
> 
> Are you willing to put in the work to allow installing openssl and
> libressl concurrently on the same system?

I'm willing to help. I know that it's one or the other. And I have
experience with distributions making arbitrary decisions about libraries,
and I think I have an idea about the challenges and possibilities.


> The only real solution then to make libressl viable is to make it
> co-exist with openssl reliably.

Ack.


> Of course there are various strategies (or combination of), to mention
> but a few:
> 
> 1.  Use a virtual/??? (but since the APIs aren't compatible despite the
> libressl promise thereto ...)
> 2.  Install them into different prefixes (eg /usr/lib/openssl +
> /usr/lib/libressl and have the linker link to a specific version,
> /usr/include/{openssl,libressl} too).
> 3.  Make ssl USE flag another single-choice USE_EXPAND, posibly by way
> of openssl.eclass.

These are all interesting and I think worth exploring! But also
non-trivial, so maybe better saved for later?

What do you think about my suggestion in a previous email to have the
libressl ebuild install only libtls .so and .a files built from static
libs/objects, so that there are no conflicting shared objects?

I can certainly help accomplish that if there is interest.


> would be in willing and in support of updating the packages I maintain
> to assist with libressl support if the eco system can be improved.

Cool! I really appreciate your openness. I'm asking essentially to
keep options open, so that the ecosystem can be improved step by step.


Thanks

//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
Michał Górny wrote:
> 1. Stuff that does not build against LibreSSL.
> 2. Stuff that builds just fine but fails at runtime in unpredictable
> ways (e.g. Tor mentioned today).
> 3. Stuff that builds and works 'fine' but ends up being crippled (e.g.
> doesn't support new algorithms).
> 
> The first one is somewhat easy to test (e.g. via tinderbox).  The other
> two are very hard.

Nod.


> > > Actually, I see that someone has apparently forked libtls into
> > > libretls (the irony!) that works against OpenSSL [1].
> > 
> > To me, that proves value in the libtls API and in keeping libressl in
> > the tree in some capacity, even if not as an alternative to openssl.
> > 
> > Maybe with a USE flag which makes it install only libtls (built from
> > libressl static libs), which could be one provider for a
> > virtual/libtls.
> 
> I don't see why we would put an effort into that.

In my very next sentence (not quoted in your reply) I wrote explicitly
that I do /not/ ask anyone to do so, but ask that you don't hinder it
by masking libressl and also don't remove existing work potentially
supporting such efforts, ie. the libressl ebuild.


> I've just packaged dev-libs/libretls

Thanks! That seems useful.


> Trying to get the same result from libressl is just repeating the work.

Maybe for you, and I'm saying that you should be able to make that choice
for your systems, but also that you should not hinder others from making
another choice, where that's possible and as I wrote without needing
Gentoo to patch the world.


Thanks a lot

//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread Peter Stuge
Michał Górny wrote:
> > I'm sure that there are numerous cases where libressl doesn't work,
> > but that's no reason to dismiss cases where it *does*.
> 
> Are you asking people to put an effort into maintaining something that
> can't be practically installed?

No, I'm rather asking to change the level of commitment.

I agree completely that it's unreasonable for Gentoo (worse, 1 person!)
to continuosly patch the entire world for libressel.

I'm asking to stop doing that, yet still enable the choice between
openssl and libressl where that is possible without patches, even
if that's only openntpd and one other package.

The method for that choice could of course depend on the number of
packages where it applies.


> A side effect of this approach is that users will be tricked into using
> LibreSSL, only to discover that they eventually have to transition
> their systems back.

I believe I'm asking for the opposite. I think it's fine to say that
libressl has to be a deliberate choice rather than a default.


> > Did anyone gather actual numbers?
> 
> $ find -name '*libressl*.patch' | grep -v dev-libs/libressl | wc -l
> 61

I'm more interested in the number of packages which can use either
library without patches (like openntpd?). This may be tricky to find out. :\


> > > > B. It brings its own TLS API, a unique feature which by itself
> > > > warrants the package.
> > > 
> > > ...which by itself has no future
> > 
> > That's arrogant and silly coming from anywhere but upstream.
> > 
> > You can argue that you will never use the API in your TLS programs,
> > but even then that says really nothing about the API provider itself.
> 
> That's my opinion and I have a right to have it without being insulted.

You absolutely have a right to your opinion but you stated it as fact,
that made me react so strongly.


> I don't dispute whether it's good.  I dispute whether tightly binding
> it to a problematic LibreSSL is a good idea.

I agree with this, but only in cases where libressl is indeed problematic.

I can think of systems where it isn't, there the choice is a good thing.


> Actually, I see that someone has apparently forked libtls into libretls
> (the irony!) that works against OpenSSL [1].

To me, that proves value in the libtls API and in keeping libressl in
the tree in some capacity, even if not as an alternative to openssl.

Maybe with a USE flag which makes it install only libtls (built from
libressl static libs), which could be one provider for a virtual/libtls.

Note: I'm not at all expecting anyone to do such work for me, I just
don't want it to become impossible (libressl mask) or any existing
effort supporting something like the above to be sunset.

Does that make sense?


Thanks!

//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-28 Thread Peter Stuge
Michał Górny wrote:
> > A. It is a distinct implementation with probably /quite some/ stable
> > compatibility, meaning that it will work perfectly fine as an
> > alternative in many cases.
> 
> Except that it doesn't, as has been proven numerous times.

I'm sure that there are numerous cases where libressl doesn't work,
but that's no reason to dismiss cases where it *does*.

Did anyone gather actual numbers?


> > B. It brings its own TLS API, a unique feature which by itself
> > warrants the package.
> 
> ...which by itself has no future

That's arrogant and silly coming from anywhere but upstream.

You can argue that you will never use the API in your TLS programs,
but even then that says really nothing about the API provider itself.


> > More elaborate OpenSSL API users can (arguably should) just block on
> > libressl instead of requiring patch work.
> 
> It's all nice theory but in practice it means that nobody will be able
> to install libressl because some important system packages will block it.

Gentoo can't be expected to do magic. If libressl would conflict on another
system then of course it will on Gentoo too. Give users more credit here.

Also, think more about other use cases than your own. I mentioned one;
non-releng stages. The point here is that it's possible to deliberately
create a system using libressl by making tradeoffs, e.g. not using some
"important" system packages which would block it.

Finally, I find it quite beautiful if Gentoo can clearly show that
important system packages have slipped far down a monoculture slope -
this is a great incentive for new projects which tackle creating
alternatives for those packages.


> waste our users' time pretending that we do support LibreSSL,
> while anyone actually trying it will hit a brick wall.

You shouldn't pretend to be something you are not. With a little effort
to set users' expectations according to the technical reality (a function
of upstreams; rather unrelated to Gentoo) I don't expect wasted time.


//Peter



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-28 Thread Peter Stuge
Michał Górny wrote:
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.

I think that's a horrible idea, since Gentoo is about choice and this
particular component is one of the most important in a system.

But "support" can mean different things...


> LibreSSL users, does LibreSSL today have any benefit over OpenSSL?

Yes, at least two:

A. It is a distinct implementation with probably /quite some/ stable
compatibility, meaning that it will work perfectly fine as an
alternative in many cases.

B. It brings its own TLS API, a unique feature which by itself warrants
the package.


> All this considered, provided that nobody is able to find a good reason
> to use LibreSSL, I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.

There is no reason at all to do all three of those atomically:

1. Stop patching packages to make them build also against libressl
2. Stop maintaining libressl-*.ebuild
3. package.mask

I think the complaint is really only about 1. and I can understand
that the effort here outweighs the perceived benefit, that's fine,
I don't think it's the responsibility of Gentoo developers to patch
the world to build also against libressl.

But as long as a single package can be built with either openssl or
libressl without changes I consider it appropriate to maintain both
libressl ebuilds and either virtual/openssl or another way to decide
system-wide to use libressl instead of openssl. This remains very
valuable especially for non-releng stages.

More elaborate OpenSSL API users can (arguably should) just block on
libressl instead of requiring patch work.


//Peter



Re: [gentoo-dev] libressl / libtls

2020-12-11 Thread Peter Stuge
Paul B. Henson wrote:
> Would it be possible to have a use flag such as 'libtlsonly' or whatever 
> for the ebuild which only installs libtls,

Sure.


> Or have a separate ebuild just for libtls (which couldn't 
> be installed with the full libressl ebuild or vice versa)

That's also technically possible.


I'd personally prefer the latter.


//Peter



Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Peter Stuge
Georgy Yakovlev wrote:
> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles
> by the end of the week by updating virtual/tmpfiles ebuild.

Michael Orlitzky wrote:
> Corollary: the tmpfiles.d specification can only be implemented (safely)
> on Linux after all.

So should virtual/tmpfiles differentiate based on system?


//Peter



Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?

2020-11-09 Thread Peter Stuge
Andreas K. Hüttel wrote:
> it's probably time to deprecate the amd64 17.0 profiles!

I for one am not so excited about the amd64 17.1 profiles. On the surface
it appeared to me that one developer has "taken over" just about everything,
which (regardless of the individual) can't be a good thing..


Jaco Kroon wrote:
> ...just wondering where the lib32 => lib symlink comes from now.

baselayout contains a conversion to/from lib symlink(s).


Kind regards

//Peter



Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Peter Stuge
Michał Górny wrote:
> Read: it's important to slap users to satisfy developer's wannabes.

LOL! Michał, you managed to squeeze both misrepresentation and ad hominem
into so few words. Please take care. Anyway, you missed my point:

It's important that (the project) developers set accurate expectations
for contributors.


Michał Górny wrote:
> If user puts effort to make a good contribution, the developer
> shouldn't be rejecting it to 'demonstrate other methods'.

Here you confused a couple of different things, maybe you didn't
understand what I meant.

"demonstrate other methods" is something that the Gentoo project does by
enabling choice also in the development process. This is made possible by
self-determined infrastructure in parallel with GitHub. This is important
and valuable both philosophically and practically, and I think Gentoo
should be both proud of it and also proud to present it.

"rejecting" would require an action, that's not the case; we're talking
about simply documenting which developers don't use GitHub, so that
contributions can know the right place to go.

Then there's your opinion that developers should do all that contributors
want. I disagree with that for two reasons:

1. it doesn't scale, and
2. developers too work in their spare time, and choose how they do so


> This is the horrible attitude that kills the project.

In general I think that individual lack of reflection is a far greater
problem than developer workflow choices within community projects.

For Gentoo specifically I think that a fairly small number of structures
are the main reason to rather spend time on other projects - that's off
topic for this thread though.

Assuming good faith and asking for clarification when something seems
negative is always a good idea.


//Peter



Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag

2020-08-18 Thread Peter Stuge
Joonas Niilola wrote:
> some of you may already have seen the new packages.gentoo.org page,
>   https://packages.gentoo.org/

I had not seen that - that's wonderful!

I would just request that /packages/ is removed from the start of
package URLs. I understand how this makes request routing more
complicated, but I consider it a significant usability improvement.


..anyway:

> I'm suggesting of adding a new metadata flag to our Wiki's
> User:/Project: page which then prints a message to this page saying
> whether the maintainer (be it project or user), "accepts" or "deals
> with" Github contributions. The wording can be a bit better, but it'd be
> there to **notify** our **contributors** whether their time and effort
> will most likely be wasted making a pull request for this particular
> maintainer.

I think this is a very good feature.

If I ever do become a proper Gentoo developer I will certainly not spend
any time on anything to do with GitHub, and in my current position of
occasional contributor I don't either. The workflow imposed by GitHub
isn't good and it's important to demonstrate other methods.


//Peter



Re: [gentoo-dev] Last-rites: dev-libs/liboobs

2020-08-03 Thread Peter Stuge
Jimi Huotari wrote:
> # Jimi Huotari  (2020-08-04)
> # No consumers since 2015, and no known stand-alone use.
> # Removal in 30 days.
> dev-libs/liboobs

Wut - isn't that a really poor reason to remove from the tree? :\

Why not just keep it unless there is an actual technical problem?
(Security, maintainability, etc.) If there is, then please mention it.


//Peter



Re: [gentoo-dev] Last rites: */* More Py2 only items

2020-07-21 Thread Peter Stuge
Remco Rijnders wrote:
> I'd like to volunteer myself as proxy maintainer for this package. As
> this would be the first package in gentoo I'd be working on, I ask for
> advice on the following two points:

Note that I'm no developer but have been proxy-maint for some time.


> - Can the removal of this package from gentoo be pushed backwards with
> a month or so to allow me to work on packaging this new version as well
> as do some rudimentary testing to ensure it works properly with Gentoo?

I have no idea about this one.


> - As upstream for this program would be changed, should the name
> getmail in gentoo be kept or would it better to use getmail6, and if
> so, what would be the best way to go about this?

Since you want to avoid clobbering the existing name outside of Gentoo
I think you should strive for the same also within Gentoo. That said,
if the two are interchangeable then a virtual/getmail ebuild would
probably be reasonable.


//Peter



Re: [gentoo-dev] Gentoo/OpenBSD current status

2020-06-01 Thread Peter Stuge
Benda Xu wrote:
> > I was wondering if the openbsd prefix support is something
> > that is still garnering any interest from gentoo?
> 
> There is still interest in Gentoo.  But no one seems to have energy to
> take care of it.

FWIW I have interest in this as well.


> Your contribution is welcomed.

What contributions are known to be needed at the moment?


Kind regards

//Peter



Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-24 Thread Peter Stuge
Kent Fredric wrote:
> > While services such as reCAPTCHA are (as said) massively intrusive, there
> > are other, much less intrusive and even terminal-compatible ways to 
> > construct
> > a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
> > for a human above the response input line - that's not so bad.
> 
> Well, they kinda have to be,

I disagree with that, especially for this service, that was the point I
wanted to make. :)


> the state of AI is increasing so much that current captcha systems
> undoubtedly also develop their own adversarial AI to try beat their
> own captcha.
> 
> I don't think we have the sort of power to develop this.

In any case I don't think that's required.


> And the inherently low entropy of only having 80x23 with so few
> (compared to full RGB) bits per pixel,

A character doesn't compare too bad to RGB. See aalib, or if you
will risk exclusion of color-vision-impaired humans libcaca.


> this gives any would-be AI a substantial leg up.
> 
> Using text distortion is amateur hour these days.
> 
> (and there's always mechanical-turk anyway)

Except this isn't for some web-scale disruptive startup, it's a
statistics/reputation system for an advanced, super-nerdy Linux distribution.

Please think more about the threat model, and remember the rate limit knob.

The bar only needs to be raised high enough.


//Peter



Re: [gentoo-dev] [RFC] Bootloader use in eclean-kernel

2020-05-24 Thread Peter Stuge
Michał Górny wrote:
> Hence my question: do you find 'do not remove kernels listed
> in bootloader config' feature useful?  Do you think it should remain
> the default?  Do you think it is worthwhile to continue supporting it?

I continue to use LILO because simpler and more mature code is good,
especially in the boot code path. I used GRUB for a short while but when
I saw it fail to boot from one start to another (without any OS changes)
I ended that experiment. I also wasn't impressed by the GRUB2 code quality
and tendency to become a mini-OS, trendy as that is.

I don't use eclean-kernel, but FWIW I think there is clear value in
supporting the LILO-style approach with explicit installation/configuration
of the bootloader in advance.


//Peter



Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-22 Thread Peter Stuge
Stop motivated attackers or keep low barrier to entry; pick any one. :)

Michał Górny wrote:
> CAPTCHA
> ==
> A traditional way of dealing with spam -- require every new system
> identifier to be confirmed by solving a CAPTCHA (or a few identifiers
> for one CAPTCHA).
> 
> The advantage of this method is that it requires a real human work to be
> performed, effectively limiting the ability to submit spam.
> The disadvantage is that it is cumbersome to users, so many of them will
> just resign from participating.

While services such as reCAPTCHA are (as said) massively intrusive, there
are other, much less intrusive and even terminal-compatible ways to construct
a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle
for a human above the response input line - that's not so bad.

Attacking something like a server-generated maths challenge rendered in a
randomly chosen and maybe distorted font would require OCR and/or ML, which
is fairly annoying. The only real problem then would be with OCR packages. ;)

Combine with a rate limit that is increased manually as the service grows
more popular. It can be a soft limit which doesn't report failure but results
in queueing+maybe vetting of reports, to allow some elasticity for peaks.


//Peter



[gentoo-dev] user.eclass ignores ROOT/SYSROOT

2020-05-05 Thread Peter Stuge
Hi,

I'm trying something out over here and I'm surprised to find that
acct-group/* do not work with ROOT+SYSROOT != "/".

Should I file yet another bug about this?

I suppose the limitation is in user.eclass, but what about the 11 bugs
already filed about exactly this problem?

They are easy to see in the dup bug list at https://bugs.gentoo.org/53269

Unfortunately mgorny closed 53269 WONTFIX because GLEP-27 is Deferred,
causing all dup and dep bugs to be forgotten. Sad panda.


--8<-- reproduce
# export r=$(mktemp -d)
# ROOT=$r SYSROOT=$r strace -fe execve emerge baselayout acct-group/ftp 2>&1 | 
grep groupadd
[pid 13269] execve("/usr/sbin/groupadd", ["groupadd", "-r", "-g", "21", "ftp"], 
0x5d7e299e2340 /* 227 vars */) = 0
groupadd: cannot lock /etc/group; try again later.
 *   groupadd -r ${opts} "${egroup}" || die
 *   groupadd -r ${opts} "${egroup}" || die
-->8--

In my particular case -R $r would work just fine, but as can be seen
in several of those 11 dup bugs it is not a general solution.


Any ideas on how to solve this?


Thanks

//Peter



Re: [gentoo-dev] zoom concerns

2020-04-08 Thread Peter Stuge
Kent Fredric wrote:
> Syntax above not expected verbatim, just food for thought,

I think this is a really good and useful idea. I would love to see it.


> the nature of this metadata is that it SHOULD NOT be in the ebuild
> itself, as it is inherently "repo based", the installed values of
> these are worthless.

E.g. for auditing the installed values of these could be worth a lot.


Thanks!

//Peter



Re: [gentoo-dev] ceph's static-libs

2020-04-05 Thread Peter Stuge
James Le Cuirot wrote:
> Damn, I realised just as I hit send that there's a caveat here and
> that's sub-dependencies. If you're building a partially static binary
> then I think you're okay. A fully static binary obviously needs all its
> dependencies to be static and that includes any sub-dependencies.

Note that there isn't really a way to express "partially static" to the
toolchain when building a binary.

If you link a binary -static then that is always "fully static". No .so
will satisfy any -l options.

The only way a "partially static" binary gets created is when linking
*without* -static but some -l libraries only exist as static libraries,
or if a library/object archive is specified with full .a filename,
without using -l.

And "partially static" also only means that some dependencies were
included into the binary, but unlike "fully static" the binary is
not runnable without ld.so and a fitting libc.


> If an executable statically links libwebp.a with JPEG support but you
> don't have libjpeg.a then you'll end up with undefined references.

It's a bit more complicated..

Assume: ( note: without -static )

gcc -o binary source.c /usr/lib/libwebp.a

If libwebp requires libjpeg, and libwebp was not built to include
libjpeg.a then the above will not build. So we try:

gcc -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a

If both .a exist this builds, but binary is still *not* linked statically,
at a minimum, ld.so and libc are still required to run it.

If we do:

gcc -o binary source.c /usr/lib/libwebp.a -ljpeg

Then the compiler will pick any libjpeg that is available, preferably
.so but if that can't be found then it will also look for .a. binary is
still *not* static.


Finally consider:

gcc -static -o binary source.c -lwebp -ljpeg
gcc -static -o binary source.c /usr/lib/libwebp.a /usr/lib/libjpeg.a

The above two are equivalent, but only thanks to -static. This fails
if either library .a is not found. When this succeeds, we have a static
binary, which runs anywhere regardless of ld.so and libc.


pkg-config .pc files for libraries are a very convenient solution to
the problem of sub-dependencies. In the above case, libwebp.pc would
perhaps have -lwebp in Libs and libjpeg in Requires.private (or maybe
-ljpeg in Libs.private).


> That probably explains why the ceph dependencies are as they are

I think USE=static-libs is nice to have, and ideally (IMHO) it would
be a global USE flag, respected by every package that installs a
library. The flag says nothing about consumers, it only promises
availability of the .a files, which I think is nice.

One technical reason for a consumer to DEPEND on libotherpackage[static-libs]
would be if an upstream Makefile has /usr/lib/libother.a instead of -lother,
arguably it would make more sense to apply a patch to the Makefile then.

Another technical reason would be that libotherpackage doesn't adhere to
common sense/best practice for library ABI/API compatibility, and make
the static library *different* from the shared object. If libotherpackage
maintainer heroines have made it possible to have one SLOT installed as
static library and another, incompatible, SLOT installed as shared object
and the consumer maintainer might know that only the static variant works.
This one is very hard to do anything about about in Gentoo, but it is also
a very construed case. The closest I've seen to this is giflib, which
changed API and ABI without bumping SONAME.


//Peter



Re: [gentoo-dev] Use acct-* for qmail users

2019-09-15 Thread Peter Stuge
Mike Gilbert wrote:
> Do the users actually need home directories?

Technically probably no, but ~qmail is easier to type than /var/qmail.

TBH I actually always type it out anyway.


Mike Gilbert wrote:
> If you don't want to maintain them, you'll need to find someone else
> to do it.

If noone else wants to take this then you can add me as proxied maintainer.


//Peter



Re: [gentoo-dev] Gentoo i486 support

2018-08-22 Thread Peter Stuge
Rich Freeman wrote:
> Is there a large population that actually runs x86 on modern
> hardware, or is ancient hardware a significant use case?

There are current products with pre-686 instruction sets.

Companies such as DM still produce 586-class SoCs for embedded and
industrial. These[1][2] are current products.

And Intel Quark[3] is another one.

I prefer option number 1 as suggested in the initial mail.


//Peter

[1] https://en.wikipedia.org/wiki/Vortex86
[2] http://www.vortex86.com/?p=264
[3] https://en.wikipedia.org/wiki/Intel_Quark



Re: [gentoo-dev] News item review: OpenSSH LDAP support

2018-08-06 Thread Peter Stuge
Hi Thomas, I suggest some improvements..

Thomas Deutschmann wrote:
> Title: OpenSSH LDAP support

Perhaps qualify this a bit, e.g. "Migration required for OpenSSH with LDAP"


> When your sshd authenticates against LDAP, you have to migrate your

s,When,If,

> current setup to a new one using sshd's "AuthorizedKeysCommand" option and
> use

s, use,,

> a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey
> because beginning with net-misc/openssh-7.7_p1, deprecated OpenSSH-LPK
> patch set no longer applies.

Maybe "because beginning with net-misc/openssh-7.7_p1 the OpenSSH-LPK
patch set is deprecated and no longer applies."


Thanks a lot!

//Peter



Re: [gentoo-dev] Adding USE=udev to linux profiles

2018-07-20 Thread Peter Stuge
Mart Raudsepp wrote:
> > * USE=udev means different things for different packages. You think
> >   it "makes udev work" or whatever, but nobody has any idea what it
> >   does for half of the packages that use it. The meaning is package-
> >   specific, so the default should be package-specific.
> 
> It makes hardware work without static configurations, including when
> hotplugged.

That's not really a complete description...

1. Linux always sends netlink messages on device changes.

2a. If running, udevd receives those messages and executes all udev rules.

2b. udevd then sends its own netlink messages, after executing rules.

3. libudev consumers receive messages from 2b.

libudev and udev in general is thus an abstraction of the kernel
information exposed in 1. It is possible, easy, and at times strongly
preferable to skip the udev stack and just consume 1. messages
directly. I know of at least one package which does exactly that
on USE=-udev, I can only emphasize that the meaning of USE=udev is
completely package-specific. There are several possibilities what to
do in an upstream package when libudev can or should not be used, and
I for one don't think profiles/ebuilds should neccessarily model them.


> It should be enable by default for all Linux users.

I disagree. Linux is used more widely than that.


> The default shouldn't be "nothing works, until you make it work".

I agree completely, but please don't assume that no Linux system will
work without USE=udev.


I think the viewpoint of rearranging profile inheritance makes a lot
of sense. Profiles are super powerful, expressive, and cheap! I think
it would be fine to add another level of inheritance for udev.

Maybe there is a clever trick with a profile for each desired USE flag?
Somehow dynamic profiles? Dunno - just an idea.


Thanks!

//Peter



Re: [RFC] Commit messages - WAS Re: [gentoo-dev] Re: What means bup?

2018-07-18 Thread Peter Stuge
M. J. Everitt wrote:
> I'm thinking something along the lines of the following:
> - Line one is limited to / and some Key Word that defines the
> type of change made, similar to bugzilla perhaps eg. "REVBUMP, VERBUMP,
> EAPIBUMP, BUGFIX, PATCH, FEATUREREQ, OTHER". This would get around the
> issue of long package-names and/or overlays and other lengthy prefixes.

This would remove one of two information atoms in commit messages,
reducing human expression in commit messages to mere 50%,
or to 0% for --oneline output.

I think that's unacceptably poor usability.


> This should satisfy line length limitations,

My counter-proposal is to bup the repoman line length limitation.


//Peter



Re: [gentoo-dev] x11-terms/xterm up for grabs

2018-06-25 Thread Peter Stuge
Johannes Huber wrote:
> I will take it.

Thanks. I can help as proxy-maintainer if you like.


//Peter



Re: [gentoo-dev] newsitem: baselayout 2.5 changes (round 2)

2018-02-13 Thread Peter Stuge
William Hubbs wrote:
> The first change is that ROOTPATH is no longer set. This means all of
> the *sbin directories will be added to the default path for all users
> instead of just the root user.

Maybe add a sentence about why this is changing or even neccessary,
to avoid perception of weakened security.


//Peter



Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

2018-01-11 Thread Peter Stuge
Maybe this is a discussion for -project, then?


Andreas K. Huettel wrote:
> a few outside trolls who
> * keep pushing their personal agenda in endless threads,
> * confuse their own inability to contribute with being a mistreated underdog,
> * and keep commenting opinionated on technical things they plainly have no 
>   clue about (while whining when are told they sprout bulls##t).
..
> Andreas K. Hüttel
..
> (council, toolchain, perl, libreoffice, comrel)

You Sir are IMHO neither fit for the office of council nor of comrel,
solely based on your communication style in that one mail.


I would not vote for you, and would vote against you if that's even possible.

//Peter



Re: That's all folks. (Re: OT Re: [gentoo-dev] Re: [gentoo-project] [RFC] Splitting developer-oriented and expert user mailing lists)

2017-12-08 Thread Peter Stuge
Andreas K. Huettel wrote:
> 
> Independent of whether William now unsubscribed or not, he's now enjoying a 
> lengthy (1 year until review) vacation from all Gentoo communication channels.
> 

I don't understand two things about Gentoo:

1. style: How can anyone consider "enjoying a vacation" to be
appropriate wording in this context? That is at a minimum tasteless.

2. substance: Why would William be blocked from Gentoo for a year?

How and/or where will these two points be clarified?


Thanks

//Peter



Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-05 Thread Peter Stuge
Daniel Campbell wrote:
> On Sun, Dec 03, 2017 at 12:18:04AM +0100, Michał Górny wrote:
> > I'd like to establish the following changes to the mailing lists:
> > 
> > 1. Posting to gentoo-dev@ and gentoo-project@ mailing lists will be
> > initially restricted to active Gentoo developers.
> 
> I don't think this plan will have the effect you're going for,

I agree, and I'll double down on my previous comment on this proposal:

I consider the proposal to be the wrong solution.


> but let's be honest here: the "RFC" is just a formality; the decision's
> already been made.

I hope that a mere proposal doesn't automatically mean policy change.


> If the "real leaders" of Gentoo want to divide and fragment the
> community, it's their prerogative.

When there is a request for comments, there should also be comments. :)

Far too many fall into the simple trap that is tribalism, and I'd like
to encourage everyone on this list to not be that kind of person,
because there really is no "us and them", there is only "us".


> As we tell users who do something they're not supposed to: You get
> to keep the pieces.

Well, let's see what happens, now that both developers and
non-developers have clearly spoken out *against* this proposal.


Kind regards

//Peter



Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-05 Thread Peter Stuge
William L. Thomson Jr. wrote:
> No one questions why I stepped down.

I have wondered what happened, but haven't felt able to investigate.

Please know that I wouldn't take sides without investigating, and I
think that an overwhelming majority is also like that. A problem is
that you'll only ever hear from those who do take sides, but I think
the vast majority doesn't.

In the end I think giving up any position comes down to one of two things:
either feeling that one can not sufficiently meet expectations, or feeling
that others do not meet one's own expectations. I've experienced both.

How those happen is probably always a sad story of personal differences. :\


> I let others convince me I was the problem so I went away. Yet things
> did not improve in my absence. Maybe I wasn't the problem

I hope that everyone always learns. I think almost everyone does.


William L. Thomson Jr. wrote:
> > doing whatever you did to get banned from  GitHub
> 
> You tell me does this make any sense to ban someone from Gentoo's Github?
> https://github.com/gentoo/gentoo/pull/1721#issuecomment-300178677

It doesn't make sense to me, because you're trying to help inform a
community contributor. But I also don't know any of the "Gentoo Java"
context - which I think also matters.

Reading the motivation for the ban "not the place to post comments and
recount how Gentoo Java is struggling with its staffing needs" and
"GitHub ..  [is] for code-centric feedback and technical discussions,
not about Gentoo-meta issues or the like" I can understand that someone
would feel that your comment was out of place, but I don't think that
a 14 day ban is an appropriate first response.

That said, expectations were clearly not met, all around.

The expectations of the community contributor were not met by Gentoo,
since (as is mentioned in the ban mail) Gentoo is not a typical GitHub
project, where a PR is the entire process into the repo. I think it is
perfectly fine to communicate about this in a PR, and I think a Gentoo
policy never to do so is a mistake.

The expectations of the Gentoo GitHub Project were not met by you,
since it seems a PR policy is "Everyone can review pull requests. 
However, please make sure that your comments are correct and on
topic." and your comment was also trying to inform about the larger
context, not strictly limited to technical details.

I personally disagree with such expectations in the GitHub team, but I
can't even be bothered to become a proper Gentoo developer, because the
threshold is just too high for me.


I would attribute the contributor's (very valid) disappointment to lack
of communication, ie. to Gentoo not having set accurate expectations.
It is probably true that Gentoo isn't equipped to do so at the moment,
so everyone has to learn on their own. Some will get burnt in the process. :\


> https://github.com/gentoo/gentoo/pull/6033
> I felt I should have responded to not be rude.

I agree with you, and you seem to always respond politely. While I
sometimes find it a bit difficult to understand what you intend to
say because of your writing style, it looks to me like you always
intend to equip others with useful information.


> I still do not respond in kind to others.

I think that shows good character. Please keep that up, no matter what
others do.


To the actual topic of Gentoo Java I think the best you can do is
essentially what you are already doing - work on solving your own
problems in your own overlay, if there is a kind of informal team
working mostly to provide life support. You can try to support them,
but you may have very different needs, and if communication doesn't
work so well then there can't be an actual team.

I rarely use Java, but what I do know about Java supports your
argument that Gentoo could need a lot of work for JDK 9, because
the expectations/assumptions of the Java ecosystem are quite far
apart from those of the Gentoo ecosystem, and if a great solution
is even achievable at all then it certainly requires mastering both
Java and Gentoo, which likely requires Java people to get into Gentoo
rather than the other way around, and both environments have long
learning curves, and until there is a critical mass of developers
mastering both, there can't really be a team. :\


Kind regards

//Peter



Re: [gentoo-dev] We Are All wltjr On This Blessed Day

2017-12-04 Thread Peter Stuge
I'm quite unimpressed by how mgorny and jstein behave there.

I wouldn't accept that, were I leading the project.


//Peter



Re: [gentoo-dev] [RFC] Splitting developer-oriented and expert user mailing lists

2017-12-03 Thread Peter Stuge
Hi Michał,

Michał Górny wrote:
> major problems with some of the posters for more than a year.

Please believe me when I say that I know what this feels like.

I want to applaud and thank everyone who has been tackling/discussing
this issue in private, and I especially want to applaud taking action!

I however disagree with the proposal to move the problem.

I would like to encourage everyone, but in particular devs, to watch
this 18 min talk by Donnie Berkholz from 2012, about Gentoo actually:

Assholes are Ruining Your Project
https://www.youtube.com/watch?v=-ZSli7QW4rg

If you don't want to, then the most important take-away as stated by
Donnie and supported by my own experience having "my" project ruined
is:

Do not tolerate bad behavior by anyone!


> The problems of more abusive behavior from some of the mailing list
> members have been reported to ComRel numerous times. After the failure
> of initial enforcement, I'm not aware of ComRel doing anything to solve
> the problem.

While reading your message, I kept thinking to myself: "isn't this
the very purpose of ComRel?"

I only have a non-dev understanding of ComRel, but I agree with Matt that
inaction in this situation is a failure of ComRel, and that should not be
to the detriment of any constructive contributor on gentoo-dev.


> A. Bans can be trivially evaded
> B. People should be allowed to express their opinion

Mh, so-so. It is important to take action which clearly rejects
unacceptable behavior. Otherwise any behavior is per definition
implicitly accepted, which attracts assholes.


> C. The replies of Gentoo developers were worse

This should *also* not be accepted. Equal standards for what is
acceptable and what is not must apply to everyone.

It could be argued that different people deserve different sanctions.
I would agree with that only as far as there is a mentoring process in
place, requiring a third party to work on eliminating bad behavior.

I think that's the purpose of DevRel for developer<->developer, and
ComRel for developer<->non-developer.

Yes, such mentoring requires a non-negligable committment to
non-trivial work.

It is clearly not always possible to mentor bad behavior away. Then
that person must be shut out to save the environment, whether a
long-standing developer or not!


Coming back to the concrete proposal, I think a better course of
action is to demonstrate strong leadership, by speaking out in force
against bad behavior, every time.

In order to have something to lean on, it can be super helpful to
have a code-of-conduct in place, and was already mentioned.

I had to think about code-of-conduct for a long time, before my
mental model of them "clicked". I consider them to be about
explicitly stating the community expectations for good behavior,
and as an agreed-upon reference for (sometimes unpleasant, but
incredibly important) forceful action in reponse to bad behavior.


> The alternative suggested by ComRel pretty much boiled down to 'ignore
> the trolls'.

I find this highly inadequate.


I urge either ComRel or other leadership to take as forceful action
as is neccessary against bad behavior, to uphold a healthy
environment.

Selective moderation is a more technically sophisticated ban. If
possible that's cool. If not possible that's perfectly fine. Just
ban. Keep banning if the bad behavior resurfaces with another
identity.

Please do not relent. It is not fair to yourself or your colleagues.


Thank you and keep up the excellent effort everyone

//Peter



Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote:
> Or uber minimal, can't get much smaller still 5.20s
> https://travis-ci.org/Obsidian-StudiosInc/asspr#L165
> https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac

Consider

AM_INIT_AUTOMAKE([foreign no-define no-installinfo no-installman])

foreign in particular if you would like to skip the various UPPERCASE
files in the project root.


//Peter



Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote:
> Or uber minimal, can't get much smaller still 5.20s
> https://travis-ci.org/Obsidian-StudiosInc/asspr#L165
> https://github.com/Obsidian-StudiosInc/asspr/blob/master/configure.ac

That takes 2.0s here, on quite old hardware, though with primed cache.


> #secondsmatter :)

Yeah! :)


> The dependency aspect I agree with 100%. I think even cmake has more.

cmake itself is the dependency. ;)


> Or who cares about end users, its all about saving devs time, no clue.
> #mesonbandwagon

End users generally consume behind a distribution build process, so
yes, it's all optimization for development time, which makes some sense.


//Peter



Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-24 Thread Peter Stuge
William L. Thomson Jr. wrote:
> I cannot understand why systems get faster, yet configure seems to
> take the same amount of time and is super slow.

The generated configure scripts can be fork intensive, which is still
fairly expensive.

But I think the problem is more with poorly written configure source,
which is the argument about mastering..


> On small projects configure can take longer than compile... Configure
> is my main gripe against make/autotools. Plus all the other stuff,
> auto-reconf, autogen, etc.

configure having zero dependencies is the killer feature compared
to all other options. The tight integration between configure and
cross-toolchains is also a very strong point.


> The larger the project, the slower configure can be.

Doesn't have to be, but it's easy to write poor configure source and
difficult to write good source.


//Peter



Re: [gentoo-dev] Re: cmake + ninja vs autotools

2017-11-23 Thread Peter Stuge
Martin Vaeth wrote:
> > 1.  Doing a full clean build [..] the speed of make or ninja is hugely
> > offset by the compilation speed, and their overhead is negligible.
> 
> It depends on the definition of negligible. For huge projects like
> boost or chromium it is several minutes

It's arguably a bug that a projects gets huge.

The simplicity of configure+make is difficult to beat, but I also
agree that it's difficult or at least tedious to master autotools.

That is arguably reason enough to choose meson, but I think I will
stay with autotools for a while..


//Peter



Re: [gentoo-dev] Java 9 on Gentoo

2017-11-17 Thread Peter Stuge
William L. Thomson Jr. wrote:
> > If you have any suggestions as to what I should look at to better
> > understand the OpenJDK build system I would very much appreciate
> > them.
..
> Build OpenJDK stand alone. Get familiar with that.

It used to be that one could not build OpenJDK without already having a
working JDK. Has that changed with OpenJDK 9 (IIRC it was planned for
OpenJDK 7 :) or not yet, and that is a reason for having icedtea in the mix?


//Peter



Re: [gentoo-dev] Package up for grabs

2017-08-23 Thread Peter Stuge
Michał Górny wrote:
> W dniu nie, 23.07.2017 o godzinie 16∶13 +0200, użytkownik Manuel Rüger
> napisał:
> > dev-libs/libgit2
> 
> I'm going to co-maintain this with the full set (-glib, pygit2). I've
> used it in the past, and I think it'll still come in handy
> in the future.

I too have some interest in libgit2, but not much experience with
upstream. I'm thrilled that leio and mgorny are on it, I don't think
I can contribute much.


> > net-libs/libssh2
> 
> I'll co-maintain this as well as an important dep of libgit2.

FYI I'm part of upstream. The project mailing list is a perfect point
of contact, but you can reach out to me as well.


//Peter



Re: [gentoo-dev] Changing PMS to Portage Manager Specification

2017-08-14 Thread Peter Stuge
Alexander Berntsen wrote:
> While the PMS perhaps hasn't been an unequivocal success, it's still a
> good effort with some success. I would be disappointed to see the
> proposed change, and view it as a bad sign for Gentoo.

As far as technical documentation about how ebuilds work (the core of
Gentoo, but also many other distributions; I have created several of
my own), PMS is an absolutely amazing document!

It comes down to whether Gentoo is a "meta-distribution" with
absolutely amazing generic tooling (including portage), or "simply" a
source-based distribution with an arbitrary package format.

PMS has tremendous value, and yes, EAPI is a process, and I am sure
that portage developers gnash their teeth at blockers stemming from
PMS, but I wholeheartedly believe that Gentoo, PMS and Portage are
all better off for it.

Without knowing specifics I guess I would suggest to the original
poster to create new tooling for the job that needs to be done. Maybe
even a fork of portage, at first only used in your (derivative)
Gentoo distribution? Just my idea for a possible solution.


//Peter



Re: [gentoo-dev] Allow variable refs in HOMEPAGE

2017-08-04 Thread Peter Stuge
Michael Orlitzky wrote:
> All this is to say that "easy to read" is in the eye of the beholder.
> For ebuilds in the tree, the beholder is usually the maintainer, which
> is why I think the choice should be left up to him.

I think what mgorny says is that locality of ebuilds is an important factor.


> Our ebuilds are bash programs, and in source code, "as little
> duplication as possible" is a strong contributor to "easy to read."

Here's an idea: Could a little bit of automated (but obviously checked!)
de-duplication be made [an optional] part of adding an ebuild into the
tree, and please everyone?


//Peter



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

2017-07-25 Thread Peter Stuge
Michael Palimaka wrote:
> The 30 day waiting period is useful for smoking out major upstream bugs,
> but can't replace stabilisation integration testing. For example,
> package foobar may build fine in ~arch but fails in stable because it
> needs a newer libbaz.

So that's either because of an ebuild bug (incorrect DEPEND) or an
upstream bug (e.g. incorrect PKG_CONFIG_CHECK in configure.ac), right?

It seems to me that waiting (random()=30) days and then testing
against (random()=current-version) libbaz in stable isn't amazing. :)

The ebuild bug could be detected automatically for upstreams using
configure.ac and maybe also cmake.

The upstream bug, well, that's a bit more tricky.


I'll try to write a thoughtful response in the other part of this
thread later. Gotta run now. Thanks everyone for your insights!


//Peter



Re: [gentoo-dev] New eclass: opam.eclass

2017-07-25 Thread Peter Stuge
Good work on the refactoring!

Alexis Ballier wrote:
> > >   if [ -d "${ED}/usr/share/doc/${PF}/${PN}" ] ; then  
> > 
> > It’s always been recommended to me that we should use the [[ … ]]
> > form.
> 
> Doesn't make much difference here

Some; you need neither quote nor {} in expansions within [[ ]]. So
instead of the above one could write:

if [[ -d $ED/usr/share/doc/$PF/$PN ]]; then


> and I've always been recommending the other way :p
..
> if you only do ebuilds or bash, then you don't care, but I definitely
> do other scripts

Be that as it may this is an eclass, and I think conforming to an
established coding style has significant value. I too have understood
that to be [[ ]].


Thanks

//Peter



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

2017-07-24 Thread Peter Stuge
Thank you for working on this.

Sergei Trofimovich wrote:
> Can this proposal make a difference and make gentoo better and
> easier to work with?
> 
> Does it try to attack the right thing?
> 
> Does it completely miss the point?

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.

Based solely on how excellently unstable (and similar approaches before
using Gentoo) works for me in practice, I believe that skipping stable
and instead focusing efforts on resolving problems reported in unstable
a little quicker would yield a much better end result - and would net
positive dev time.


> Does it sound fun?

Sorry, no, not to me. It sounds like "double" overhead. :\


I consider dev time a precious resource. Devs should need to do as
few things as possible, to keep things going, and should be able to
immediately reuse as much input from the wider community as possible.

More troubleshooting and fixing "hard" problems, less routine work.


//Peter



[gentoo-dev] Sanity check: enewuser in binpkg with portage-utils

2017-07-20 Thread Peter Stuge
Hi,

I have some ebuilds which use enewuser to create groups and users in
pkg_setup(), and make use of those groups and users in src_install()
in exeopts, insopts etc.

Is there any reason that this would not always work reliably with
binpkgs?

Ie. regardless of whether I am using portage or portage-utils to
install binpkgs with such pkg_setup() and src_install() combinations?

Should it matter if the groups and users already exist? I expect no.

I would expect it to always work reliably, because exeopts/insopts
user and group arguments are looked up by install at run time.

I think I had a problem with this yesterday, but I can't reproduce it.


Thanks

//Peter



Re: [gentoo-dev] Integrating Ada into toolchain.eclass, again

2017-05-20 Thread Peter Stuge
Luke A. Guest wrote:
> Thoughts?

I can't comment on your strategy, but I do agree with and support
your goals of being able to use more Ada in Gentoo.

Thanks to you and others for your work on this! :)


//Peter



Re: [gentoo-dev] [RFC] Master plan for fixing elibtoolize

2017-03-18 Thread Peter Stuge
Alexis Ballier wrote:
> > If elibtoolize results in different binaries being produced, then it's
> > done wrong in the first place. AFAIU the primary goal of elibtoolize
> > logic is to fix issues on recent systems with outdated build systems.
> > Which is certainly not something that needs to be done for every user
> > out there.
> 
> You probably didn't have a look at what the patches fix. Having a
> quick look at patches there,

Where are those patches you mention?


> I could fine one fixing relink to old libs (from / instead of $D),

I have an open bug for this for a package, both in Gentoo and
upstream. It seems to be a problem with libtool itself, is that
about right?


> another one fixing parallel install. The former produces broken
> binaries, the latter none at all.
> 
> I seriously doubt this shouldn't be fixed for every user.

What "this" do you refer to? Sorry for the confusion, I want to understand.


//Peter



Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-11 Thread Peter Stuge
Anthony G. Basile wrote:
> >> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
> >> against the bitcoin eclass.  The following is his proposed change.
> >> I'll commit it after review.
> > 
> > Please do not do that, Anthony.
> 
> I don't have time nor the familiarity to properly maintain bitcoins
> myself.

Understood, and no problem. I think it's especially important to be a
bit conservative under those circumstances.


> I will ignore all negative advice regarding this package unless it is
> balanced with positive advice.

That's cool. I tried to also be constructive in my mail - sorry if
that didn't get through. I was saying that the patched version should
probably be a separate ebuild.

But Mathy's (sorry for the mistype in my last mail Mathy) suggestion
to go ahead with renaming the USE flag but *not* flipping it to
default on is also a good step.


> Please point out what lines of the patch should be changed and what
> they should be changed to, else I will commit the patch as
> provided.

All lines containing +knots should say knots instead.


Thanks!

//Peter



Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-07 Thread Peter Stuge
Anthony G. Basile wrote:
> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
> against the bitcoin eclass.  The following is his proposed change.
> I'll commit it after review.

Please do not do that, Anthony.


> Bitcoin Knots includes a number of enhancements users may find useful. I
> think  it would be a good idea to make it the default for Bitcoin
> ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).

I can only interpret this patch one way: sshole takeover attempt

I disagree very strongly. >:( Matt's suggested approach (separate
bitcoin-knots ebuild) seems like the right thing to do. I assume
there is no binary incompatiblity between the two packages?


Luke-Jr: I hope you're not maintaining a patchset, but a separate
project. A patchset would be utterly silly, since it causes
completely unneccessary user confusion.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Peter Stuge wrote:
> --8<-- mount(8)
..
>   portable. The mount(8) command internally uses udev symlinks
> -->8--

That's of course only the mount in util-linux.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Ian Stakenvicius wrote:
> > WilliamH wants everyone using /dev/disk/by-label/
> > paths in fstab to instead use LABEL= , to avoid issues if udev
> > doesn't create the symlinks before localmount tries to use them.
..
> UUID is the same situation in this case -- in fstab you can do it by
> UUID= or you can do it by /dev/disk/by-uuid/.  The latter
> form depends on udev finishing up and would have the same issue.

It seems that the former form may also depend on udev having settled.

--8<-- mount(8)
   The device indication.
..
  The recommended setup is to use tags (e.g. LABEL=) rather
  than  /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks
  in the /etc/fstab file. The tags are more readable,  robust  and
  portable. The mount(8) command internally uses udev symlinks, so
  use the symlinks in /etc/fstab has no advantage over  the  tags.
  For more details see libblkid(3).
-->8--

Oops. Let's look further:

--8<-- libblkid(3)
   The  high-level  part  of  the library supports two methods to evaluate
   LABEL/UUID.  It reads information directly from a block device or  read
   information  from  /dev/disk/by-*  udev symlinks. The udev is preferred
   method by default.
-->8--

..so when is the non-default method (querying devices) used?


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Peter Stuge
Rich Freeman wrote:
> We give you the tools when you install your system, and we give you
> the tools when it is time for renovations...

On that note - thank you very much to everyone who contributes to Gentoo!

<3


//Peter



Re: [gentoo-dev] Commented packages in the @system set

2016-10-26 Thread Peter Stuge
waltd...@waltdnes.org wrote:
> For a build-from-source distro like Gentoo, gcc and associated
> tools are a vital part of the distro.

A stage4 created (and updated) on a catalyst build farm doesn't need
to have gcc, but may still need libstdc++.


//Peter



Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

2016-10-26 Thread Peter Stuge
Rich Freeman wrote:
> I think you could make an argument that voluntarily placing that
> header on your work is an assignment of copyright.
> You could also argue otherwise.

Especially in jurisdictions where copyright can not be assigned.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Peter Stuge
Ian Stakenvicius wrote:
> by mount and works regardless of device manager, therefore removing
> the the dependency of having udev-settle before mounting these paths.

the the


Looks good. Thanks.


//Peter



Re: [gentoo-dev] Commented packages in the @system set

2016-10-26 Thread Peter Stuge
Raymond Jennings wrote:
> Why exactly isn't libstdc++ a separate package anyway?

I guess because it has no separate upstream.

I think a separate package would be a fantastic improvement though.


//Peter



Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

2016-10-18 Thread Peter Stuge
Patrice Clement wrote:
> We should strive for keeping a clean and linear history.

I agree with you.


> Cherry-picking is not my go-to solution as far as I'm concerned.
> It requires a bit of setup and is clearly tedious: you must know
> in advance the full SHA-1 of commit(s) you want to cherry-pick.

git cherry-pick master..pr1234 # picks all commits on pr1234 not on master

This is essentially a "manual" rebase of pr1234 onto master.

Demo time. Preparations:

$ git config --global alias.la 'log --oneline --graph --decorate --all'
$ export PAGER=cat


Assume the following repo:
$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

git cherry-pick master..pr1234 would apply b2 and c onto master:

$ git cherry-pick master..pr1234
[master 305532b] b2
 1 file changed, 1 insertion(+)
 create mode 100644 b2
[master d18f1ac] c
 1 file changed, 1 insertion(+)
 create mode 100644 c
$ git la
* d18f1ac (HEAD, master) c
* 305532b b2
* ccbc288 d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ 

If the pr1234 branch has some value once b2 and c are in master then
this is a good way to do it, the main drawback IMO that it leaves a
repetitive and redundant pr1234 branch behind.


Another way would be to simply rebase the pr1234 branch. Disclaimer: I
don't know GitHub processes and assumptions, so rebase might suck for this.

If noone cares about the PR branches once they have been merged/closed
(I got that impression from your mail) then rebase may be a good choice.

$ git la
* ccbc288 (HEAD, master) d
* d33a95b b
| * 3e5b52e (pr1234) c
| * 6491f93 b2
|/  
* 2dfcb95 a
$ git rebase master pr1234
First, rewinding head to replay your work on top of it...
Applying: b2
Applying: c
$ git la
* 92417d4 (HEAD, pr1234) c
* 385ca8c b2
* ccbc288 (master) d
* d33a95b b
* 2dfcb95 a
$ 

At this point, pr1234 can be fast-forward merged into master:

$ git checkout master
Switched to branch 'master'
$ git merge --ff-only pr1234
Updating ccbc288..0565e44
Fast-forward
 b2 | 1 +
 c  | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 b2
 create mode 100644 c
$ git la
* 0565e44 (HEAD, pr1234, master) c
* 0dbfdf8 b2
* ccbc288 d
* d33a95b b
* 2dfcb95 a
$ 


> You may or may not know about it but a PR can be fetched as a git
> am-compatible patch.
..
> https://github.com/gentoo/gentoo/pull/1234.patch

Didn't know - that's pretty handy!


> $ cd /home/patrice/gentoo
> $ pram 1234

Nice work! I might have made a git pr alias instead, but pram seems
way more flexible than that would be.


Finally, while I do agree with you, the one and only reason IMO to
live with merge commits is that they implicitly preserve the branching
point. For source code that can be useful, but for ebuilds less so.


//Peter



Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Peter Stuge wrote:
> How can I help improve ..?

Michał Górny wrote:
> people focused on preaching and/or implementing random crap-based
> solutions without even stopping for a few minutes to consider what
> we exactly need.

You could interpret my question as "what exactly do we need" ?


> GitHub works for us. GitHub works for our contributors. GitHub
> boosts our productivity, unlike those vain discussions.

Windows works for me. Windows works for my customers. Windows
boosts my business, unlike vain discussions about open source
and free software. ;) Maybe you get my point?


> We don't have time for all this tin foil hat nonsense.

I think we have all the time in the world, and I think it's important
for us to innovate also in this field if neccessary, as we have and
continue to do in other distro-development-related fields.


Thanks

//Peter



Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Michał Górny wrote:
> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> That's the most convenient solution for most of proxy-maint team members.

How can I help improve that problematic situation?

It's not cool to gravitate the project towards GitHub Inc.


//Peter



Re: [gentoo-dev] Re: Packages up for grabs

2016-08-06 Thread Peter Stuge
Felix Janda wrote:
> I'd like become a proxy-maintainer for app-editors/nvi.

Sweet! If there are some open bugs then please upload patched ebuilds
and other neccessary files to the bugtracker, ideally as output by
git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
to get someone to proxy them into the tree for you.

https://anongit.gentoo.org/git/repo/gentoo.git


//Peter



Re: [gentoo-dev] Packages up for grabs

2016-08-06 Thread Peter Stuge
Andrew Savchenko wrote:
> On Sat, 6 Aug 2016 13:37:19 +0000 Peter Stuge wrote:
> > Hi Pacho, many thanks for your work, but..
..
> > ..do you think you can arrange to post everything in one mail,
> > instead of 14 different ones in a single day?
> 
> I suppose these posts are automated (at least partially), since
> each of them is linked to a different retirement bug.

That would explain the many emails - then it will probably be halfway
straightforward to also bundle the bugs and send one email at say 2:00 am
or whenever is a likely time that Pacho is not doing retiring. :)


> So you shouldn't blame Pacho for his work.

I don't think I was - I wanted to nudge to improve the output of his work.

I like to follow what gets retired, in case I want to pick something up,
but I don't like to read 14 emails in one day with a few packages in each.


Another, maybe simpler, approach would be to have a stateless cronjob
instead of a queue, the job would just look at what retirement bugs
were changed (opened?) in the last while (day?), and send one email
listing all packages. Maybe it could also set some status in the bug,
to avoid duplicates because of DST or whatever.


Thanks a lot

//Peter



  1   2   3   4   5   6   >