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
Hi Christopher, Am Mittwoch, den 27.05.2020 um 09:37:59 Uhr -0700 schrieb Christopher Head : > ... > I already had a PR 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. > >  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 with some further updates (vobject with python 3.9). Please just close your old PR now.  https://github.com/gentoo/gentoo/pull/15783 signature.asc Description: PGP signature
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
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
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.
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
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.
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.
Dear all, sys-apps/pacman is up for grabs after my retirement as the proxied maintainer for it. There are open bugs, 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. Best regards, Nils Freydank Links:  https://packages.gentoo.org/packages/sys-apps/pacman  https://bugs.gentoo.org/buglist.cgi?quicksearch=sys-apps%2Fpacman_id=3981994  https://bugs.gentoo.org/659474#c1 signature.asc Description: This is a digitally signed message part.
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.
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.
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.
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.
Am Freitag, 15. Dezember 2017, 17:59:59 CET schrieb Anton Molyboha: > On Tue, Dec 5, 2017 at 5:18 PM, Nils Freydank <holgers...@posteo.de> wrote: > > [snip] > > > > > > > > 3. Moderation > > - > > The moderation team has to consist of at least two developers. The > > moderators > > have to do join the moderation team voluntarily. > > > > "have to do join" should probably be "have to join" > > > > > > [snip] Sure, thanks! I don’t know if this is really necessary anyway. Maybe I read too many company related docs :-D -- GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17' Holgersson signature.asc Description: This is a digitally signed message part.
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.
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. 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.  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
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.
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 in place and is working if explicitly added. > Thanks, > Alon > >  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.
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.
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 . 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 , 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.
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.
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.