> 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
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
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
> 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
> 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
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
> 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
> 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
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
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
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
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 (
> 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
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
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
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
> -> 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 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
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
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
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.
> 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
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
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
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
> 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 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
# 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 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
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
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
---
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
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
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
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
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
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
>> +# @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
OK.
This is a slightly modified version that uses string comparison to form the
result.
Best,
Matthias
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
> [[ ${ret} == true ]]
>
> Would be the canonical bash way.
Updated.
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
> 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
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
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/
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 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
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 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 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 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
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, Mar 23, 2018, at 08:48 CDT, Michal Privoznik
wrote:
> [...]
Applied. Thanks!
Matthias
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 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
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
# 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
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.
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 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 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
> 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
> 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
> 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
> 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
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
> 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 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
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 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
> 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.
# 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
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
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
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 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 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 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
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
Am 05. Oct 2014, 15:20 schrieb Diego Elio Pettenò :
> Simple as this: -pam is not by default tested and you keep the pieces if it
> breaks.
Upstream bug is at [1]. According to comment 1 also upstream does not
seem to test non-pam use cases all that often.
I have the impression that all this fu
> Not sure if the llvm C++ runtime might help here or it is any better
> than the one provided by gnu, but might be a good time to gather
> volunteers to provide a mean to use clang as main compiler out of box.
libc++ makes stricter ABI guarantees [1]. But from personal experience I
would not con
>
> Could you please blog or add some notes to the wiki about it?
>
I've put up a preliminary version for the toolchain part:
https://gist.github.com/tamiko/7e3a0be806fac11f2a35
Best,
Matthias
Am 27. Oct 2014, 11:14 schrieb Alexis Ballier :
> By the way, any help for maintaining the libc++ stack is very welcome;
> as you can see from the age of the current snapshots, it's been some
> time I've not been playing with it.
>
>
> Some notes:
> - why not adding a clang subprofile ? there's o
Am 27. Oct 2014, 12:07 schrieb "M. Ziebell" :
> Does clang compile glibc already?
> At the last GNU Cauldron the speaker said that clang fails because
> of:[1]
> - nested functions
> - VLAIS
>
> How did you avoid that problem?
Even without this issues there remains the fact that glibc is quite
c
> - libcxxabi is probably the new way to go instead of libcxxrt; last
> time I checked there was a chicken and egg problem: libcxxabi needed
> clang + libc++ to build, so bootstrapping the stack was a bit
> painful.
I give libcxxabi a try.
Does anybody has a bit insight in the current stat
Am 03. Nov 2014, 00:24 schrieb Andrés Martinelli :
> I am working on a terminal spreadsheet based on "sc", but with some
> adds like undo/redo..
> you can find it here:
>
> https://github.com/andmarti1424/scim
>
> Any new ideas and/or contribution is always welcome!
Just out of curiosity.
The o
# Matthias Maier (4 Nov 2014)
# Masked for removal in 30 days. The package has multiple open bugs
# (bug #482472, bug #501818, bug #528190) and is superseded by
# app-emulation/virt-manager[-gtk]
app-emulation/virtinst
Am 07. Nov 2014, 19:30 schrieb Ciaran McCreesh :
> On Fri, 07 Nov 2014 19:11:04 +0100
> Jauhien Piatlicki wrote:
>> Then the same question for you: where can one read about the algorithm
>> Paludis uses?
>
> It's basically a two stage process: simple constraint solving using
> value ordering heur
Am 07. Nov 2014, 20:21 schrieb Ciaran McCreesh :
> On Fri, 07 Nov 2014 19:54:08 +0100
> Matthias Maier wrote:
>> Currently, for portage just to decide that nothing has to be done on
>> my machine takes around 1 minute.
>
> Are you running with or without metadata
I've commited a live ebuild for libvirt-python to CVS. Given the fact
that we already have one for libvirt and one for virt-manager, this
makes sense.
Best,
Matthias
*libvirt-python- (08 Nov 2014)
08 Nov 2014; Matthias Maier +libvirt-python-.ebuild:
provide live ebui
Am 11. Nov 2014, 15:59 schrieb Pavlos Ratis :
> * dev-vcs/mr
I can take care of this one - I use dev-vcs/mr quite heavily.
Best,
Matthias
> * dev-vcs/mr
> * dev-vcs/vcsh
On second thought, I think, I'll adapt both of them. :-)
Best,
Matthias
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 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 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
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
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 -
>
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 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
> 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?
1 - 100 of 137 matches
Mail list logo
