Dear all,
I have had little time to contribute to Gentoo over the last 24
months. Therefore, I need to downsize in actively maintained packages.
I will drop myself as maintainer from the following packages in the next
couple days. Please adopt them if you're interested:
app-crypt/efitools
a
On Tue, Feb 27, 2024, at 08:45 CST, Michał Górny wrote:
> Given the recent spread of the "AI" bubble, I think we really need to
> look into formally addressing the related concerns. In my opinion,
> at this point the only reasonable course of action would be to safely
> ban "AI"-backed contribut
On Tue, Feb 13, 2024, at 02:39 CST, Sam James wrote:
> Hi,
>
> We should consider adding a .mailmap to gentoo.git.
>
> There's a few reasons:
> [...]
+1
You can add
* allows to fix up accidental commits with wrong e-mails as well. *cough*
Best,
Matthias
On Sat, Aug 26, 2023, at 09:59 CDT, Ionen Wolkens wrote:
> app-shells/zsh
If no one else steps up then I will happily take over zsh
(co)maintenance. But due to limited time lately, :-(, it would be
best if I found a (co)maintainer :-)
Best,
Matthias
On Wed, Mar 9, 2022, at 17:32 CST, Matt Turner wrote:
> I think you just made that number up :)
Nah. My sample was just bad (ago just made a sizable number of commits.
I would estimate the current usage of repoman to be about 20-25%, down
from well over 80-90% back when we just switched to g
On Wed, Mar 9, 2022, at 15:47 CST, Matt Turner wrote:
> [...]
>
> I wouldn't block anyone from doing this, but it's not something I'm
> personally interested in pursuing. I see very little value here.
I did not intend to imply that you should do anything.
I just want to point out that we had b
Just a quick though:
Looking at the man page of repoman it doesn't look to difficult to
replicate the behavior with pkgcheck. Meaning, we could think of
creating a drop-in replacement for "repoman [full]" (which would just
call pkgcheck) and "repoman commit" which actually does much more than
ju
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
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
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
# Matthias Maier (2019-09-03)
# Duplicate package - use sci-libs/med instead, bug #693146
# (Expedited) removal in 7 days
sci-libs/libmed
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
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
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
Guys - we have resolved this off list. No need for more discussion.
Best,
Matthias
> could you please stop sending project related stuff to the -dev mailing
> list? It is irrelevant place to provide bump patches
Why? What's the purpose of a developer mailing list then?
Applied, thanks!
On Thu, Oct 25, 2018, at 10:31 CDT, Michal Privoznik
wrote:
> --- a/app-emulation/libvirt-snmp/Manifest
> +++ b/app-emulation/libvirt-snmp/Manifest
> @@ -1,2 +1,3 @@
> DIST libvirt-snmp-0.0.2.tar.gz 152790 BLAKE2B
> b2e5eee2d67283112556c52921b14029a90d5cedf0c4575e056475191470a
On Mon, Oct 22, 2018, at 08:21 CDT, Michal Privoznik
wrote:
> QEMU upstream has changed a bit and thus we must update our ebuild.
>
> Michal Privoznik (2):
> app-emulation/qemu-: Drop gtk2 use flag
> app-emulation/qemu-: Drop sdl-1.2 support
>
> app-emulation/qemu/qemu-.ebuild
Applied. Thanks!
On Mon, Oct 15, 2018, at 06:47 CDT, Michal Privoznik
wrote:
> virt-manager has dropped --qemu-user configure option in
> e6738d9827492d. Update live ebulid to not pass it.
>
> Signed-off-by: Michal Privoznik
> ---
> app-emulation/virt-manager/virt-manager-.ebuild | 1 -
>
Pushed, thanks!
On Wed, Sep 26, 2018, at 09:38 CDT, Michal Privoznik
wrote:
> Qemu dropped ppcemb target in
> a69dc537cc1a6d3c3cb35d30197ed45914a150c3.
>
> Signed-off-by: Michal Privoznik
> ---
> app-emulation/qemu/qemu-.ebuild | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
On Sun, Sep 23, 2018, at 21:26 CDT, Kent Fredric wrote:
> I personally try to use something of the form:
>
> "Bump version to 12.234.1567"
>
> Mostly, because it gives some vaguely useful context when reading a
> commit summary log, that doesn't necessitate you running "git log -p"
> or "git diff
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote:
> I don't really know the original rationale for this.
>
> The NIST standard says 1-3 years. If I were to guess, I'd say 1 year
> was chosen for subkey because subkey expiring is a 'smaller' issue than
> the whole key expiring, i.e. other
On Thu, Jul 5, 2018, at 08:36 CDT, Michał Górny wrote:
> That said, I'm open to using a different recommendation, e.g. 2 years
> as in riseup [1]. I suppose having the same time for both primary key
> and subkeys would make the spec simpler, and many developers are
> mistaking expiration times
On Tue, Jul 3, 2018, at 11:22 CDT, Matt Turner wrote:
> I'd be happy to switch if the space requirements were similar.
$ git clone --depth=1 https://github.com/gentoo-mirror/gentoo
occupies 662M on my machine (just tested). With full history
(i.e. without --depth=1) I am at 1.1GB.
Best,
Mat
On Mon, Jul 2, 2018, at 12:01 CDT, "Jason A. Donenfeld"
wrote:
> Aren't git signatures done over the full commit objects? Meaning you'd
> need the entire tree of metadata and thus all commits in order to
> verify? Or do you see some clever opportunity for extracting just
> enough metadata tha
088b
virt-manager is strictly python3 only. Update the ebuild to
follow this change.
Closes: https://bugs.gentoo.org/650790
Closes: https://bugs.gentoo.org/647376
Signed-off-by: Michal Privoznik
Signed-off-by: Matthias Maier
On Fri, Mar 23, 2018, at 08:48 CDT, Michal Privoznik
wrote:
> [...]
Applied. Thanks!
Matthias
Hi all,
the next Council meeting will be on Sunday 2018-03-11, 18:00 UTC in the
#gentoo-council channel on Freenode.
We have a fairly short agenda this time:
1. Roll call
2. Bugs with council involvement:
- GLEP 68
[1] https://bugs.gentoo.org/649740
[2]
https://archives.gentoo.org
On Fri, Feb 23, 2018, at 10:01 CST, "Anthony G. Basile"
wrote:
> [...]
> I'm not even sure a news item is needed here. What do people think? If
> you think so, who do I even direct it at?
If there is no action needed on user side and an upgrade and migration
from uclibc to uclibc-ng happens
On Thu, Jan 11, 2018, at 11:34 CST, Rich Freeman wrote:
> It is kind of hard to get new people interested in fixing bugs when
> half the traffic is complaining because the people doing the work
> aren't doing it in a way that makes the people not doing the work feel
> important.
++
On Tue, Dec 12, 2017, at 15:46 CST, Daniel Campbell wrote:
> The following packages are in need of a maintainer:
>
> dev-util/astyle
I will take over this one.
Best,
Matthias
signature.asc
Description: PGP signature
On Sun, Dec 17, 2017, at 07:21 CST, Michał Górny wrote:
> Hello, everyone.
>
> It's my pleasure to announce that with a majority vote the QA team has
> accepted a new policy. The accepted wording is:
>
> Total size of 'files' subdirectory of a package should not be larger
> than 32 KiB. If t
On Wed, Aug 9, 2017, at 15:43 CDT, "Andreas K. Huettel"
wrote:
> Hey there,
>
> it's time we do a proper lead election and have a toolchain meeting again.
>
> So, here's the plan:
>
> 1) team lead election:
> * Nominations from now until August 18, by e-mailing to the toolchain alias
> * Vot
l
>> catalyst runs, and am at the tail end of a fresh install of a
>> sys-libs/uclibc-ng userland on actual MIPS hardware.
>>
>> Signed-off-by: Joshua Kinard
Signed-off-by: Matthias Maier
>> ---
>> eclass/toolchain.eclass |3 ---
>> 1 file change
On Sat, Jul 1, 2017, at 03:55 CDT, James Le Cuirot wrote:
> Funny that no one noticed this for 10 years. :) Thanks to klausman for
> clearing this up.
> ---
> eclass/toolchain-funcs.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/
On Wed, Jun 14, 2017, at 18:15 CDT, Matthias Maier wrote:
> Hello all,
>
> this is a series of patches against the toolchian-funcs and toolchain-glibc
> eclasses, most notably
>
> - introducing new tc-enables-pie(), tc-enables-ssp(),
>tc-enables-ssp-strong() a
> there should be a way of turning these off systematically. the
> advantage of the current hardened gcc specs is that one can switch
> between them using gcc-config. if these are forced on for the default
> profile then there will be no easy way to systematically turn them off.
No - there won't
Hi Michael,
On Sun, Jun 11, 2017, at 16:39 CDT, Michael Brinkman
wrote:
> So I was just wondering if ~arch is ready for more secure defaults on
> the 17.0 profiles in the linker flags. There are several
> distributions which ship RELRO by default and I am not aware of any
> performance issues
> [[ ${ret} == true ]]
>
> Would be the canonical bash way.
Updated.
From: Arfrever Frehtes Taifersar Arahesis
Newly added tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong()
and tc-enables-ssp-all() check macros instead of specs.
This solution also works with older GCC and with Clang.
Signed-off-by: Matthias Maier
---
eclass/toolchain-funcs.eclass
OK.
This is a slightly modified version that uses string comparison to form the
result.
Best,
Matthias
>> +# @FUNCTION: tc-enables-pie
>> +# @RETURN: Truth if the current compiler generates position-independent
>> code (PIC) which can be linked into executables
>> +# @DESCRIPTION:
>> +# Return truth if the current compiler generates position-independent code
>> (PIC)
>> +# which can be linked into
On Wed, Jun 14, 2017, at 18:15 CDT, Matthias Maier wrote:
> [...]
and of course, many thanks to Arfrever for patches and his kind support!
Best,
Matthias
signature.asc
Description: PGP signature
Hello all,
this is a series of patches against the toolchian-funcs and toolchain-glibc
eclasses, most notably
- introducing new tc-enables-pie(), tc-enables-ssp(),
tc-enables-ssp-strong() and tc-enables-ssp-all() functions in
toolchain-funcs compatible with gcc >=6 and clang as a replaceme
From: Arfrever Frehtes Taifersar Arahesis
configure accepts --enable-stack-protector=... option which results
in build system passing appropriate -fstack-protector... option
when possible.
Signed-off-by: Matthias Maier
---
eclass/toolchain-glibc.eclass | 17 ++---
sys-libs
For gcc-6 and newer the old logic in the toolchain-glibc eclass:
if use hardened && gcc-specs-pie ; then
append-cppflags -DPIC
else
filter-flags -fPIE
fi
is obsolete. Simply disable the check.
---
eclass/toolchain-glibc.eclass | 24 +++-
1 file changed, 15 inser
From: Arfrever Frehtes Taifersar Arahesis
Newly added tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong()
and tc-enables-ssp-all() check macros instead of specs.
This solution also works with older GCC and with Clang.
Signed-off-by: Matthias Maier
---
eclass/toolchain-funcs.eclass
---
eclass/toolchain-glibc.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index 5be31eb193..270c9cdac7 100644
--- a/eclass/toolchain-glibc.eclass
+++ b/eclass/toolchain-glibc.eclass
@@ -266,7 +266,7 @@ se
From: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Matthias Maier
---
eclass/toolchain-glibc.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index eba829cd2f..5be31eb193 100644
--- a/eclass/toolchain
On Sun, Jun 11, 2017, at 13:39 CDT, "Walter Dnes" wrote:
> 1) Should I be doing bug reports on the Gentoo bugzilla or upstream?
Please check [1] and if not already reported open a bug report blocking
[1] on our bugzilla.
Best,
Matthias
[1] https://bugs.gentoo.org/show_bug.cgi?id=gcc-6
On Wed, Jun 7, 2017, at 15:44 CDT, "Andreas K. Huettel"
wrote:
> [...]
> Obviously we're now in the test phase and the official switchover
> recommendation
> can only happen after gcc-6 is stable. This is also why I'm not touching
> profiles.desc yet.
>
> Patches following for review (only
# Matthias Maier (06 Jun 2017)
# Dead upstream, unmaintained, no homepage, no SRC_URI, x86-only, does not
# compile, bug #620964. Removal in 30 days.
app-text/7plus
On Fri, May 26, 2017, at 13:07 CDT, Alexis Ballier wrote:
> On Sat, 20 May 2017 19:38:01 +0200
> "Andreas K. Huettel" wrote:
>> - Globally setting -std=c++14 in upcoming 17.0 profiles
>
> A bit late to the party, but what was the outcome of the meeting, esp.
> this part ?
>
> I'm not sure if d
> Were this an actual office, this would be better solved with a "ok,
> we've clearly been working too hard this week, everyone stop, ITS PUB
> O-CLOCK!"
This is most definitely true for almost everything going on for the last
days in Gentoo.
signature.asc
Description: PGP signature
On Wed, May 17, 2017, at 22:53 CDT, Alon Bar-Lev wrote:
> On 18 May 2017 at 06:46, Matthias Maier wrote:
>> [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set
>> EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the
>> cross
Hi there,
On Wed, May 17, 2017, at 17:25 CDT, Marty Plummer wrote:
> Greetings,
>
> So, I'm a relatively new gentoo user (as of 2016-12) coming from arch,
> and one thing I've noticed is the relative difficulty of setting up a
> mingw-w64 cross-compile toolchain and libraries.
>
> I'm consideri
Hi all,
I will post an RFC for a profile update (and a news item) for 17.0
shortly with the following change:
- unmask pie use flag for sys-devel/gcc
- unconditionally force pie and ssp use flag for sys-devel/gcc
Any additional profile changes for our
default/linux/*/13.0
that shall be
> Has anyone checked 32-bit systems? "emerge -pv =sys-devel/gcc-6.3.0"
> on a 2008 Core2duo 32-bit install (my GCC 6.3.0 testbed) shows "(-pie)".
> I read that as the "pie" USE flag being hard-masked out. On my 64-bit
> desktop, "pie" is the default.
Yes, we are aware of this. Unfortunately, d
Hello all,
In light of the recent discussion, I will restore the status quo for the
pie use-flag: masked on non-hardened profiles, unmasked and forced on
hardened profiles.
The next step will be to switch the pie use-flag on default profiles from
masked to unmasked/forced with a profile update.
s/base/package.use.mask
+++ b/profiles/base/package.use.mask
@@ -7,6 +7,10 @@
# This file is only for generic masks. For arch-specific masks (i.e.
# mask everywhere, unmask on arch/*) use arch/base.
+# Matthias Maier (11 May 2017)
+# Globally mask pie use flag. Selectively unmask on specific profiles
On Thu, May 11, 2017, at 10:57 CDT, "Jason A. Donenfeld"
wrote:
> Does anybody have any objections to me doing this? (I'll wait a week
> from now before taking any actions.)
There is a clear and easy upgrade path to rxvt-unicode, so please mask
right away.
Best,
Matthias
On Wed, May 10, 2017, at 10:32 CDT, Hanno Böck wrote:
> Can't we just provide a small script or bash oneliner that will rebuild
> all affected packages?
See mail e-mail with the updated news item.
"[RFC] News item: GCC 6 defaults to USE="pie ssp", v2"
Best,
Matthias
> -> This would also give us some time to discuss what other changes we might
> make with the transition to the new profiles.
>
> -> Also, this means the transition is independent of gcc release timing.
>
> (We just need to be careful since hardened also inherits 13.0, so the setting
> must be o
On Wed, May 10, 2017, at 02:28 CDT, Martin Vaeth wrote:
> I am using gcc-6 since ages and tried to run a desktop with default pie
> for quite a while, but soon was forced to give up:
> [...]
I have pie enabled on a desktop for years. Almost all major linux
distribution have pie enabled as well
On Wed, May 10, 2017, at 00:07 CDT, Jason Zaman wrote:
> I just want to make sure im understanding this right, only .a files that
> were compiled without -pie will cause issues if you compile the later
> thing that uses the .a with -pie?
> So:
> 1) people on hardened profiles are going to be fin
This is a reworded news item (assuming we proceed with the plan to
default-enable USE=pie). Suggestions for improving the emerge command to
fix static archives is highly welcomed.
Matthias
Title: GCC 6 defaults to USE="pie ssp"
Author: Matthias Maier
Content-Type: text/plain
Poste
> For a transition we can probably build everything with -fPIE but not
> link with -pie. If we want that to happen fast, gcc-6 might do that and
> gcc-7 add the -pie option.
I am not entirely convinced that a transition period of one gcc version
is enough for a smooth transition [1].
It might be
s/base/package.use.mask
@@ -7,6 +7,10 @@
# This file is only for generic masks. For arch-specific masks (i.e.
# mask everywhere, unmask on arch/*) use arch/base.
+# Matthias Maier (09 May 2017)
+# Mask pie useflag globally and unmask + use.force on hardened profiles.
+sys-devel/gcc pie
+
# Mike Gilbert (
On Tue, May 9, 2017, at 15:10 CDT, Alexis Ballier wrote:
> There is a *huge* difference between:
> Disable PIE support (NOT FOR GENERAL USE)
> and the negation of:
> pie - Build programs as Position Independent Executables (a security
> hardening technique)
>
> Enabling the latter builds *ev
Title: GCC 6 defaults to USE="pie ssp"
Author: Matthias Maier
Content-Type: text/plain
Posted: 2017-05-07
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: >=sys-devel/gcc-6.3.0
Display-If-Keyword: amd64
In Gentoo, several GCC features can be default disabled or enabled
via
sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal
copy got removed [1].
[1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=242985
---
eclass/toolchain.eclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
ind
> After the discussion on this thread (no one seemed to object), I went
> ahead just now and added ~ keywords to sys-devel/gcc-6.3.0.
Thanks a lot!
Did you update any keywording bug (if one is open at all)?
Best,
Matthias
signature.asc
Description: PGP signature
> Just as a datapoint, my main dev system is ~80% stable and has been updating
> with gcc-6 since beginning of february; no problems. [*] [**]
Same here. The gcc-6 incompatibilities were resolved quite a while
ago. Let's keyword gcc-6 and try to get gcc-7 into the tree on time.
Best,
Matthias
On Thu, Apr 20, 2017, at 17:17 CDT, "Walter Dnes" wrote:
> ...fun !NOT. If you're doing a fresh install, ***WITH A GCC5-BUILT
> INSTALL CD AND STAGE 3***, then yes, go for it. But changing horses in
> mid-stream can be painfull. Would it hurt to stay with 4.9.4 for the
> time being, assuming
> manifest-hashes = SHA512 SHA3-512 WHIRLPOOL
>
> Your thoughts?
I just want to point out that according to GLEP 63 we only require pgp
signatures with at least sha-256 [1]. Further, our PGP signatures by the
release team are as well either SHA-256/SHA-512.
So using SHA3-512 (or whirlpool for t
> The kernel doesn't give you a choice of multiple independent patch
> sets. We have just a few options that bundle many patches. You can't
> selectively turn them on and off.
>
> I'm not asking whether patching bitcoin is good or bad.
>
> I'm pointing out that if you want to do the same thing w
On Tue, Mar 7, 2017, at 10:52 CST, Rich Freeman wrote:
>> As a Bitcoin user I personally don't feel too happy with my experience
>> changing without me changing USE-flags. I'm not against changing the name of
>> the USE-flag, just against changing the default behavior and applying a
>> bunch of
On Wed, Mar 1, 2017, at 13:43 CST, Fabian Groffen wrote:
> Hi,
>
> I'd like to push out attached news item ASAP. Please review.
Looks good. Has a clear and precise structure.
> Title: =mail-mta/exim-4.88 problem with chunking
> Author: Fabian Groffen
> Content-Type: text/plain
> Posted: 20
> Nice .. esp. coming from a QA dev ...
This is an absolutely inappropriate response.
Especially from a Mentee and prospective new Developer.
Matthias
signature.asc
Description: PGP signature
# Matthias Maier (31 Jan 2017)
# Dead upstream (no development since 2010) [1,2], outstanding security
# issue with newer encfs versions [3], oustanding Gentoo bugs [4,5].
# Mask for removal in 30 days.
# [1] https://github.com/tomm/cryptkeeper/commits/master
# [2] https://github.com/tomm
> well then 'ihateudev' masking udev, 'ihateeudev' masking eudev and
> 'ihatesystemd' masking systemd; what are the blockers here?
You make three profiles, 'udev', 'eudev', 'systemd' and put them in one
group and let them block said group.
On Mon, Jan 23, 2017, at 13:30 CST, Alexis Ballier wrote:
> still that doesn't account for a 'ihatelennart' mixin masking udev &
> systemd and a 'ilovelennart' mixin masking udev & eudev and an user
> enabling them both
But that's exactly what is ruled out by the "blocks @group" mechanism in
mg
On Tue, Dec 6, 2016, at 20:37 CST, james wrote:
> So do I need to apply again, or an I on the list? I went (nomail)
> cause at the time reading via gmane.org was working. Perhaps I should
> just change the status to receive the mails? I can test post, if
> that is helpful?
No, the list is si
On Tue, Nov 1, 2016, at 11:52 CDT, William Hubbs wrote:
> requirement for udev to "settle" before it's startup completes. The
^~~~
its
Best,
Matthias
signature.asc
Description: PGP signature
> So, it is probably simpler to avoid controversy by just incorporating
> it by reference under their original name, which is certainly the
> intention of the Linux Foundation in promoting it.
+1
:-)
signature.asc
Description: PGP signature
On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman wrote:
> I'd think that the title of a legal document falls more under
> trademark law than copyright law. That is why the FSF publishes the
> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
> LICENSE." The former has far more trad
> Therefore, we may indeed consider taking the DCO from the Linux source
> tree which is distributed under the GPL-2
I highly doubt that the DCO in the readme is licensed under GPL-2. There
is no readme/header, or other indicator stating this. Not everything in
the linux repository falls under GPL
> please make also clear that UUID=... syntax will still work, one for all I
> don't like labels and will gladly continu to use this format:
> UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime 1 2
+1
Slightly revising the example given later on by simply showing one
example fo
> Well, depending on how this is done the main harm is in administrative
> overhead, unless this is automated, or we use a simplistic approach of
> just continuing to append names.
The pragmatic approach would be to remove the policy and associated
repoman warning and allow contributors to use an
> I think you could make an argument that voluntarily placing that
> header on your work is an assignment of copyright.
I very much doubt that.
> Personally I'd rather move to an explicit system.
Yes!
And I see absolutely no harm in explicitly annotating the actual
copyright in gentoo ebuilds
On Mon, Oct 3, 2016, at 16:59 CDT, William Hubbs wrote:
> All,
>
> I want to look into removing grub:0 from the tree; here are my thoughts
> on why it should go.
>
> - the handbook doesn't document grub:0; we officially only support
> grub:2.
>
> - Removing grub:0 from the tree doesn't stop y
On Sun, Sep 25, 2016, at 16:08 CDT, Michał Górny wrote:
> Hi,
>
> I'd like to introduce a new USE_EXPAND for LLVM & clang. It'd be named
> LLVM_TARGETS, and it's going to replace the current solution based on
> USE=multitarget & VIDEO_CARDS=radeon.
>
> In the old system, the following rules appl
On Tue, Aug 16, 2016, at 18:49 CDT, Matthias Maier wrote:
> On Tue, Aug 16, 2016, at 18:20 CDT, William Hubbs wrote:
>
>> All,
>>
>> I have received a request to implement a feature in OpenRC to allow
>> multiple software packages to drop files in a directory,
On Tue, Aug 16, 2016, at 18:20 CDT, William Hubbs wrote:
> All,
>
> I have received a request to implement a feature in OpenRC to allow
> multiple software packages to drop files in a directory, /etc/modules.d
> for example, which would define modules the /etc/init.d/modules script
> would load.
# Matthias Maier (3 Aug 2016)
# Masked for removal in 30 days. Obsolete packages that are now part of
# sci-libs/libqalculate and/or sci-calculators/qalculate-gtk
sci-calculators/qalculate-bases
sci-calculators/qalculate-currency
sci-calculators/qalculate-units
signature.asc
Description: PGP
> 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
# 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
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
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
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
1 - 100 of 137 matches
Mail list logo
