Re: [gentoo-dev] Typo: 2024-02-01-grub-upgrades: add news item

2024-02-05 Thread Nils Freydank
Am Montag, den 05.02.2024 um 23:44:10 Uhr + schrieb Sam James 
:
> [...]
> > +However, this will clobber any BOOTX64.EFI image provded by other
> > +loaders. If dual-booting using another boot loader, users must take care
> > +not to replace BOOTX64.EFI if it is not provided by GRUB.
Hi, I think you meant "provided" here (missing "i").

Looks lgtm otherwise.

> [...]


signature.asc
Description: PGP signature


[gentoo-dev] NetworkManager support by p.m.?

2022-11-13 Thread Nils Freydank
> (In the same vein I wouldn't mind someone taking over NetworkManager...)

Hi Matt,

would it help you if I'd co-maintain NM itself as proxied maintainer?

Best regards,
Nils


signature.asc
Description: PGP signature


Re: [gentoo-dev] Package up for grabs: app-misc/pdfpc

2021-12-19 Thread Nils Freydank
Am Mittwoch, den 15.12.2021 um 20:23:57 Uhr +0100 schrieb Ulrich Mueller 
:
> [...]
> 
> I am actively using this. So, I'll take it unless someone else wants to
> maintain it. (Co-maintainers are also welcome.)
> 
> Ulrich

Great, thanks for taking it!

Nils


signature.asc
Description: PGP signature


[gentoo-dev] Package up for grabs: app-misc/pdfpc

2021-12-15 Thread Nils Freydank
Hi everyone,

pdfpc is a nice presentation tool to show PDFs and a presenter screen with
notes etc[1].

With version 4.5.0 upstream startet to use webkit-gtk and has no intention
to make this optional[2]. I use a Qt-based desktop, have no interest to build
another browser engine for a single tool and didn't use pdfpc in over a year
(only tested it to verify that it's still working). Therefor I step down as
it's proxied maintainer.

The only open bug right now is a stabilization request[3]. Releases are not
often (in the order of one or two per year).

[1] https://packages.gentoo.org/packages/app-misc/pdfpc
[2] https://github.com/pdfpc/pdfpc/issues/62
[3] https://bugs.gentoo.org/828333

Kind regards,
Nils


signature.asc
Description: PGP signature


[gentoo-dev] Package up for grabs: app-editors/retext (and dev-python/markups)

2021-07-18 Thread Nils Freydank
Hi all,

I'm stepping down as the proxied maintainer of the graphical markdown editor
app-editors/retext and it's dependency dev-python/markups because I didn't use
it in a long period and have not enough time to test it thoroughly.

Upstream releases are infrequent and retext has no open bugs and is stable.
Future maintainers could e.g. support the python project with bumping markups
and its deps and clean up the old retext stable version 7.1.0, keeping 7.2.1
(I was often not fast enough - kudos mgorny for speed-bumping without
breackage!).

Corresponding PR on github.com: https://github.com/gentoo/gentoo/pull/21701

Kind regards
Nils


signature.asc
Description: PGP signature


Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

2021-03-20 Thread Nils Freydank
Hi Andreas,

Am Samstag, den 20.03.2021 um 16:37:23 Uhr +0100 schrieb "Andreas K. Huettel" 
:
> [...]
> Does anyone remember the reason for 1) ? Or is that lost in history?

I just quote comment 3 from the linked bug https://bugs.gentoo.org/737914#c3:
"copying the zonefile to /etc/localtime is a good idea, as /usr could be on a 
separate partition. How about creating the

/etc/TZ -> /etc/timezone softlink by default?"

In my opinion so many tools tend to expect an always-mounted /usr that the
symlink would not do any harm. FWIW I use symlinks on a handfull Gentoo machines
and had no issues in years, but I'm pretty close to mainstream (amd64, glibc,
OpenRC).

Best regards,
Nils


signature.asc
Description: PGP signature


Re: [gentoo-dev] Improving warnings on packages.g.o

2020-08-27 Thread Nils Freydank
Hi,

thanks for the work around p.g.o! I'd directly like to use your opt out for a
package I maintain in proxied mode:

The following changes since commit b1e0b4c9ec76049631cbb0a2d3798adbce2075ac:

  Ignore net-misc/dropbox::void_x86_64 for repology (2020-08-26 19:14:45 +0200)

are available in the Git repository at:

  https://git.holgersson.xyz/gentoo-related/soko-metadata ignore-mktorrent

for you to fetch changes up to dd823eaaf3f4893b24130360c7ec1c7f22f8b39b:

  Ignore net-p2p/mktorrent for repology (2020-08-27 11:45:34 +0200)


Nils Freydank (1):
  Ignore net-p2p/mktorrent for repology

 repology/ignored-packages | 1 +
 1 file changed, 1 insertion(+)

--
regards,
Nils


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2020-08-15 Thread Nils Freydank
Hi Christopher,

Am Mittwoch, den 27.05.2020 um 09:37:59 Uhr -0700 schrieb Christopher Head 
:
> ...
> I already had a PR[1] open for the version bump and Python 3.7 support.
> I’m happy for you to take over if you like; mine is waiting for review.
> Just thought you ought to know in case you get merge conflicts later
> on, or want to take any bits of my changes.
> 
> [1] https://github.com/gentoo/gentoo/pull/15783

sorry for the delay - I really like to take over, and as your PR isn't merged
yet I opened a new one[1] with some further updates (vobject with python 3.9).

Please just close your old PR now.

[1] https://github.com/gentoo/gentoo/pull/15783


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2020-05-27 Thread Nils Freydank
Hi,

I can add my already bumped app-misc/khard and start to co-maintain it via
p.m. project.

Am Mittwoch, den 27.05.2020 um 06:00:18 Uhr +0200 schrieb Zoltan Puskas 
:
> [...]
> I'm happy to take dev-python/ruamel-yaml and dev-python/ruamel-yaml-clib 
> either
> as a solo or as a comaintainer. I'll put up a PR later adding myself to the
> metadata as a proxy maintainer. Feel free to keep or remove yourself
> after that.

Zoltan, I prepared a branch with khard plus metadata.xml and would like to ask
you to merge it into your PR as you took deps of khard:

https://github.com/holgersson32644/gentoo/tree/bump-khard

regards,
Nils


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation

2020-05-05 Thread Nils Freydank
Hi all,

I find the idea of having data great, but agree that it can lead to a false
sense of having a correct data base. Therefor two thoughts:

First, therefore I'd like to propose that you introduce gentoostats as a
*strictly timed experiment* and evaluate if it actually changed anything within
your decisions and drop it or let run permanently afterwards.

I have no proper solution for the parameters though, maybe something like
"I choose to keep X use flags based on g.s.", but this would ask every dev to
log plenty of decisions manually (read: I don't think this will happen).

Second, I'm a bit frightened of Whissi's thought of dropping anything
security related based on non-input via g.s. -- I'd like to ask you to use the
information based on g.s. *not* for security related decisions, more for
"harmless" ones like the Matt mentioned: Should I really support feature X while
literally everyone of 200 users uses feature Y instead and I have no real
testing ground for feature X (Matt, yell at me if I got you wrong!).

Kind regards,
Nils (holgersson on Freenode)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last rites: media-video/syncplay

2020-03-25 Thread Nils Freydank
Am Mittwoch, 25. März 2020, 08:38:47 CET schrieb Michał Górny:
> # Michał Górny  (2020-03-25)
> # Unmaintained.  Python 3 support requires a version bump.  Bad quality
> # ebuild.
> # Removal in 30 days.  Bug #710240.
> media-video/syncplay

There is a pending PR on github.com:
https://github.com/gentoo/gentoo/pull/15077

--
PGP fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
keybase.io/nfreydank

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages

2019-08-31 Thread Nils Freydank
Hi,

most of my points were just said. Two additional notes:

- dev-embedded/jtag says upstream is dead anyway and it
recommends an alternative we have inside our tree,
dev-embedded/urjtag.

- games-strategy/netpanzer got a rewrite called
  version 2.something, which looks active/used.

Please reflect these in the masking message(s).


However, thanks for the housekeeping!

Kind regards,
Nils

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson





Re: [gentoo-dev] rfc: moving default location of portage tree

2018-07-12 Thread Nils Freydank
Am Mittwoch, 11. Juli 2018, 18:19:39 CEST schrieb Alec Warner:
> [...]
> 
> +1 to this. The challenge (in moving it) is that its been "/usr/portage"
> for a long time so many tools
> may have hard coded this location; as opposed to querying portage for where
> the tree is, e.g.:
> 
> PORTDIR=$(portageq get_repo_path / gentoo)
> 
> -A
Some people including myself moved the tree to /var by variable definitions 
(and not wild mounting) a while ago. This configuration *is* supported for a 
while now but not the default and if tools break they have to be fixed anyway. 

(Side note: At least most of the common tools like gentoolkit parts or repoman 
work on my machines with the moved tree.)

- Nils

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] rfc: killing mediawiki

2018-07-05 Thread Nils Freydank
Am Dienstag, 3. Juli 2018, 19:39:43 CEST schrieb William Hubbs:
> All,
> 
> some of us have talked about this on IRC off and on, but I want to bring
> it up here as well.
> 
> I don't care that we have a wiki, but can we please look into killing
> mediawiki and look at something with a git backend?
What about https://github.com/Git-Mediawiki/Git-Mediawiki?
"Gate between Git and Mediawiki" sounds as it would be the right extension
while mediawiki can be kept.

Best Regards
Nils Freydank

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Package up for grabs: sys-apps/pacman

2018-07-04 Thread Nils Freydank
Dear all,

sys-apps/pacman[1] is up for grabs after my retirement
as the proxied maintainer for it.

There are open bugs[2], but I would consider the package
in a relatively good shape. Some people seem to be already
interested in proxied maintenance - please coordinate with them.

For details take a look at the latest bump bug[3].

Best regards,
Nils Freydank

Links:

[1] https://packages.gentoo.org/packages/sys-apps/pacman
[2] 
https://bugs.gentoo.org/buglist.cgi?quicksearch=sys-apps%2Fpacman_id=3981994
[3] https://bugs.gentoo.org/659474#c1

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [News item review] Portage rsync tree verification (v3)

2018-01-27 Thread Nils Freydank
Am Samstag, 27. Januar 2018, 15:26:44 CET schrieb Michał Górny:
> [...]
> 
> The new verification is intended for users who syncing via rsync.
> Verification mechanisms for other methods of sync will be provided
> in future.
s/who syncing/who are syncing/

("who sync via rsync" would sound a bit odd, but should work aswell.)

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


OT: Re: [gentoo-dev] [PATCH 1/1] profiles: drop USE=cracklib from base/make.defaults.

2017-12-27 Thread Nils Freydank
Am Mittwoch, 27. Dezember 2017, 22:33:03 CET schrieb R0b0t1:
> On Wed, Dec 27, 2017 at 10:32 AM, William Hubbs <willi...@gentoo.org> wrote:
> > As he said, he contactedd the maintainers in ample time, so I would say
> > that since they didn't respond he went ahead in good faith. I'll get the
> > link later, but as I recall, the dev manual recommends a 2-4 week wait
> > for maintainers not responding then we can assume that what we are doing
> > is ok.
> 
> This assumes there is some pressing need for the change to take place,
> which I am not sure there is. I can understand wanting to make the
> change for consistency's sake, but the feature is important enough
> that I think a suitable replacement should explicitly be found before
> continuing. E.g. affirmative feedback from all affected packages.

Often a fix timeline is the only way to achieve any responses - or at least
get stuff done, even if the matter itself is not urgent at all. In this 
specific case the points Michael had were quite clear, and the timespan of
two month was long enough to react somehow (at least in the context of typical
periods in Gentoo, e.g. last rite/removal period of 30 days).

On topic: There are some users including myself that find cracklib mostly 
annoying. I use strong passwords (or ssh keys only) where I can, and cracklib 
annoys me with the request to set "secure passwords" for a container 
playground, where I want root:test as login credentials.
Beside that the point that profiles in general should contain as least USE as 
possible (see the bug report for that).

> Enforcement of rules or Gentoo development guidelines does not happen
> consistently, and the times when rules are enforced "for consistency's
> sake" seem completely arbitrary. There seems to be no extant problems
> caused by the flag as set, so why focus on this specifically?

To me these times look as they're based upon agreement between the involved 
parties, and in itself consistently, e.g. at least 30 days masking before
removal out of the tree, or in this case at least two to four weeks to let 
others respond.

> There is a lot of discussion of not burdening developers with
> pointless talk or changes. If that is a goal, then why is this posting
> receiving so many replies?

With all due respect, your posting didn't bring any new relevant aspects into 
this thread on this mailing list with the explicit focus and topic of Gentoo 
development, and might be exactly part of the "pointless talk" you mention.

My one isn't better; I just want to point that out to you, because you tend to
write messages with this kind of meta questions about the cause of things.

If you want to discuss this, I'd prefer another place than this list.

Regards,
Nils

-- 
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread Nils Freydank
Am Mittwoch, 20. Dezember 2017, 17:48:54 CET schrieb kuzetsa:
> On 12/16/2017 10:14 AM, Nils Freydank wrote:
> > Am Dienstag, 5. Dezember 2017, 23:41:45 CET schrieb kuzetsa:
> >> On 12/05/2017 05:18 PM, Nils Freydank wrote:
> >>> 5. Reasons for warnings and bans
> >>> 
> >> 
> >> --snip--
> >>  --- other snip ---
> > 
> > Could you write a short paragraph for this?
> 
> Haven't been paying much attention to this thread.
> (I was quoted here - Point #c versus #d)
> 
> Am I being asked to write something up?
Yes, exactly that is what I’m asking for. I think your point c vs. d statement 
was that good it might be best if you’d write two or three sentences.

I’m not sure if the whole moderation approach will be followed anyway, but 
IMHO we should still give it a try.

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread Nils Freydank
Am Dienstag, 5. Dezember 2017, 23:41:45 CET schrieb kuzetsa:
> On 12/05/2017 05:18 PM, Nils Freydank wrote:
> > 5. Reasons for warnings and bans
> > 
> 
> --snip--
> 
> > c) spamming, i.e. flooding discussions with lots of messages in a row
> > d) constant postings off topic, i.e. disrupting discussions with unrelated
> > questions
> > 
> > (constant means more than two times in a row)
> 
> Point #c versus #d
> 
> #c - there can (and often are) good faith reasons for
> multiple postings "in a row", such as when responding
> to multiple threads, and/or to multiple posters within
> the same thread. Even just people who are awake (and
> would respond) at a time when other participants in the
> list would be sleeping could complicate this rule.
Valid point.

> #d - definition for constant seems unnecessary. For an
> alternative, maybe refine the definition to either
> use a 72 hour window or similar, or even just a basic
> expectation for discussion to be germane (on-topic)
> with refusal to stay on-topic (when warned) being the
> measure. Perhaps three strikes (per day?) are when
> the enforcement could start. parliament / congress
> and other formal assemblies have models for this.
Sounds good to me. As spamming is *always* off topic
this should even catch point c).

Could you write a short paragraph for this?

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-20 Thread Nils Freydank
Am Freitag, 15. Dezember 2017, 23:37:48 CET schrieb R0b0t1:
> Hello,
> 
> On Tue, Dec 5, 2017 at 4:18 PM, Nils Freydank <holgers...@posteo.de> wrote:
> > Hello everyone,
> > 
> > with regards to the current mailing list (ML) split discussion, and one
> > specific message deep down there by mgorny asked for someone providing
> > moderator rules, I would like to propose the following ruleset for
> > gentoo-dev
> > 
> > Right now the situation escalated in a way that forces to actually do
> > something and I hope we can recreate an atmosphere where technical
> > improvements can happen.
> 
> To me, at least, this isn't self-evident. What specific actions make
> you think an immediate response is necessary?
> 
> self-evident
>   adj. Evident to one’s self and to nobody else.
> 
> Cheers,
>  R0b0t1
There is a specific RFC about splitting the mailing list because of a 
problematic style of conversation.

Even if that split won’t happen -- I don’t know if mgorny has the "right" or 
support to do that and I personally want to stay out of these discussions -- I 
really *do* think that a moderation of a frequented mailing list like gentoo-
dev is a generally good idea. Therefore we need properly documented rules 
(beside moderators).

To answer you question: I think the RFC introduces either a "time pressure" or
should be seen as sign that this list needs an improvement.

Regards,
Nils

--
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [RFC] Moderator ruleset for gentoo-dev@lists.gentoo.org

2017-12-05 Thread Nils Freydank
Hello everyone,

with regards to the current mailing list (ML) split discussion, and one 
specific message deep down there by mgorny asked for someone providing 
moderator rules, I would like to propose the following ruleset for gentoo-dev 

Right now the situation escalated in a way that forces to actually do 
something and I hope we can recreate an atmosphere where technical 
improvements can happen.

I suggest using a very specific ruleset to give a proper guide to future
moderators and users of the ML in addition to our *existing* Code of 
Conduct[1].

As my personal experience showed me it might be good to add a good alternative
to every expelled bad one, so I added them.

As this is a RFC I’d welcome any discussion about that document.

Proposal


1. Idea and topic of the mailing list

The gentoo-dev mailing follows the main idea of discussing topics that are
part of the development of Gentoo itself. This limits to technical aspects
like eclass improvements, or GLEP development.

Off topic discussions or general user support are not part of this mailing
list and should be held on other, appropriate lists.

2. People or groups allowed to write to gentoo-dev ML
-
Everybody who has the intention to contribute to the discussions according
to the mailing list’s topic has the right to do that after a subscription.

This explicitly excludes off topic discussions, flaming, trolling and verbal
attacks against other people or groups (which are defined under point 5).

On gentoo-dev it also excludes bug reports or support questions. Bug reports
can be filed in the bug tracker, support related questions can be asked on 
other mailing lists, in IRC channels or in the Gentoo related forums.

3. Moderation
-
The moderation team has to consist of at least two developers. The moderators
have to do join the moderation team voluntarily.

Moderators are held to warn authors on the list if they ignore the rules of
this list and ban them for a limited time if they repeat the behaviour that
led to warnings in the first place.

4. Procedure of banning and ban times
-
As banning is a severe interaction it has to be strictly regulated.
When moderators perceive someone ignoring the rules, they have to go
through the following steps:

a) Warn the respective person once pointing out the exact rule
   that was violated.

If the violation continues, moderators have to
b) ban the user for 24h noting this in a direct response the violation.
   That way the violation, ban time and reason are documented.

Every third 24h ban results into
c) a 7 day ban with the same regularities as a 24 hour ban.

d) Every ban has to be notified to ComRel (com...@gentoo.org).

5. Reasons for warnings and bans

The rationale for the whole moderation is to keep the list productive. To
achieve this, some specific actions have to be sanctioned:
a) trolling, i.e. provocation of aggressive reactions
b) attacks, e.g. insulting people or groups
(which does not include proper articulated disagreement)
c) spamming, i.e. flooding discussions with lots of messages in a row
d) constant postings off topic, i.e. disrupting discussions with unrelated 
questions
(constant means more than two times in a row)


6. Preservation of transparency & discussions
-
Maybe the most important aspect for moderation is transparency. To achieve it
the ban is
a) strictly regulated with regards to possible reasons
b) strictly timed,
c) logged via the mailing list archives.

If a warned or banned person thinks the action taken wasn’t correct, this 
issue
might addressed with the moderator in a private discussion first. If there is 
no
conclusion found, the discussion should take place with ComRel as a mediation 
party.

[1] https://wiki.gentoo.org/wiki/Project:Council/Code_of_conduct

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


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

2017-12-05 Thread Nils Freydank
Am Montag, 4. Dezember 2017, 18:02:21 CET schrieb Michał Górny:
> W dniu pon, 04.12.2017 o godzinie 14∶18 +0100, użytkownik Dirkjan
> 
> Ochtman napisał:
> > On Sun, Dec 3, 2017 at 10:43 PM, Michał Górny  wrote:
> [...]
> 
> I'm all for it, as long as someone is actually going to do the necessary
> work within the next, say, 4 weeks. I'd really like to avoid once again
> having no resolution whatsoever just to wait for never-to-come upgrade.
> 
> I should point out that this includes:
> [...]
> 2. Establishing a clear policy on how moderation should be performed.
> Without a clear policy, the effects could be far worse than status quo.
I’m working on a draft for a ruleset and will send it to the list (as a new 
thread). However, this may take until the end of this week.

> 3. Establishing a good and trusted moderators team. Normally I'd say
> ComRel could do that but given their inability to react within the last
> year...
> 
> So, anyone volunteering to do the work?
I would do it, but IMHO it’s inappropriate if I would do that as a non-dev/
normal user.

-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

2017-12-02 Thread Nils Freydank
Am Samstag, 2. Dezember 2017, 21:43:53 CET schrieb Alon Bar-Lev:
> Hi,
> Any reason we do not publish hardened/no-multilib?
> I see we have[1] in place and is working if explicitly added.
> Thanks,
> Alon
> 
> [1] profiles/features/hardened/amd64/no-multilib

Hi,

one of the devs said in #gentoo-hardend (IRC, Freenode) a day ago
it’s just not added yet and we should stay on the old one so long.

I personally guess there’s just too much other stuff in was pushed
deeper down on the todo lists.
-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Packages up for grabs

2017-11-25 Thread Nils Freydank
Am Dienstag, 21. November 2017, 22:01:01 CET schrieb Manuel Rüger:
> Packages up for grabs:
> [...]
> * app-shells/thefuck
> [...]
I think this tool is...magnificent and therefore I’ll proxy maintain it.

-- 
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] manifest-hashes changing to 'BLAKE2B SHA512' on 2017-11-21

2017-11-15 Thread Nils Freydank
Am Mittwoch, 15. November 2017, 17:28:44 CET schrieb Michał Górny:
> Hi, everyone.
> 
> The Council has approved the manifest-hashes switch on 2017-11-12
> meeting [1]. The transition will occur to the initial plan, with small
> changes. The updated plan is included at the end of this mail.
> [...]
Just for general convenience:
It appears you forgot the actual link [1], and I assume it should be:
https://wiki.gentoo.org/wiki/Project:Council/Meeting_logs
resp. taken from this site
https://projects.gentoo.org/council/meeting-logs/20171112.txt

Signatures for the textfile logs are linked on the wiki page aswell.
-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Packages up for grabs: net-analyzer/hexinject

2017-10-19 Thread Nils Freydank
Am Donnerstag, 19. Oktober 2017, 19:06:40 CEST schrieb Jonas Stein:
> Dear all,
> 
> The following packages are up for grabs:
> 
> net-analyzer/hexinject
> [...]

https://github.com/gentoo/gentoo/pull/5987
 
I’d take care of it. Works for me on gcc-6/hardened with the version bump.


-- 
GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B'
Nils Freydank

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] RFC: news item for the 17.0 profiles

2017-10-10 Thread Nils Freydank
Am Dienstag, 10. Oktober 2017, 20:56:32 CEST schrieb Andreas K. Huettel:
> Am Dienstag, 10. Oktober 2017, 01:15:42 CEST schrieb Magnus Granberg:
> > 3) Hardened profiles will be moved to the 17.0 profile as sub profile.
> 
> Are there any special switching instructions for hardened that we need to
> add?
As far as I know hardened had the PIE enabled at least for a while, but it is 
possible to switch to a non-PIE subprofile via gcc-config for gcc <6.

It looks to me as there isn’t any emtytree world rebuild necessary, as long as 
someone comes from hardened with PIE enabled.
-- 
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc
Description: This is a digitally signed message part.