ime what would happen if we had a clearly
recognizable AI as a user that made (reasonably) sensible posts. We would then
have no chance of banning this AI user without an explicit prohibition. I
would be much more comfortable if we clearly communicated that we do not
accept an AI as a user.
Yes, I would also be very happy to see this proposal implemented.
--
Best regards,
Peter (aka pietinger)
Hello Eli,
Maybe add also a link to:
https://wiki.gentoo.org/wiki/Early_Userspace_Mounting
(IMHO this article is a better starting point than
https://wiki.gentoo.org/wiki/Custom_Initramfs )
Many Greetings,
Peter
. I don't
know if the effort is actually practical for you but it /is/ doable and
most importantly it can be customized for the individual systems
currently in production at your customers.
//Peter
Peter Stuge wrote:
> Essentially you will be maintaining a private fork of gentoo.git,
If this seems too heavy handed then you can just as well do the reverse:
Maintain an overlay repo with the packages you care to control in the
state you care to have them, set that in the catalyst stage4.s
rballs (and binpkgs) from snapshots of that repo.
emerge can install binpkg at least from FTP.
//Peter
It's one of a few different methods (by far the most common) to
access networked printers so it may not be so misplaced in net-print.
//Peter
ng from upstream, or a withdrawal of the CVEs, or a notice from
> the CVE reproters that they're invalid. But I really don't understand
> why anybody cares about this leaf package that nobody actually seems
> to use, including you.
Imagine that I fork boa to a project called boah, change nothing but
the version number, create a release and then tell you again that the
three CVEs are invalid for both boa and boah.
//Peter
t work better because we react indiscriminately to CVEs",
> > that's an honest answer (thank you!) but not great quality. Does
> > everyone mostly agree with that policy?
>
> It generally can't work better with MITRE being useless in many
> cases. Yes, the CVEs seem garbage, but I can't say that
> authoritatively, so I don't.
What would convince you?
Thanks a lot
//Peter
ds with actual problems be masked?
Even if there's currently no possibility to emerge other packages
which depend on that it seems incorrect to mask those other packages
only because a dependency can't be emerged?
I don't think portage cares; it will show sbcl masked if it is a
dependency, right?
Thanks
//Peter
John Helmert III wrote:
> So much yapping on the mailing lists, and no response in the bug which
> triggered the last rites...
Apologies if I responed in the wrong forum. I thought on list would
be good, why are those mails on the list if not?
> So, Peter, do you use Boa?
Not right n
istently remains one strong reason for me
to *not* become a Gentoo developer.
Kind regards
//Peter
liances which use boa. They have nothing to do with boa itself.
The named files do not exist in the boa package.
Shouldn't this process work a lot better?
Thanks
//Peter
d:
$ git status
# On branch master
nothing to commit, working directory clean
$
The v0.4 tag in bdrewery/vchkuser also equals the commit hash in the
directory name of the .tar.gz. (This is of course weak.)
//Peter
till functional?
I don't use it, I use something else for the same task.
Looking up the GitHub user that person seems present, just that
particular repo is no longer there.
Searching for the repo name on GitHub finds this however:
https://github.com/bdrewery/vchkuser
..which seems to be a 2010 version of the code. I did a test, it works
fine. Maybe just change the SRC_URI.
//Peter
e if "Upstream Homepage and
SRC_URI is gone" and "Gentoo is the last distro with this package"
are the only reasons...
Thanks
//Peter
many regards and it makes me really
sad whenever Gentoo changes based on nothing more than "others did it".
Thanks and kind regards
//Peter
mance.
Right?
//Peter
ook
(with a clue to delete it if not desired).
Kind reagards,
Peter
ble 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
t 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
d 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
ank you for your work!
//Peter
o 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
that (swlicense_says_yes && patent_says_yes)
is guaranteed to be true at the cost of functionality?
//Peter
hon or perl. A quick look into
the source code seems to confirm that there's no strong tie to Python.
//Peter
uded well - kernel maintainers who
want can support it. Everyone who considers it pointless can ignore it.
All good.
Kind regards
//Peter
Marco Scardovi wrote:
> mail-filter/bogofilter
I'd like to proxy-maintain this.
//Peter
> 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
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
r of statically enabling them
That is the direct opposite of Gentoo's single most core value: choice
Just don't do it. Kthx.
//Peter
mber} ]] && return 0
> + if [[ $[number % i ] == 0 ]]; then
An inconsistent space after "% i" here. I don't know what style is correct.
//Peter
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
rather messy database USE logic..
//Peter
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
; taking on p-m of it.
Hank, please feel free to ping me for another pair of eyes or Cc me on bugs.
//Peter
easeweazle
And these ready-to-buy products:
https://shop.deviceside.com/prod/FC5025
https://www.kryoflux.com/
Kind regards
//Peter
ly 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
mething
> 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
nt 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 a
g them manually in your screenshot I get 36.
That's not a whole lot; just 7% of 500.
//Peter
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
rlook 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
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 nothin
lling off GTK:2" in Gentoo?
Are there (presently or foreseeable) technical issues with GTK:2?
Many thanks and kind regards
//Peter
3. Have it always use some fixed compiler somewhere (ie, compile it
4. Make gcc-config regenerate libtool, otherwise as 2.
//Peter
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
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 some things.
Kind regards
//Peter
eed 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
ovider 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
t; 3. Eventually remove LibreSSL.
4. A libressl or libressl-libtls ebuild installs only libtls.
//Peter
tim and engage with my proposal instead.
I'd appreciate feedback from everyone.
Thanks a lot
//Peter
lthy 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
;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
est 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
th 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
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
ly 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
appreciate your openness. I'm asking essentially to
keep options open, so that the ecosystem can be improved step by step.
Thanks
//Peter
ce
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
d 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
aste 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
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
a)
That's also technically possible.
I'd personally prefer the latter.
//Peter
r all.
So should virtual/tmpfiles differentiate based on system?
//Peter
'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
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
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
roblem?
(Security, maintainability, etc.) If there is, then please mention it.
//Peter
aid,
if the two are interchangeable then a virtual/getmail ebuild would
probably be reasonable.
//Peter
gt; Your contribution is welcomed.
What contributions are known to be needed at the moment?
Kind regards
//Peter
x27;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
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
. 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
padd -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
installed values of
> these are worthless.
E.g. for auditing the installed values of these could be worth a lot.
Thanks!
//Peter
stalled 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
to do it.
If noone else wants to take this then you can add me as proxied maintainer.
//Peter
[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
beginning with net-misc/openssh-7.7_p1 the OpenSSH-LPK
patch set is deprecated and no longer applies."
Thanks a lot!
//Peter
clever trick with a profile for each desired USE flag?
Somehow dynamic profiles? Dunno - just an idea.
Thanks!
//Peter
ility.
> This should satisfy line length limitations,
My counter-proposal is to bup the repoman line length limitation.
//Peter
Johannes Huber wrote:
> I will take it.
Thanks. I can help as proxy-maintainer if you like.
//Peter
weakened security.
//Peter
in that one mail.
I would not vote for you, and would vote against you if that's even possible.
//Peter
stable release will be
out. It's much better to have this version package masked. Then in package
mask comment we could note the need for backup.
--
Peter.
uot;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
hey'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
h
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
I'm quite unimpressed by how mgorny and jstein behave there.
I wouldn't accept that, were I leading the project.
//Peter
ve 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
man])
foreign in particular if you would like to skip the various UPPERCASE
files in the project root.
//Peter
uild process, so
yes, it's all optimization for development time, which makes some sense.
//Peter
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
utes
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
enJDK 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
ething but this should work out of box:
https://wiki.gentoo.org/wiki/Binary_package_guide#Web_based_binary_package_host
Or do you mean something else?
--
Peter.
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
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
part of adding an ebuild into the
tree, and please everyone?
//Peter
ges
that do not specify minimum required versions for dependencies. Thus we had
to duplicate maintainer's work and check lot's of dependencies again.
Also when we speak about stable tree we first should define what stability
are we talking about? What do we guarantee? ABI/API compatibility or that
it is expected "just work" (whatever this means)?
--
Peter.
1 - 100 of 1120 matches
Mail list logo
