Guys - we have resolved this off list. No need for more discussion.
Best,
Matthias
For the whole patchset:
On Mon, Jul 29, 2019, at 13:24 CDT, Mike Gilbert wrote:
> Signed-off-by: Mike Gilbert
Acked-by: Matthias Maier
signature.asc
Description: PGP signature
I will take care of app-misc/hello.
It is after all one of the most essential packages of the GNU project.
Best,
Matthias
On Sun, Aug 18, 2019, at 07:32 CDT, Michał Górny wrote:
> Hello,
>
> Due to the retirement of their only maintainer, the following packages
> are now up for grabs:
>
> ap
profiles/package.mask: mask app-admin/webmin for removal
# Matthias Maier (2019-08-22)
# Masked for removal in 30 days. Unmaintained and upstream has released
# backdoored versions for more than a year due to a compromised development
# server, http://www.webmin.com/exploit.html
app-admin/webmin
# Matthias Maier (2019-09-03)
# Duplicate package - use sci-libs/med instead, bug #693146
# (Expedited) removal in 7 days
sci-libs/libmed
As we have a stable mate 1.8 desktop and mate 1.6 related packages start
to pick up a bunch of outstanding issues, I've remove all 1.6 version
for mate packages from the tree. The following list contains
mate-1.6-only packages that will be removed:
# Matthias Maier (20 Dec 2014)
# R
IMHO, maintaining a sensible set of old glibc versions of the last 5
years makes sense, and we should try to support it:
> +1 from me. I cannot think of any scenario where we need to keep such
> old glibc versions around.
One scenario is to create a cross-compile toolchain with specific old
versi
> +1 for an "archive overlay"
This sounds like a reasonable compromise.
For the toolchain.eclass problem you mentioned. We could just version
the eclass as needed, something like toolchain-crossdev-vX.eclass. With
this development on the main repository is independent and we would
still have old
I'm a bit surprised about this discussion as Mike, who currently
maintains the toolchain, has never implied that suddenly older versions
of glibc are unusable. Or that we need a big cleanup.
He simply stated two facts (that have been true for a long time)
- for a current kernel a current toolcha
Am 23. Dec 2014, 16:51 schrieb William Hubbs :
>> just the simple fact that crossdev without the ability to select
>> specific versions of glibc is only half as useful. And please, do not
>> underestimate the usefulness of our crossdev script in this regard!
>
> I'm not saying anything about b
> I'm wondering if there is an equivalent of debootstrap of Debian
> anywhere. By equivalent I mean a tool that ..
Given the fact that such a tool only has to handle 3 files (tarball,
digest + signature file) I guess there was never much need for such a
thing.
> * I can run like "command FOLDE
Am 29. Dec 2014, 09:46 schrieb Zac Medico :
> In order to implement something like this for Gentoo, we could add
> PROVIDES_EXCLUDE and REQUIRES_EXCLUDE ebuild metadata variables. These
> variables would be used to automatically generate PROVIDES and REQUIRES
> data for binary packages, based on
Thanks for the detailed explanation.
Best,
Matthias
>
> I'm going to write a devmanual patch but don't want to sound like a lunatic.
>
Also, an informal definition on what is supposed to be appropriate
hardware and userland (e.g. clean amd64 profile) and what are keywording
best practices would be nice to have. (Alternatively a link to the
respect
Am 09. Jan 2015, 23:42 schrieb Diamond :
>> [...] (that's why I used all
>> that LXC and separate X server precautions).
>
> Can you give any reference about how to isolate Skype properly using
> LXC?
I'm also interested in the separate X server part =)
> Any comments?
Sounds good!
> So can someone please remind me what are the technical reasons why we
> prefer libav over ffmpeg?
*ugh* Please no.
What about leaving the default (if there ever was such a default) as it
is and avoid the otherwise imminent trainwreck?
Best,
Matthias
signature.asc
Description: PGP signature
> Thoughts?
One point in favor of the current practice (installing add-on files
unconditionally) is the fact that you can basically do it for free - you
neither have to depend on additional packages, nor is the presence of
the add-on files a penalty in download time or storage.
Further, a lot of
gcc upstream has at least unified the C++98(03) and C++11 abis in gcc-5
[1] and declared the C++11 abi stable. This could resolve [2] in the
"near" future..
Best,
Matthias
[1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
[2] https://bugs.gentoo.org/show_bug.cgi?id=542482
Just a bunch of packages I'm no longer interested in (and that are
hardly useful to begin with...):
app-misc/grabcartoons
sys-apps/conspy
sys-fs/safecopy
Best,
Matthias
signature.asc
Description: PGP signature
> Users can fetch/pull from Github.
We could also provide automatic signed tags every 30min/1h/2h/whatever
(signed with a suitable infrastructure key). With that, the integrity of
a tagged git checkout can be easily verified on client side.
Best,
Matthias
signature.asc
Description: PGP signatu
> That is, I was under the impression signing a tag only signs the
> references themselves, and then relies on SHA1 referential integrity
> beyond that.
No, a signed tag verifies that the whole integrirty of the entire
repository, whereas a signed commit only authenticates the differences
introduc
> it would have to re-use the same tag name every time otherwise we end up with
> 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea
Or we supply a signature of the sha1-sum of the tag in question by some
external procedure...
Best,
Matthias
signature.asc
Description: PGP signat
On Mon, Aug 10, 2015, at 22:56 CDT, Kent Fredric wrote:
> So how is GPG verifying "The whole repository" ?
You can verify the state of the repository via
$ git fsck
after that you can verify that the current HEAD is tagged with a valid
and singed tag with something like
$ git tag -v `git
> constantly adds any security to the tree. What might add security for
> end-users is if git automatically checked the push signatures, which
> are the signatures that ensure that branches aren't tampered with
> (which is what rebasing you bring up actually does).
It is news to me that a signat
> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line. If I have missed something, can someone
> fill me in, or if it isn't useful any more can we consider removing it?
It is possible to define custom keyword expansions for $Id$ with
.gitattributes
> They will be OpenPGP signed by a releng key during thickening and
> portage will auto-verify it using gkeys once things are in place. As
> such checksum for ebuilds and other files certainly needs to be part
> of the manifest, otherwise it can open up for malicious alterations of
> these files.
On Fri, Aug 14, 2015, at 15:04 CDT, Andrew Savchenko wrote:
> On Thu, 13 Aug 2015 19:19:10 +0800 Ben de Groot wrote:
>> I vote for a simple
>>
>> Bug: 333531
>
> +1
>
> Of course, for external bugs (e.g. in other projects) full URI
> should be used.
+1
signature.asc
Description: PGP signatur
On Wed, Sep 9, 2015, at 09:17 CDT, Doug Goldstein wrote:
> The following is the proposed news item to inform OpenRC users of a
> change to the init script setup for libvirt 1.2.19 and newer.
+1 Looks good.
signature.asc
Description: PGP signature
Cardoe's second mail didn't make it to the list.
Please find attached the second mail and the updated news announcement.
=
On 9/9/15 9:17 AM, Doug Goldstein wrote:
> The following is the proposed news item to inform OpenRC users of a
> change to the init script setup for libvirt 1.2.19 and n
Just a comment before this discussion gets entirely side tracked.
On Mon, Oct 12, 2015, at 11:45 CDT, Ian Delaney wrote:
> [...]
> Users are neither seasoned nor prepared for the type of review put
> upon them by him and mgorny.
My impression is that the reception of the code review on githu
On Wed, Nov 11, 2015, at 15:52 CST, "Jason A. Donenfeld"
wrote:
> I'd be in favor of full-on LC_ALL=C.
++
I'm surprised that we do not have such a policy already.
Best,
Matthias
# Matthias Maier (06 Jan 2016)
# Obsolete package, nowadays bundled with media-sound/quodlibet
# Masked for removal in 30 days
media-plugins/quodlibet-plugins
signature.asc
Description: PGP signature
> I'd have to check but I suspect that portage hangs onto build-time
> dependencies by default, probably so that you're not uninstalling them
> and reinstalling them anytime you do anything. Strictly speaking,
> however, it would be safe to depclean anything that is only a
> build-time dependency
On Mon, Jun 1, 2020, at 15:27 CDT, Michał Górny wrote:
> 2020-08-01 Python 3.7 migration deadline
>
>After this date, we lastrite all remaining packages that haven't been
>ported. This gives people roughly two months, with a ping one month
>from now.
> [...]
> 2020-12-01 Python
Dear all,
Due to some work related crunch time I had very limited time lately to
properly maintain the following packages of the virtualization stack:
app-emulation/libvirt
app-emulation/libvirt-glib
app-emulation/libvirt-snmp
app-emulation/lxc
app-emulation/lxc-templates
app-emulatio
Hi William,
I have migrated my system to a merged /usr a while ago.
In addition to moving everything to /usr and setting up symlinks, the
main thing I had to do was to set up a /etc/portage/bashrc hook for
post_src_install() that would move everything into /usr.
Do we have native support in port
101 - 137 of 137 matches
Mail list logo
