Re: [gentoo-dev] Standard parsable format for profiles/package.mask file
On 2023-09-21 Thu 15:22, Ulrich Mueller wrote: On Thu, 21 Sep 2023, Arthur Zamarin wrote: Should it be a GLEP, I don't think so? But I'm unsure about it. We do need to document it (for example header of that exact file). It shouldn't be too difficult to wrap this up as a GLEP. To me standardizing a format in Gentoo (outside of PMS-related functionality) requires a GLEP or at the very least some semi-formal documentation outside the file in question in a place like the devmanual. Consider it due diligence of the process that allows people writing code to target the format without having to chase details down into code bases or mailing list threads. OTOH, we don't have a GLEP for eclassdoc either. This is a poor example since it's partly the reason why an awk script with issues relating to extensibility and maintainability is still used to generate eclass manpages. I mainly let it slide when writing pkgcore/pkgcheck parsing functionality because the devmanual [0] was a passable resource at the time. Tim [0]: https://devmanual.gentoo.org/eclass-writing/#documenting-eclasses
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
On 2023-07-03 Mon 04:17, Florian Schmaus wrote: On 30/06/2023 13.33, Eray Aslan wrote: On Fri, Jun 30, 2023 at 03:38:11AM -0600, Tim Harder wrote: Why do we have to keep exporting the related variables that generally cause these size issues to the environment? I really do not want to make a +1 response but this is an excellent question that we need to answer before implementing EGO_SUM. Could you please discuss why you make the reintroduction of EGO_SUM dependent on this question? Just to be clear, I don't particularly care about EGO_SUM enough to gate its reintroduction (and don't have any leverage to do so anyway). I'm just tired of the circular discussions around env issues that all seem to avoid actual fixes, catering instead to functionality used by a vanishingly small subset of ebuilds in the main repo that compels a certain design mostly due to how portage functioned before EAPI 0. Other than that, supporting EGO_SUM (or any other language ecosystem trending towards distro-unfriendly releases) is fine as long as devs are cognizant how the related global-scope eclass design affects everyone running or working on the raw repo. I hope devs continue leveraging the relatively recent benchmark tooling (and perhaps more future support) to improve their work. Along those lines, it could be nice to see sample benchmark data in commit messages for large, global-scope eclass work just to reinforce that it was taken into account. Tim
Re: [gentoo-dev] EGO_SUM (was: [gentoo-project] Gentoo Council Election 202306 ... Nominations Open in Just Over 24 Hours.)
On 2023-06-30 Fri 02:22, Sam James wrote:
> My position on this has been consistent: a check is needed to statically
> determine when the environment size is too big. Copying the Portage
> check into pkgcheck (in terms of the metrics) would satisfy this.
>
> That is, regardless of raw size, I'm asking for a calculation based on
> the contents of EGO_SUM where, if exceeded, the package will not be
> installable on some systems. You didn't have an issue implementing this
> for Portage and I've mentioned this a bunch of times since, so I thought
> it was clear what I was hoping to see.
>
> I would also like (which is not what I was referring to here) some
> limit on the size, given that we already have a limit on the size of
> ${FILESDIR}, but this is less of a concern for me given it's bounded
> by the aforementioned environment size check.
Why do we have to keep exporting the related variables that generally
cause these size issues to the environment? I've asked as much on IRC
multiple times (nearly every time this discussion has been brought up)
and the answers I've gotten are some variation on "it's always been that
way" or "not exporting them would break using commands as external
programs" (e.g. calling via xargs).
The first response isn't a great argument and the second response, while
more valid, also feels less important than having a more minimalistic,
exported environment that causes less issues like this one and others
such as potentially affecting a package's build system in an unexpected
fashion. See bug #721088 for the related discussion on environment
variable exports.
>From my stance, the spec should state that the only variables to be
exported are ones already "semi-standard" and used externally of package
manager internals in the expected fashion, which probably only includes
HOME, TMPDIR, and maybe ROOT. This would of course currently break
packages that use `xargs` while calling internal commands depending on
some of those exported variables, but from a cursory glance at the
gentoo repo, there aren't many ebuilds using that functionality and in
general those that are could be written in an easier to understand
fashion without using xargs. It should also be possible to proxy the
required variables to those commands in various fashions without using
the environment if using commands externally is extremely important to
the few ebuild maintainers who make use of that functionality.
In short, adding checks to portage and pkgcheck feels like a ill-suited
workaround that foists hacking around the error onto users or developers
due to a poor decision made decades ago on environment handling.
Tim
[gentoo-dev] pkgcraft: yet another package manager spec implementation
Hello all, As some already know, for about two years I've been working on pkgcraft[1] which is yet another implementation of the package manager specification (PMS). Having recently achieved the milestone of functionally supporting metadata generation for the tree[2], I thought a wider audience might be interested to learn about the project. In short, pkgcraft is a highly experimental tooling ecosystem for Gentoo. From a design standpoint, it's mainly implemented in rust, bundles its own extended version of bash allowing all PMS functionality to be implemented as builtins, and provides a C library that language bindings can build from -- currently python, ruby, go, and perl bindings exist at varying states of API coverage. The design enables some unique approaches and tools such as helping devs target and improve wildly inefficient bash code. Recently it was leveraged for eclass rework that cut full tree metadata generation time in half for pkgcraft with the gentoo repo. For those interested in more detailed information about the project and its development, see the FAQ[3], dev blog[4], or join the #pkgcraft channel on libera. Thanks, Tim [1]: https://github.com/pkgcraft [2]: https://pkgcraft.github.io/posts/metadata-cache-generation/ [3]: https://pkgcraft.github.io/about/ [4]: https://pkgcraft.github.io/
Re: [gentoo-dev] developing a separate repo spec
On 2021-03-30 Tue 02:18, Ulrich Mueller wrote: > So yes, maybe we should have a separate spec for forward-compatible > repository features that are independent of EAPI. But I think that > incompatible changes won't be possible there and would have to reamin > in PMS. (For example, updating of package dependencies in profiles from > EAPI 0 to EAPI 5 was not forward compatible and required the one year > waiting period.) My main point is if users expect repos leveraging these features to work with most tools it would be helpful to document them in a more canonical, visible location than man pages and probably discuss them more visibly as well. If they were truly optional features it wouldn't be as much of an issue, but an increasing number of complex overlays assume a minimum of portage-1/portage-2 profile-formats features being readily available. Furthermore, I don't think the current spec even mentions the metadata/layout.conf file (and its semi-standard fields) and only passingly mentions overlays but has no details about them. Getting more of that in an official document would help devs know what they have to implement to support current repo/overlay functionality. Finally, pinning repo features to a standardized version allows tools to more readily report why they won't work when failing to meet the repo's required EAPI/RAPI instead of the semi-random errors that will often occur during unimplemented usage. Tim
Re: [gentoo-dev] developing a separate repo spec
On 2021-03-29 Mon 00:06, Ulrich Mueller wrote: > Why not make it a chapter of PMS? A separate document would presumably > imply having a repository API (RAPI?) decoupled from EAPI? One reason is EAPI development often moves relatively slowly and many potential repo spec features are probably simple enough to discuss/implement at a quicker pace, at least initially. That being said, if EAPI 8 isn't finalized most of the repo functionality could be added to it if that approach is more agreeable. Tim
[gentoo-dev] developing a separate repo spec
Hi all, Is there any interest these days in developing and maintaining a separate repo spec [1]? Among other uses, it would help in describing standardized repo features related to metadata/layout.conf settings allowing devs to reference a single, canonical source in order to support repo/profiles features. The current spec doesn't define many repo specific features leading to people jamming all sorts of conditional features in metadata/layout.conf via profile-formats and other entries, none of which is defined in the current spec. Mostly I'm asking because I'm tired of trying to support a pseudo-spec and am quite close to dropping pkgcore's support for the few profile-formats features it tries to enable. Thanks, Tim [1]: https://bugs.gentoo.org/417013
Re: [gentoo-dev] pkgdev: an alternative to `repoman commit`
On 2021-02-27 Sat 07:50, Tim Harder wrote: > Finally responding to all the requests, I've hacked up an initial > alternative to repoman's commit functionality in the form of pkgdev [1] > that uses pkgcheck's API behind the scenes. The project is meant to grow > into a collection of tools for Gentoo development and maintenance, but > initially supports `pkgdev commit` and `pkgdev push` that should work > for a basic git workflow on ebuild repos. Just wanted to follow up that an initial release is in the tree providing commit support (pkgdev commit), manifesting (pkgdev manifest), and push support (pkgdev push). If you're missing your favorite commit-related repoman option please open an issue. What's mainly still missing are good docs explaining usage and workflow. Thanks, Tim
Re: [gentoo-dev] pkgdev: an alternative to `repoman commit`
On 2021-02-27 Sat 19:04, Louis Sautier wrote: > Could you make "push -v" a bit more verbose ? I initially forgot to rebase > and couldn't see the error message from the remote. I guess this also means > that the current code will hide messages from hooks such as changes made to > Bugzilla. Should now be fixed in git.
[gentoo-dev] pkgdev: an alternative to `repoman commit`
Hi all, Finally responding to all the requests, I've hacked up an initial alternative to repoman's commit functionality in the form of pkgdev [1] that uses pkgcheck's API behind the scenes. The project is meant to grow into a collection of tools for Gentoo development and maintenance, but initially supports `pkgdev commit` and `pkgdev push` that should work for a basic git workflow on ebuild repos. In essence, `pkgdev commit` wraps `git add` and `git commit` functionality along with supporting GLEP 66 style message prefixes for any committed files across an ebuild repo. Package manifests are also regenerated and added automatically for any targeted pkg commits. QA scanning is done on `pkgdev push` (not per `pkgdev commit` call) so knowing/learning how to interactively `git rebase` is currently essential to the workflow. Probably the main thing lacking is good docs for the workflow that pkgdev envisions as it differs slightly from the one used with repoman. Feel free to respond with questions, ideas, or flames. If you want to give it a shot, I believe a live ebuild for it has already been added to the tree at dev-util/pkgdev. Also, please open issues on the upstream project if you run into bugs or have feature requests. Thanks, Tim [1]: https://github.com/pkgcore/pkgdev
[gentoo-dev] verifying profiles/package.mask comment format
Hi all, Is there interest in enforcing some basic QA for the semi-formatted comments in profiles/package.mask (and possibly other profiles file types)? I have code implementing the basic functionality done for pkgcheck, but wondered if the format should be standardized and documented more than it may be already before support is merged. Also, I'm unsure it's been noticed but `pkgcheck scan --commits` now verifies any profile changes done in git commits so this support would automatically get run for package.mask changes (and other enabled files) when using pkgcheck locally in that fashion. Thanks, Tim
[gentoo-dev] official github action for pkgcheck
Hi all, For those with ebuild overlays on GitHub interested in QA, I've hacked up an initial GitHub Action for pkgcheck using javascript action support [1] that simplifies running pkgcheck and allows for custom arguments. For those familiar with github workflows, the examples on the pkgcheck-action homepage should be self-explanatory. If you already happen to have pieced together your own pkgcheck workflow, I'd suggest migrating to the official action since it enables many features such as cache support, colored output, internalized gentoo repo syncing, repo metadata generation, and more that your workflow probably doesn't handle. In addition, other interesting features such as incremental output (showing what changed between scans) and possibly even incremental scanning may be supported if I'm inspired. Note that the project is still quite fresh so I'm looking for people willing to report bugs and/or make feature requests. After some time I'll probably publish a release to the GitHub marketplace so it'll be easier to find for newcomers. Thanks, Tim [1]: https://github.com/pkgcore/pkgcheck-action
Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390
On 2021-02-09 Tue 17:51, Benda Xu wrote: > I am wondering how useable pkgcore is on alpha, hppa, etc. Maybe it's > time for us to plan for a Gentoo without essential Python dependency. Just to keep misinformation down, pkgcore currently has nothing to do with rust as it's implemented in python due to basically being deemed portage-ng when it forked ~15 years ago. It previously did have some extensions written in C which have mostly been removed in the current day from CPython catching up in a number of areas. That being said, alternative languages and related support has been looked at for a number of reasons/features and development could move in that direction, but hasn't yet in a public fashion. Tim
Re: [gentoo-dev] using markup language for eclassdoc tags
On 2021-01-04 Mon 04:18, Michał Górny wrote: > I'm all for switching to rST in the foreseeable future but let's stick > with the existing syntax for the transition period, i.e. until new > pkgcore is stable and deployed on Infra. I'm not saying you have to > strictly copy the existing magic, just get a reasonably readable result > for the existing eclasses. The existing syntax is supported by the current work that just uses literal blocks for all multiline text fields. This attempts avoiding all the semi-formatting issues, the downside being that text flow across paragraphs is broken since all the formatting is preserved as written in the eclasses. Pivoting to an actual markup language will be trivial if/when that occurs. Tim
[gentoo-dev] using markup language for eclassdoc tags
Hi, I've written nascent support for eclassdoc man page generation (along with rST and HTML docs) in pkgcore [1] accessible on the cli via `pmaint eclass` that intends to provide an alternative to the current awk implementation [2]. In doing so, I've noticed that the formatting of the docs feels quite haphazard due to reinventing some of the syntax for proper markup languages via embedded tags (e.g. @CODE for literal code blocks) while not handling other basic cases properly (e.g. bulleted lists). What does the community think about selecting a specific markup language and using that for multiline text for related eclassdoc tags (e.g. @DESCRIPTION)? That way, we can toss out the @CODE/@SUBSECTION tag workarounds and use what the markup language natively provides directly. In terms of choice, I'd personally choose reStructuredText since that generally plugs into python easier via docutils/sphinx (currently used for pkgcore's man/html conversion), but am open to discussion of alternatives such as markdown. The downside of moving to an actual markup language is that writing docs for eclasses will get stricter, but conversion issues could be flagged by pkgcheck aiding verification. Thanks, Tim [1]: https://github.com/pkgcore/pkgcore/commit/b3a6b8da [2]: https://github.com/mgorny/eclass-to-manpage/blob/master/eclass-to-manpage.awk
[gentoo-dev] tagging eclasses with allowed transitive inherits
In terms of QA, unintentional transitive eclass usage is generally bad. This occurs when an ebuild uses functionality from an eclass it doesn't directly inherit. It would be useful for eclasses that allow certain transitive usage (e.g. various python eclasses) to be able to tag that relationship internally so tools can make use of that data. Along those lines, pkgcheck now has eclass doc parsing support which allows scanning ebuilds for missing, indirect, or unused eclass inherits as well as internal eclass function usage. In order to more closely report valid indirect inherit results, some tag including this data needs to be included for eclasses allowing this relationship. What do interested parties think about including an optional eclass doc tag such as '@TRANSITIVE_INHERITS:' or other similar name in eclasses that allow this? The tag value would be a space-separated list of allowed transitive inherits for the given eclass. Tim
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On 2020-11-03 Tue 01:28, Joonas Niilola wrote: > Initially Arfrever suggested the same, I wasn't a fan of it because I > believe it's much simpler to make this into a pkgcheck/repoman check like > this. > > However with pkgcheck maybe a similar logic can be used as is used with > StableRequestCheck. So no objections there I guess. That's simple to achieve with pkgcheck's git support. LiveOnlyCheck now flags packages with only live ebuilds that were all added at least a year ago [1]. [1]: https://github.com/pkgcore/pkgcheck/commit/df4e40c2c2
Re: [gentoo-dev] tagging deprecated eclasses internally
On 2020-09-26 Sat 05:23, Ulrich Mueller wrote: > IIUC the authoritative document for eclass documentation is the > description of the format in the eclass-to-manpage.awk script, so this > would be a good start to add support for a new tag. Initial awk implementation available at [1], but currently only supports showing eclass deprecation replacement/message even though all tag groups are supported. I'm open to ideas for how variable/function deprecation tag info should be formatted for manpages. The tag syntax is currently the following: # @DEPRECATED: # This could be simplified to a single line if we want to force the usage of @DESCRIPTION for additional deprecation info, but I think splitting long deprecation info out is helpful. [1]: https://github.com/mgorny/eclass-to-manpage/pull/4
[gentoo-dev] tagging deprecated eclasses internally
In short, pkgcheck (in git) now supports parsing the eclass doc format as specified at [1] for the gentoo repo. This enables extracting more info from various eclass doc annotations. Along those lines, pkgcheck recognizes the '@DEPRECATED:' tag for all eclass doc block types. At the global level, this allows deprecated eclasses to internally document their status inside the '@ECLASS:' block, note their replacement (if any), and add further information if necessary. This allows for the hardcoded and poorly maintained eclass deprecation list in pkgcheck to be replaced by a dynamic version pulled from its eclass cache. If no one objects, I'd like to replace the deprecated-eclass section in metadata/qa-policy.conf with individual '@DEPRECATED:' annotations for the listed eclasses as well as adding info about the tag to the devmanual. Tim [1]: https://devmanual.gentoo.org/eclass-writing/#documenting-eclasses
Re: [gentoo-dev] [RFC] Services and software which is critical for Gentoo should be developed/run in Gentoo namespace
On 2020-09-16 Wed 09:36, Jonas Stein wrote: > The heart of a distribution is basically its infrastructure and the > tools to test, maintain and distribute packages. > > If a distribution relies on external sources, which are not maintained > by the distribution, but a single person, it has been forked. > > A healthy distribution needs to maintain its own tools. Gentoo is quite free to mirror or fork various tools it deems critical to itself. All this should require is poking your favorite infra contact until they set it up. Beyond that, forcing recalcitrant upstreams to move is futile since Gentoo has no leverage besides asking nicely. Speaking for myself, I avoid hosting most of my Gentoo-related work (outside of gentoo repo ebuild mangling) on gentoo.org since I prefer the services offered elsewhere in terms of usability, visibility, and project maintenance. Take this as constructive criticism of how Gentoo currently operates as an upstream host and see it as a call for putting more emphasis towards deploying GitLab, Gitea, or other similar service for Gentoo. Tim
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-admin/needrestart/
On 2020-03-09 Mon 10:42, Joonas Niilola wrote: > > > > Removal of that version was a mistake. Thank you for pointing it out. > > > > Here's the commit re-adding it: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f3fa1c548 > > > > I checked, and repoman doesn't seem to be warning about removing the > > last stable version of a package. > > > > ~Craig > Neither does pkgcheck for what it's worth. Unless the removal causes a > situation where there are unsatisfied revdeps left. That's not correct. If `pkgcheck scan --commits` had been used locally before pushing this would have shown a DroppedStableKeywords result pointing to the commit (if it didn't that's a bug). There is also DroppedUnstableKeywords for dropped ~arch keywords. To reiterate, pkgcheck must be used locally for scanning unpushed git commits to flag these cases, CI won't catch them. Tim
[gentoo-dev] pkgcheck/pkgcore indefinite hiatus
Hi all, Just wanted to note that pkgcheck and pkgcore (as well as snakeoil and pychroot) are effectively on an indefinite hiatus mainly due to my lack of free time for them. Since pkgcheck and pkgcore probably have more users (indirectly via CI) than when its main developer left last time I figured it would be worth mentioning this to the larger group as it could have effects down the road (e.g. EAPI 8 support). If you want more specifics, are inspired to take over or help with development, or have other pkgcore-specific questions feel free to contact me personally. Thanks, Tim
[gentoo-dev] packages up for grabs
Note that some of the packages in this list might have other maintainers, but I'm sure they wouldn't mind co-maintainers. dev-util/pkgcheck sys-apps/pkgcore dev-python/snakeoil dev-python/pychroot app-arch/vimball
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 2019-12-06 Fri 06:33, Michał Górny wrote: > If you need something convenient to commit, app-portage/mgorny-dev- > scripts has pkgcommit tool which does the only useful part of what > repoman did -- that is, prepends package name to the commit message. > For pre-push checks, I use the following oneliner: > $ pkgcheck scan $(git diff origin --name-only $( | cut -d/ -f1-2 | sort -u); echo $? If you want to shorten that, `pkgcheck scan --commits` internalizes most of that and at some point will be extended to enable profile/eclass checks if it notices any related changes. Tim
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 2019-12-06 Fri 04:03, Alexis Ballier wrote: > it's not just like repoman and cvs since repoman commit did push ;) > it will never be perfect but i really like repoman commit to refuse to > even commit if there's something obviously wrong I'm more of the opinion (and am working towards that practicality in terms of runtime speed) that a subset of QA checks should be run as a git hook which would cause push failures on certain classes of bad commits. > as you write below, it's just a matter of checking exit status and > using git, which can be done by scripting, but the script is standard > (*) and mandated to be part of the workflow > it also allows to check or templatize commit messages to follow policy Technically pkgcheck supports more git-related checks than repoman last I checked, i.e. result keywords including BadCommitSummary, DirectStableKeywords, DroppedUnstableKeywords, DroppedStableKeywords, DirectNoMaintainer, and MissingSignOff; with possible future additions such as warning when modifying deps in an ebuild without revbumping. Futhermore, one can scan against all commits in parallel via `pkgcheck scan --commits` which will enable potential commit results that are otherwise skipped. Anyway, my main point is that if someone really wants commit functionality it's semi-trivial to script something similar to what repoman does (assuming exit status/api support exists) and if it's decent enough quality (including tests) I'd probably consider adding it to the pkgcheck repo. Tim
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 2019-12-05 Thu 17:00, Alexis Ballier wrote: > > > pkgcheck is mostly used by your CI checks for > > > producing huge reports, which is nice but addresses a different > > > problem > > There is nothing stopping you from running pkgcheck locally. In > > fact, > > it should work out of the box these days. If you have any problems, > > please report them and I'm sure they will be addressed promptly. > Sure I did that to get reports like what CI does for me now but that's > always been a different usecase; I wasn't aware pkgcheck had the > equivalent of repoman commit While I dislike contributing more to this off-topic tangent, since I've fielded this question/request in IRC a few times in the past I figure I might as well address it again here for the IRC-averse. Personally I use pkgcheck as a QA tool and *git* (or another vcs tool) as a commit tool, just like how I used to use repoman and cvs a long time ago. I generally dislike when cli tools amalgamate disparate features that they weren't designed for so no one has been able to convince me why a tool designed to verify ebuilds and their related repos should support commit capabilities internally. Furthermore, pkgcheck was designed to scale towards scanning multiple pkgs, custom restrictions, or entire repos while I assume the majority of repoman usage is run against singular pkgs. In many cases, a multi-pkg scan doesn't map to a single commit so that functionality would be pretty useless in those situations. To aid those who believe this commit functionality necessary, I've mentioned I would support improving API access and/or configurable exit status settings allowing for easier pkgcheck scripting or other types of external usage. Tim
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On 2019-12-06 Fri 02:15, Michał Górny wrote: > > I think that is not an apt description in my understanding of your original > > post on the matter. The package.deprecated file is supposed to contain not > > just (qualified) package names, but some sort of package dependency > > specifications (PMS 8.2.6). > > > > Perhaps the examples should also reflect this. > > > > I haven't tested anything but bare package names. Feel free to test > and let me know how much of the dep syntax works. Speaking for pkgcheck, it supports the standard atom dep spec, i.e. anything that works in package.mask should also work in package.deprecated. However, note that a matching pkg found both in the base package.mask and package.deprecated won't be flagged as deprecated as it's currently assumed those are mutually exclusive entries (and such entries might be flagged at a later time). Tim
[gentoo-dev] packages up for grabs
The following list of packages are up for grabs that I dropped myself as as a direct maintainer from. There are probably a significantly larger number that I've indirectly maintained hiding under the guise of older projects that mostly act likes herds (e.g. graphics, sound, and vim to name a few) so interested parties should feel free to directly add themselves as maintainers for such packages. Note that some of the packages in this list already have maintainers, but I'm sure most of them wouldn't mind co-maintainers. app-admin/gopass app-admin/lnav app-arch/atool app-arch/libpar2 app-arch/par2cmdline app-arch/pigz app-backup/bup app-backup/duplicity app-doc/zsh-lovers app-editors/hteditor app-forensics/libewf app-misc/binwalk app-misc/dateutils app-misc/evemu app-misc/fslurp app-misc/jq app-misc/ltunify app-misc/ranger app-misc/rq app-misc/skim app-misc/task app-misc/terminal-colors app-shells/gentoo-zsh-completions app-shells/zsh app-text/cpdf app-text/csvfix app-text/docx2txt app-text/extract_url app-text/restview app-text/txt2man app-text/xlsx2csv app-text/yodl dev-lang/swig dev-libs/libyaml dev-libs/rremove dev-libs/stfl dev-ml/camlpdf dev-util/archdiff dev-util/coccigrep dev-util/coccinelle dev-util/cpputest dev-util/icmake dev-vcs/bfg dev-vcs/hgview dev-vcs/tig games-util/wit net-dialup/neocon net-fs/btfs net-fs/sshfs net-im/bitlbee net-irc/weechat net-mail/t-prot net-misc/autossh net-misc/proxychains net-news/newsboat net-print/sshlpr net-proxy/mitmproxy net-proxy/sshuttle sys-apps/ack sys-apps/moreutils sys-apps/pick sys-apps/ripgrep sys-apps/the_silver_searcher sys-fs/archivemount sys-fs/avfs sys-fs/bindfs sys-fs/fuse sys-fs/fuse-common sys-fs/rar2fs sys-process/cronutils sys-process/parallel sys-process/procenv www-client/lynx www-client/qutebrowser x11-misc/sxhkd x11-misc/unclutter-xfixes x11-misc/urxvt-font-size x11-misc/urxvt-perls x11-misc/xdo x11-terms/kitty x11-wm/bspwm x11-wm/herbstluftwm x11-wm/qtile x11-wm/subtle
[gentoo-dev] last rites: net-news/newsbeuter
# Tim Harder (05 Feb 2018) # Unmaintained, replaced by newsboat fork. # Masked for removal in 30 days. net-news/newsbeuter signature.asc Description: PGP signature
Re: [gentoo-dev] An example overlayfs sandbox test
On 2017-09-23 19:59, Rich Freeman wrote: > A read-only container is a much simpler solution and generates the > same kinds of errors as the current sandbox approach, but likely with > fewer compatibility issues. I'm not really sure what tracing gets us > that containers don't, other than having to make sure you trap > everything and handle it. The kernel already handles attempts to > write to read-only files and so on. > We could add an API to designate specific files/directories/etc as > read-write, and then portage would bind mount them as writable in the > container. I doubt bind mounts will scale as far as we'd need them for this approach, i.e. tons of bind mounts needed for complicated builds would cause issues. As has been mentioned before, a different way would be to write some sort of FUSE fs that can handle only allowing access to a specified set of files in a performant manner. Leveraged alongside namespaces/containers this would probably provide us what we need assuming an API of sorts could be written to perform the various request/deny/etc actions on the FUSE fs that we already use for sandboxing. Tim
Re: [gentoo-dev] An example overlayfs sandbox test
On 2017-09-22 22:26, Rich Freeman wrote: > So, we're drifting in topic, but as long as we're coming up with > nice-to-have utilities it would be lovely if our install CDs had > something similar to systemd-nspawn to set up a container instead of a > chroot for performing the install. If nothing else it would make > mount cleanup easier when you're done. I imagine it would just be a > bit of shell scripting with util-linux on the CD - while nspawn is > bundled with systemd you don't need any of its fancier features for > doing an install. If you're fine with python, you could try pychroot [1]. I wrote it with this kind of thing in mind and for doing easy namespaced chroots in python using a context manager. It's even in the tree already. ;) Tim [1]: https://github.com/pkgcore/pychroot
Re: [gentoo-dev] Changing PMS to Portage Manager Specification
On 2017-08-16 05:56, Ulrich Mueller wrote: > > Considering it says exactly the same for EAPI 5, this is almost > > certainly a mistake - but I'd rather confirm this here before > > changing the page. > Unfortunately, information about EAPI 4 and 5 support is not entirely > clear from the NEWS file, so one must look into the git log. Quoting > bug 326459 comment 4 [1]: >EAPI 4: pkgcore-0.6.5 (2011-06-22), which is the first version >(correctly) supporting default src_install. There's another change >for EAPI 4 in 0.7, namely removal of the AA and KV variables, but I >think this can be ignored here (also it's not in the NEWS file). >EAPI 5: pkgcore-0.9.3 (2016-05-28). NEWS says for 0.9 that it has >"Nearly complete EAPI=5 support just missing subslot rebuilds." >This was finally added in 0.9.3, "Add support for PN:slot/subslot >and slotted glob targets." > So yes, it appears that full support for EAPI 5 was added only in > pkgcore-0.9.3, which supports EAPI 6 already. Just to note, I consider pkgcore-0.9 to support EAPI 5 nearly as far as PMS specifies. The news item you pointed out has more to do with adding subslot input support for cli tools (pmerge, pquery, etc) which doesn't have anything to do with PMS. Tim
Re: [gentoo-dev] [PATCHES] python-r1, add integrity checks for redefined control vars
I've attached another simple patch that I don't think was fixed in your
changeset to stop the 'impl' var from _python_obtain_impls() in
python-r1.eclass from leaking into the environment.
Thanks,
Tim
>From 0a6174036e5d31028e47fb5f477033fdb7b76aba Mon Sep 17 00:00:00 2001
From: Tim Harder
Date: Fri, 3 Mar 2017 15:49:16 -0500
Subject: [PATCH] python-r1.eclass: localize variable to avoid leaking into the
env
---
eclass/python-r1.eclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass
index 929ec8fa8f..4d27881cd5 100644
--- a/eclass/python-r1.eclass
+++ b/eclass/python-r1.eclass
@@ -476,6 +476,7 @@ _python_obtain_impls() {
MULTIBUILD_VARIANTS=()
+ local impl
for impl in "${_PYTHON_SUPPORTED_IMPLS[@]}"; do
has "${impl}" "${PYTHON_COMPAT[@]}" && \
use "python_targets_${impl}" && MULTIBUILD_VARIANTS+=( "${impl}" )
--
2.12.0
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/
On 2016-02-09 19:59, Robin H. Johnson wrote: On Tue, Feb 09, 2016 at 07:03:28PM -0500, Tim Harder wrote: Just to note, devs that make these mistakes should already get emails from the CI test setup [1]. If those emails need to be more specific about the severity I'm sure that could be changed so you don't need to act like a CI bot if you don't want to. ;) [1]: https://archives.gentoo.org/gentoo-automated-testing/message/79a7b4fe2afaa71de9ef1189464f8324 Well then raise the severity, because it's still blocking rsync as nobody fixed it. I have reverted it now, so that rsync continues to propagate (it would be nice if repoman manifest-check could be non-fatal about missing DIST entries, but strict about everything else). I imagine in the end it would be better to put some of the faster checks into the git hook pipeline itself. For example, reject commits at push time that are missing DIST entries. Since I'm not familiar with the infra setup all I can do is provide support if it's feasible and someone wants to implement this using pkgcore/pkgcheck similar to what the CI stuff already does. Thanks, Tim signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-fs/samba/, net-fs/samba/files/, net-fs/samba/files/4.4/
On 2016-02-09 18:50, Robin H. Johnson wrote: Your commit is missing a DIST entry for: samba-disable-python-patches-4.4.0.tar.xz As such, is breaking git->rsync export. Please fix ASAP. Was this a partial repoman used, because the commit log shows a Portage line, yet the DIST is still missing. Just to note, devs that make these mistakes should already get emails from the CI test setup [1]. If those emails need to be more specific about the severity I'm sure that could be changed so you don't need to act like a CI bot if you don't want to. ;) Thanks, Tim [1]: https://archives.gentoo.org/gentoo-automated-testing/message/79a7b4fe2afaa71de9ef1189464f8324 signature.asc Description: PGP signature
Re: [gentoo-dev] "Lazy" use flags?
On 2016-02-09 15:35, Róbert Čerňanský wrote: BTW, what you are describing is essentially the same as in this bug: https://bugs.gentoo.org/show_bug.cgi?id=258371. It was also discussed on this list couple of times. I too would very much like to see it in portage. pkgcore's current resolver has supported this for a long time if anyone really needs this feature now; however, switching to and/or using pkgcore currently comes with quite a few caveats if one is used to portage. Tim signature.asc Description: PGP signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-01-31 23:59 UTC
On 2016-01-31 21:48, Daniel Campbell wrote: On 01/31/2016 04:05 PM, Robin H. Johnson wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2016-01-31 23:59 UTC. Removals: [snip] x11-apps/ardesia 20160129-11:18 pinkbyte c42fbbf x11-apps/ccsm20160128-08:10 pinkbyte 0f35eae x11-apps/simple-ccsm 20160128-08:10 pinkbyte 0f35eae Additions: [snip] x11-misc/ardesia 20160129-11:18 pinkbyte c42fbbf x11-misc/ccsm20160128-08:10 pinkbyte 0f35eae x11-misc/simple-ccsm 20160128-08:10 pinkbyte 0f35eae [snip] Am I reading this right? Does that mean they were added and removed at the exact same time? That's how package moves show up (0f35eae) with the current adds/removes script. Tim signature.asc Description: PGP signature
Re: [gentoo-dev] Updating all Manifest to contain SHA256 SHA512 WHIRLPOOL
On 2015-09-22 15:23, Justin Lecher (jlec) wrote: > https://github.com/jlec/gentoo/commit/0df86dcca0aa981fa7bdba633653697e2b > 40781c > Although my script checks whether the size and SHA256 changed, but > better you could also take a look. You could open a pullreq against the gentoo github repo and I think pkgcheck will be automatically run against it. Then look if there are any remaining MissingChksum reports in the output. Tim signature.asc Description: PGP signature
Re: [gentoo-dev] Updating all Manifest to contain SHA256 SHA512 WHIRLPOOL
On 2015-09-18 04:58, Justin (jlec) wrote: > 2. > Any suggestion how to do this? repoman has a manifest-check function but that > is > not functioning (bug filed). Any other tool around? Perhaps using pkgcheck? With regards to pkgcheck, run the following in a configured gentoo repo to generate a list of missing checksums in Manifest files: pkgcheck -c repo_metadata or a variation where the current working directory doesn't matter: pkgcheck -c repo_metadata -r gentoo '*' Note that this will probably output a bunch of metadata exceptions as well since the tree has a bunch of ebuilds with unknown mirrors in it (mostly berlios and bitbucket) and running the above disables the check for them so they show up as errors instead. Tim signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Rebooting the Installer Project
On 2015-07-18 15:01, Matthew Marchese wrote: > I'd like to hear it all so please speak your mind. Looking forward to > hearing from you. On another semi-related note, I've always thought it would be useful to extend repos.conf support to handle binary repos so one could use layman or equivalent tools to easily add binary repos, prioritize them however you like, and leverage them to get new installs quickly rolling or just for regular usage. That way PORTAGE_BINHOST and related settings could be tossed down the line and binary derivatives should be able to easily leverage such support. Of course while talking about unimplemented features this would could be even more interesting alongside a better, spec-ed out binpkg format, perhaps something that supports splitting metadata and actual binary pkg data so the main metadata cache could be sanely synced around via git or similar. These have both been dream goals as I've poked at pkgcore over the past year or so (and yes I'm aware paludis implements something similar to these things already). Tim signature.asc Description: PGP signature
Re: [gentoo-dev] s6.eclass: new eclass for installing s6 services
On 2015-06-01 17:08, William Hubbs wrote:
> [[ $name ]] ||
> die "${ECLASS}.eclassYou must specify the s6 service name."
This looks like it's missing a colon and space after ${ECLASS}.eclass,
note that this typo appears to be copied to a few other places.
Tim
signature.asc
Description: PGP signature
Re: [gentoo-dev] more packages up for grabs
On 2015-05-19 09:40, Francesco Riosa wrote: > Il 18/05/2015 23:13, Tim Harder ha scritto: > > * media-gfx/darktable > > * media-gfx/dcraw > > * media-gfx/gmic > > * media-gfx/rawtherapee > > * media-plugins/gimp-gmic > > > nobody for these? they are rather important for anyone who does photo on > linux. Note that those were dropped to the graphics herd, i.e. I and other people will probably poke them from time to time... just expect some probable lag in version bumps. Tim signature.asc Description: PGP signature
[gentoo-dev] more packages up for grabs
Here are some packages that I've dropped (or will drop) myself as primary maintainer from. Many of them (e.g. protobuf*) could really use some more collaborative non-maintainer update method but no one has gotten around to finalizing, documenting, and implementing the required metadata.xml changes yet as far as I know. Anyway, here's the package list (somewhat incomplete because some were dropped months ago and might also have new maintainers already but I doubt they'd mind extra help): * app-admin/lsyncd * app-arch/tardy * app-misc/lfm * app-misc/nut * app-misc/solaar * app-office/ledger * app-text/apvlv * dev-libs/fstrm * dev-libs/protobuf * dev-libs/protobuf-c * dev-python/skype4py * dev-util/gengetopt * dev-util/scanmem * net-dns/ldns * net-dns/ldns-utils * net-dns/unbound (has proxy maintainer who's mostly absent atm) * net-misc/sipcalc * sys-auth/pam-script * sys-fs/ldapfuse * sys-fs/s3backer * sys-fs/s3fs * sys-fs/s3ql * sys-libs/libstatgrab * media-libs/csfml Packages dropped to herds and might benefit from more dedicated maintainers: * dev-python/dugong * dev-python/jedi * dev-python/kazoo * dev-python/pyqtgraph * dev-python/pysfml * dev-python/robotframework * dev-python/robotframework-selenium2library * dev-python/robotframework-sshlibrary * dev-python/sleekxmpp * games-emulation/vbam * media-gfx/darktable * media-gfx/dcraw * media-gfx/gmic * media-gfx/rawtherapee * media-gfx/wkhtmltopdf * media-libs/libsfml * media-plugins/gimp-gmic * media-sound/vitunes * net-analyzer/sinfo * net-dialup/minicom * net-im/ejabberd * net-libs/canlock * net-libs/libflowmanager * net-libs/libprotoident * net-libs/libtrace * sys-process/criu Finally, here's an incomplete list of packages that I haven't dropped yet, but will probably be on the chopping block in the near future (i.e. feel free to add yourself to them and/or do stuff to them). * app-arch/pbzip2 * app-arch/snappy * app-misc/pfm * app-misc/vittk * app-text/ansifilter * app-text/par * app-text/txt2man * dev-db/recutils * dev-lua/lpeg (we probably could use a lua herd) * dev-lua/lua-json * dev-util/apitrace * dev-util/byacc * dev-util/trinity * dev-util/umockdev * media-libs/glew * media-sound/squeezeslave * www-client/dwb * www-client/links * www-client/vimb * www-client/vimprobable2 * www-misc/urlwatch If you have questions about any of them feel free to drop me a line. Thanks, Tim signature.asc Description: PGP signature
[gentoo-dev] pkgcore reborn
Hey all, pkgcore-0.9 is now in the tree with working EAPI 5 support with the exception of subslot rebuilds. Alongside that, pkgcore-checks (pcheck) has been renamed to pkgcheck and dev-util/pkgcheck-0.5 now in the tree should be able to perform full tree scans or whatever you were doing with pkgcore-checks a long time ago. Also, EAPI 6 support for pkgcore is nearly done so we shouldn't have any lag issues this time compared to EAPI 5. I'm sure there are plenty of bugs to be found so please file issues for the respective project under the pkgcore org on github [1] if you want us to take a look or submit a pull request if you feel like doing a bit of hacking. In terms of future major development, I'll probably be focusing on rewriting the resolver and developing various tools leveraging pkgcore's API. Also of importance is reviving and refreshing the documentation as well as providing more examples and code for using the API. A few readthedocs sites already exist (e.g. [2]) but we haven't updated the process, theme, etc yet so docs are still broken in a few places. If you want to get involved with development, have ideas for features you want implemented, or just want to chat about pkgcore feel free to drop us a line in #pkgcore on freenode. Otherwise the pkgcore-...@googlegroups.com mailing list [3] could be revived as well. Thanks, Tim [1]: https://github.com/pkgcore [2]: http://pkgcore.readthedocs.org [3]: https://groups.google.com/forum/#!forum/pkgcore-dev signature.asc Description: PGP signature
Re: [gentoo-dev] ALLARCHES bugzilla keyword for stabilization requests
On 2015-03-30 17:14, James Le Cuirot wrote: > I tried to find the council meeting minutes where this was discussed > but to no avail. :( Sorry, I'm a bit slow. I'll be writing those up when I send out the next call for agenda items this week. Tim signature.asc Description: PGP signature
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On 2015-03-23 18:54, Pacho Ramos wrote: > Personally I think a tag in metadata to show that a package can be > touched by others freely would be much more useful than having a big > herd with a mix of packages that are not even related. Sure, I'd just like to expose this status in a better manner for the set of official and unofficial tools out there than having to grep the tree or similar. I'm fine with a metadata flag if people can agree on what that is as I'm unsure if the previous discussion on that topic went anywhere. > If people usually don't have time to fix the tons of packages that > lacks a maintainer (and, then, they could also fix them without asking > for permission), I doubt that new herd would get much real help :( This isn't about unmaintained pkgs or asking for help. It's more an experiment in non-territorial package maintenance. Tim signature.asc Description: PGP signature
Re: [gentoo-dev] collab herd for cooperative pkg maintenance
On 2015-03-23 13:48, Panagiotis Christopoulos wrote: > You want to have a herd for that or something in metadata.xml that would > raise a > flag that the package can be freely touched/maintained by anyone? I'd rather have a herd so people can easily scan via euscan or similar to see the entire array of pkgs falling into the space. Abusing another metadata field doesn't give the same visibility or would require changes from tools. For example, bugs assigned to the herd or with it in CC could be fixed by anyone without having to ask for permission. How would that be handled easily when using an extra metadata field? Tim signature.asc Description: PGP signature
[gentoo-dev] collab herd for cooperative pkg maintenance
Hey all, Having been around for a few years I've inherited or added quite a few pkgs to the tree that I wouldn't mind other people fixing/bumping/etc that don't fall into any current herds. With that in mind, I think it would be an interesting experiment if we had a collaborative herd (probably named "collab") that signals the status that anyone is generally free to fix, bump, or do sane things to the pkgs with the caveat that you fix what you break. Anyone else interested in such a setup? Tim signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] please review ebuilds for neovim and deps
On 2015-02-21 13:19, Ben de Groot wrote:
> > neovim:
> >
> >> # Copyright 1999-2015 Gentoo Foundation
> >> # Distributed under the terms of the GNU General Public License v2
> >> # $Header: $
> >>
> >> EAPI=5
> >> inherit cmake-utils flag-o-matic
> >>
> >> DESCRIPTION="Vim's rebirth for the 21st century"
> >> HOMEPAGE="https://github.com/neovim/neovim";
> >> if [[ ${PV} == ]]; then
> >> inherit git-r3
> >> EGIT_REPO_URI="git://github.com/neovim/neovim.git"
> >> KEYWORDS=""
> >> else
> >> inherit vcs-snapshot
> >> COMMIT="8efb3607a7f6cefce450953c7f8d5e3299347bae"
> >> SRC_URI="https://github.com/${PN}/${PN}/tarball/${COMMIT} ->
> >> ${P}.tar.gz"
> >
> > I don't think relying on stability of generated tarballs is a good
> > idea. The same applies to almost all other ebuilds.
> Do we often run into trouble with that? I know it's not perfect, but
> it should be temporary, until we get regular releases.
Personally I'd rather do manual snapshot releases for now. Many vim
packages end up being handled in the same fashion anyway (glance at [1]
for proof).
Tim
[1]: http://dev.gentoo.org/~radhermit/vim/
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-board/stockfish: stockfish-6.ebuild metadata.xml Manifest ChangeLog
On 2015-02-10 12:38, hasufell wrote: > > - Motion: "The council encourages the games team to accept join > > requests and elect a lead. In the event they don't elect a lead > > within 6 weeks, we will consider the team as dysfunctional and thus > > disband it." > > Accepted with 6 yes votes and 1 abstention. > This is offtopic, but what's the status? Who is the new lead? This was mostly contingent on new people joining the games herd, from what comments I got back no one really wanted to join (at least under the current system). I wasn't going to force the games team to elect a new lead when it appears none cared much at that point who the lead was. Also, I would advise caution on considering it dysfunctional and disbanding it due to this. To reinforce the point that's been said before, if people want the status quo to change the most direct route is often joining and making changes, not standing on the sidelines asking for change. Thanks, Tim signature.asc Description: PGP signature
Re: [gentoo-dev] Things one could be upset about
On 2015-01-19 07:28, Patrick Lauer wrote: > On 01/19/15 17:47, Jeroen Roovers wrote: > > On Sat, 17 Jan 2015 19:35:09 +0800 > > Patrick Lauer wrote: > > > >> * AutoRepoman catches on average maybe 2 user-visible breakages. > >> Mostly removing stable on HPPA ;) > >> Fix: Make repoman faster (tree-wide scans take ~2 CPU-hours) > >> Fix: Remind people that using repoman is not optional > > > > repoman doesn't check reverse dependencies for the package you're > > working on. > > If it were fast enough we could do that. > > pcheck from pkgcore was at one point down to under 3 minutes for a full > tree scan, that's pretty much "fast enough" so that people could run it > on almost every ebuild removal. repoman takes around 30 minutes when > parallelized, on the fastest hardware I currently have access to. Or > about 2 CPU-hours with a single thread ... that's prohibitively slow. I'd be interested to hear if pcheck has regressed significantly at all for you when running it now on a similar set up. Thanks, Tim pgpzx_hu442lz.pgp Description: PGP signature
[gentoo-dev] app-emulation/vagrant up for grabs
Hi, I've dropped myself as maintainer of app-emulation/vagrant as I have no time or interest to try debundling the path that upstream has taken and rarely use it anyway. If someone is interested, feel free to pick it up and reassign bugs 466344 and 505124 to yourself. However, my advice to those interested (if you value your time and possibly sanity) you'll last rite app-emulation/vagrant and add something like app-emulation/vagrant-bin instead if you must have it in the main tree. Tim pgpdm6NkDSKl9.pgp Description: PGP signature
Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing
On 2014-12-07 15:02, Kristian Fiskerstrand wrote: > >> The most important consumer is app-text/pdftk Unfortunately, > >> there is still no replacement for the latter which works as > >> good, especially if you have tricky pdfs to process. Loosing gcj > >> would therefore be a real loss. > > As long as you're fine with any command-line pdf processing tool, > > you could use app-text/cpdf which I've used for a long time and > > just added to the tree. > > Note that it's licensed under a non-commercial type license > > though. > Why would we want to replace a working GPL-2 application for an > application under a non-free license? As one of the users of > app-text/pdftk I'm not a big supporter of this (although I have not > looked into mcpdf as was brought up earlier in this thread, although > that as well seems to be under a more restrictive AGPL-3 license). I'm not saying it's a replacement, it's an alternative. Also, some of us are less picky about licensing issues as long as the source code is available and free for personal use. :) Tim pgpUdoqQuXnyI.pgp Description: PGP signature
Re: [gentoo-dev] Re: sys-devel/gcc::mgorny up for testing
On 2014-12-07 13:15, Martin Vaeth wrote: > The most important consumer is app-text/pdftk > Unfortunately, there is still no replacement for the latter > which works as good, especially if you have tricky pdfs to > process. Loosing gcj would therefore be a real loss. As long as you're fine with any command-line pdf processing tool, you could use app-text/cpdf which I've used for a long time and just added to the tree. Note that it's licensed under a non-commercial type license though. Tim pgpGEuEzOcHeU.pgp Description: PGP signature
Re: [gentoo-dev] help needed: net-irc/weechat
On 2014-11-12 06:31, Andreas K. Huettel wrote: > [Sending this out for scarabeus since the gmail conspiracy is keeping him > from > posting to the -dev mailing list...] > Hello people, > I stopped using weechat and it is slowly piling bugs, so if someone wants to > take over, it would be lovely. > net-irc/weechat Since nothing appeared to be happening in this case, I took it over. As usual anyone should feel free to help out if they're interested. Thanks, Tim pgp0XEHP_KsAO.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 2014-11-23 20:17, hasufell wrote: > dev-python/jedi I'll help maintain this. Tim pgpeY1d3cCgA7.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 2014-11-21 10:31, hasufell wrote: > Are you serious? > Instead of creating random competing concepts in one repository we > should rather enhance configuration options, so that the USER can choose > what he likes instead of the developer. > I think this is a very bad idea. > If we all decide to drop the eclass, then fine. Until then, users don't > have any convenient way to have games world-executable without > overwriting the eclass (which I currently do myself). Personally I've seen somewhat competing concepts evolve in the tree over the past years, specifically python/ruby eclass (r)evolution springs to mind. Stuff didn't immediately get deprecated in those cases but only after a certain period of burn-in for the newer work. I guess this case is somewhat different in that the outcome is a bit more visible to the average user and people want to remove the thing entirely. If this is a step in that direction fine and maybe this will help spur discussion to get that moving somewhere. Tim pgphhehLmVmBz.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] games.eclass: Allow to disable games permissions wrt #467386
On 2014-11-21 09:54, hasufell wrote: > There are users who seem to like it and the games team wants to keep it > as well, so I don't see a reason to push into that direction. > The main thing is that you cannot turn off all the permission stuff in > the eclass whether you like it or not. Changing the install variables > thing is just for convenience and already possible. If people don't want to use the games eclass, then don't use it. I thought this had already been discussed and mostly ok-ed. I don't see the point of adding circumvention methods if you can just avoid it altogether. Tim pgpKweuVpdC43.pgp Description: PGP signature
[gentoo-dev] last rites: dev-embedded/msp430*
# Tim Harder (31 Oct 2014) # Deprecated, use >=sys-devel/crossdev-20141030 to build an msp430 # toolchain using the standard binutils/gcc/newlib/gdb packages. # Masked for removal in 30 days. dev-embedded/msp430-binutils dev-embedded/msp430-gcc dev-embedded/msp430-gdb dev-embedded/msp430-libc dev-embedded/msp430mcu pgpy5Igqn_S9Y.pgp Description: PGP signature
[gentoo-dev] last rites: dev-util/cmockery
# Tim Harder (25 Oct 2014) # Deprecated project, devwlopment continues in dev-util/cmocka. # Masked for removal in 30 days. dev-util/cmockery pgpFbqYtjXuY2.pgp Description: PGP signature
[gentoo-dev] last rites: dev-python/pry
# Tim Harder (25 Oct 2014) # Upstream migrated to nose for testing instead of their own framework. # Masked for removal in 30 days. dev-python/pry pgpjRV0rQHQab.pgp Description: PGP signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On 2014-09-14 21:57, Kent Fredric wrote: > I generate metadata for the perl-experimental overlay periodically as a > snapshotted variation of the same, and the performance isn't so bad. Overlays with few eclasses are much different than the main tree. Anyway, egencache isn't bad it's just significantly slower than alternatives so it could be sped up quite a lot if necessary. > However, what I suspect you *could* do with a push hook is regen metadata > for only things that were modified in that commit, because I believe > there's a way to regen metadata for only specific files now. > ie: > modifications to cat/PN *would* trigger a metadata update, but only for > that cat/PN > modifications to eclass/* would *NOT* trigger a metadata update as part of > the push. > And doing tree-wide "an eclass was changed" updates could be done with > lower priority in an asynchronous cron job or something so as not to block > workflow for several minutes/hours/whatever while some muppet sits there > watching "git push" do nothing. If we need to do piecewise regen it seems we would be better off just sticking with the current scheduled cron job approach. Otherwise it sounds like one could pull updates without having the correct metadata for a significant portion of the tree. Tim pgpD3F3w_LSNi.pgp Description: PGP signature
Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
On 2014-09-14 10:46, Michał Górny wrote: > Dnia 2014-09-14, o godz. 15:40:06 > Davide Pesavento napisał(a): > > How long does the md5-cache regeneration process take? Are you sure it > > will be able to keep up with the rate of pushes to the repo during > > "peak hours"? If not, maybe we could use a time-based thing similar to > > the current cvs->rsync synchronization. > > This strongly depends on how much data is there to update. A few > ebuilds are quite fast, eclass change isn't ;). I was thinking of > something along the lines of, in pseudo-code speaking: > > systemctl restart cache-regen > > That is, we start the regen on every update. If it finishes in time, it > commits the new metadata. If another update occurs during regen, we > just restart it to let it catch the new data. > > Of course, if we can't spare the resources to do intermediate updates, > we may as well switch to cron-based update method. I don't see per push metadata regen working entirely well in this case if this is the only way we're generating the metadata cache for users to sync. It's easy to imagine a plausible situation where a widely used eclass change is made followed by commits less than a minute apart (or shorter than however long it would take for metadata regen to occur) for at least 30 minutes (rsync refresh period for most user-facing mirrors) during a time of high activity. I haven't run portage metadata regen on a beefy machine lately, but I don't think it could keep up in all cases. Perhaps someone can prove me wrong. Anyway, things could definitely be sped up if portage merges a few speed tweaks used in pkgcore. Specifically, I think using some of the weakref and perhaps jitted attrs support along with the eclass caching hacks would give a 2-4x metadata regen speedup. Otherwise pkgcore could potentially be used to regen metadata as well or some other tuned regen tool. Tim pgpGfmG5Ks9YC.pgp Description: PGP signature
[gentoo-dev] reinvigorating Gentoo games development
Hi all, For those not following council meeting discussions, I volunteered to help new devs join the games herd/team in order to foster discussion about its future path and move towards electing a more active team lead in a month or so. Just to make things clear, although I'm currently in the games herd I have no interest or time to be lead and don't work regularly enough on games in Gentoo for that to make any sense. I just want to help bring in new devs that feel left out from the current, often unresponsive team to aid development. I imagine several potentially interested devs will want to change some current game policies (such as seen in [1]) before they consider joining so there may be a chicken and egg situation. However, anyone interested in games on Gentoo should either respond here or ping me on IRC and I'll try to organize things. Finally, I don't want non-devs and the community at large to feel left out either so hopefully discussions can include more on reviewing contributions, overlays, and other ways for the community to interact positively. I know this has been brought up in several previous threads (such as [2]), but most of them seemed to trail off without any firm resolution or guidance for interested community members. Thanks, Tim 1: http://thread.gmane.org/gmane.linux.gentoo.devel/91839 2: http://thread.gmane.org/gmane.linux.gentoo.devel/88570 pgpUGyfm9pHIu.pgp Description: PGP signature
[gentoo-dev] Last rites: dev-lang/fpc-ide
# Tim Harder (26 Apr 2014) # Deprecated by the ide use flag on recent versions of dev-lang/fpc. # Removal in 30 days. dev-lang/fpc-ide pgpa7lVDXbm_G.pgp Description: PGP signature
Re: [gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
On 2014-04-11 09:02, Ralph Sennhauser wrote: > java-utils-2 does it like that since before PMS, since around the time > Portage gained support for EAPIs. PMS leaves it open whether using > DESTREE in pkg_setup is allowed or not. Neither Portage, Paludis nor > earlier version of Pkgcore did mind this use. Well, one could argue > that using DESTREE in pkg_setup is allowed. Pkgcore explicitly worked around it for a long time (since 0.2.12-ish) specifically noting it was for this case until I dropped it recently since keeping targeted hacks around for things like this isn't great for maintainability. > I would welcome PMS clearly defining the scope of DESTREE and the most > logical choice of course would be src_install only where it is > currently explicitly required. Yep, as Ulrich noted (and I noted in the 2nd paragraph of my first message) PMS already defines the scope of DESTTREE to be src_install only. > If we fix java-utils-2 we should fix PMS as well. After all, > java-utils-2 is a prime suspect for the different handling of > DESTREE and for instance INSDESTREE in PMS. This asymmetry is why I > didn't touch java-utils-2 when I looked into exactly this usage of > DESTREE 2+ years ago. Just to note, I already committed the fix a few days ago after discussing it a bit on the java herd IRC channel. Really it would be great if someone was interested in reworking most of the java eclasses since they've been showing their age for a while now. Thanks, Tim pgpjO6aUuSb2m.pgp Description: PGP signature
[gentoo-dev] [PATCH] fix java-utils-2 eclass to only use DESTTREE during src_install
Currently the java-utils-2 eclass refers to $DESTTREE in the
java-pkg_init_paths_ function that gets run during pkg_setup (via the
java-pkg-2 eclass that calls java-pkg_init). The java-pkg_init_paths_
function also gets called again for most src_install java-utils-2 eclass
functions that use the related variables but the current implementation
doesn't allow the variables to be reset.
This is an issue for pkg managers that try to follow the spec and don't
define DESTTREE outside of src_install. Note that DESTTREE was recently
added to pms so you'll probably have to view the live version to see the
DESTTREE related info.
The attached patch fixes the situation by adding java-pkg_init_paths_
calls to a couple src_install related functions that use the related
variables and removes the call to it during pkg_setup (no related
variables appear to be used before src_install but I could be missing
something). People familiar with various java pkgs should test it to
make sure those variables aren't used before src_install.
Thoughts or comments welcome,
Tim
--- java-utils-2.eclass
+++ java-utils-2.eclass
@@ -192,6 +192,7 @@
[[ ${#} -lt 1 ]] && die "At least one argument needed"
java-pkg_check-phase install
+ java-pkg_init_paths_
local dest=/usr/share/doc/${PF}/examples
if [[ ${1} == --subdir ]]; then
@@ -543,6 +544,7 @@
# QA checks
java-pkg_check-phase install
+ java-pkg_init_paths_
[[ -z "${dir}" ]] && die "Must specify a directory!"
[[ ! -d "${dir}" ]] && die "${dir} does not exist, or isn't a directory!"
@@ -2060,7 +2062,6 @@
java-pkg_announce-qa-violation "Using old ant_src_unpack. Should be src_unpack"
fi
- java-pkg_init_paths_
java-pkg_switch-vm
PATH=${JAVA_HOME}/bin:${PATH}
pgp5lx1_7XasF.pgp
Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 2014-03-11 13:10, Pacho Ramos wrote: > app-arch/snappy I can help with this. > dev-python/snappy This can go to me/python. - Tim pgpghBrqScHqq.pgp Description: PGP signature
Re: [gentoo-dev] Add support for rsync patches
On 2014-02-05 00:13, Mike Frysinger wrote: > i don't see any patches in rsync-3.1.0. i'd be hesitant to add support for > them even if they were there ... They're in a different tarball [1], and yes I agree that it would be best to use epatch_user or similar. Tim [1]: http://rsync.samba.org/ftp/rsync/rsync-patches-3.1.0.tar.gz pgpwjbE9Ii_TQ.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 2013-12-23 08:01, Pacho Ramos wrote: > sys-process/cronutils I'll maintain this. Tim pgptQxCZkO57Z.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
On 2013-06-16 06:55, Brian Dolbec wrote: > > > Due ferringb retirement the following packages are up for grabs: > > > dev-python/snakeoil > > > sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained > > > and neither has eapi5 support) > I'll take pkgcore (if somehow we can get eapi 5 finished.) > I'll take snakeoil. I'm adding some of it's libs into catalyst I can help with pkgcore, pkgcore-checks, and snakeoil as well. I've got most of the EAPI 5 resolver work done in a local fork and have been fixing other bugs I've found along the way. Tim
Re: [gentoo-dev] Packages up for grabs due lack of time
On 2013-02-16 Sat 05:08, Pacho Ramos wrote: Due pva lack of time the following packages are now up for grabs: net-libs/libmnl Added to netmon herd. Tim pgpHn4U3M2RcW.pgp Description: PGP signature
Re: [gentoo-dev] scheme herd needs help
On 2013-02-03 Sun 13:21, Cyprien Nicolas wrote: Who is behind lisp overlay? Only you or more people that could also be contacted to try to get them maintaining guile? Thanks for the info We are 2 or 3 non-dev volonteers. pchrist is busy with life and common-lisp stuff, grozin and radhermit give a hand on some packages. The lisp overlay guys are easily rechable through #gentoo-lisp or gentoo-lisp mailing list. About guile, I'm the only one having touched it for the last 2 years [1]. I think I could proxy-maint it, with an experienced dev in eselect modules and multiple SLOT packages. I can help maintain guile and will proxy stuff for you (but I'm not in the proxy-maintainers herd). Tim pgpSbtyAuIrur.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due lack of time
On 2013-02-03 Sun 04:46, Pacho Ramos wrote: net-dns/ldns-utils net-dns/unbound net-libs/ldns I'll help maintain these. Tim pgpVlqSDEz0M6.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-doc/abs-guide: metadata.xml ChangeLog
On 2013-01-27 Sun 15:06, Ryan Hill wrote: If you have some kind of problem with this, I suggest you change the default output of metagen. I just find it annoying to have duplicate info for herds under the maintainer tag since tools like euscan and other scripts take that to mean a package has a separate maintainer and herd. Anyway the docs mention that the maintainer tag is supposed to be used for individual maintainers besides herds, but I can see how that metagen help output can be confusing. Tim pgpe0YubCOQ43.pgp Description: PGP signature
[gentoo-dev] Lastrite: dev-python/github2
# Tim Harder (27 Jan 2013) # Masked due to deprecated API, use dev-python/PyGithub instead # Removal in 30 days dev-python/github2 pgpjD6sKJpimi.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due nelchael retirement
On 2012-12-16 Sun 06:22, Pacho Ramos wrote: dev-libs/protobuf I'll take this since I already maintain protobuf-c. Tim pgpgjSAUrAAzt.pgp Description: PGP signature
Re: [gentoo-dev] ebuild laziness and binpkg overhead
On 2012-06-12 Tue 20:20, Michael Sterrett wrote:
> Calling "use" in global scope isn't allowed so what are you suggesting
> they do instead?
Can't they just do something similar to how most cmake-utils and
autotools-utils users do things? For example:
src_configure() {
G2CONF="${G2CONF}
--disable-bash-completion
--disable-hal
--disable-schemas-compile
--with-dbus-service-dir=/usr/share/dbus-1/services
$(use_enable afp)
$(use_enable archive)
$(use_enable avahi)
$(use_enable bluetooth obexftp)
$(use_enable bluray)
$(use_enable cdda)
$(use_enable fuse)
$(use_enable gdu)
$(use_enable gphoto2)
$(use_enable ios afc)
$(use_enable udev)
$(use_enable udev gudev)
$(use_enable http)
$(use_enable gnome-keyring keyring)
$(use_enable samba)"
gnome2_src_configure
}
Seems like that should work fine.
Tim
pgptmeIZLBJc0.pgp
Description: PGP signature
Re: [gentoo-dev] unmasking of jabberd, and now feeling uncertain about it...
On 2012-05-19 Sat 08:03, Samuli Suominen wrote: > net-im/jabberd was masked for removal but I've fixed the bugs that it > was masked for > in fact, there should now be 0 bugs in bugzilla for it (or can anyone > find some?) > so i've unmasked it again > was that right, wrong, what? i really don't know anything about the > application itself > does jabberd2 replace all of it's functionality? I don't know how many people are using jabberd rather than jabberd2 (or other options such as ejabberd) nowadays since jabberd2 is well maintained and is generally a suitable replacement for jabberd, Also, jabberd hasn't had much development in years from what I've seen. Unfortunately, no one has bumped jabberd2 in the tree for a while so there are a few bugs open for it. Tim pgp6jL6vtESwL.pgp Description: PGP signature
Re: [gentoo-dev] New License: FreeBSD License
On 2012-03-28 Wed 17:31, Richard Yao wrote: > > Gentoo/FreeBSD is currently using the BSD license, but it seems that > > this is not the license used by the BSD project: > > http://www.freebsd.org/copyright/freebsd-license.html > > In particular, the FreeBSD license removes the third clause and appends > > "The views and conclusions contained in the software and documentation > > are those of the authors and should not be interpreted as representing > > official policies, either expressed or implied, of the FreeBSD Project." > > For comparison, here is a link to the BSD license in portage: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/licenses/BSD?view=markup > > Does anyone have any objections to committing the FreeBSD license to > > portage? > As a small correction, I meant to say the FreeBSD project, not the BSD > project. Isn't this just a slightly modified version of the BSD-2 license in the tree? Tim pgpZMWgKetNqA.pgp Description: PGP signature
Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies
On 2012-03-12 Mon 10:54, Nathan Phillip Brink wrote: > > > # Samuli Suominen (12 Mar 2012) > > > # Severely broken wrt bugs #179178, #331181, #334835, #350059, > > > # #372839, #380155, #380627, #381055, #383515, #383553, #384687, > > > # and #403399. Search bugzilla with keyword lilypond. Nothing > > > # left in tree that builds. Removal in 30 days. > > > > > media-sound/denemo > > > media-sound/frescobaldi > > > > > > # Samuli Suominen (12 Mar 2012) > > > # media-sound/lilypond required for this is masked in ../package.mask > > > # for removal > > > app-text/asciidoc test > > > > > Just curious, but is there no one interested in this, lilypond, > > package anymore? The latest stable is 2.14.2 and the project is pretty > > active. Seems like a shame to get rid of it entirely. > I myself am quite interested in lilypond. I only use it occasionally > and am still a novice at it, but I like the typesetting it does. > Maybe next week I can find time to attack some of these bugs and > rescue it, unless if someone more qualified or with more time is > interested... For those not following #gentoo-dev, I already said I'd take over maintainership since I've been using it an overlay for years. Anyone is free to help close bugs and co-maintain it if they wish. Tim pgpnJL6RZXo86.pgp Description: PGP signature
Re: [gentoo-dev] making the stable tree more up-to-date
On 2011-12-16 Fri 06:05, Andreas K. Huettel wrote: > > That said, there is probably room for debate over the length of time > > we leave the bug open. Maybe a week isn't quite long enough - maybe > > two weeks is better. When you do timeout a bug and assign it to arches, it would be great if you could assign it to *all* previously stable arches, not just x86 and amd64. I've reopened a few timed out bugs to add missing arches so arch teams can either drop keywords or stabilize. That way the tree as a whole can slowly improve rather then just letting x86/amd64 rocket ahead while having to keep all the old and often deprecated packages around anyway for all the other stable arches. Thanks, Tim pgpGkmAd7Lu1Y.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due vanquirius retirement
On 2011-11-22 Tue 10:22, Pacho Ramos wrote: > Due vanquirius retirement the following packages need a new maintainer: > app-backup/duplicity I'll take this. Tim pgp7K4m0SJrjq.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due ricmm retirement
On 2011-11-22 Tue 10:46, Pacho Ramos wrote: > Due ricmm retirement the following packages need a new maintainer: > dev-util/scanmem I'll take this. Tim pgpdQO0pOMuR7.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs: virtual/{cron,dev-manager,inetd,libc,linux-sources,man,os-headers,package-manager,skkserv,ssh,w3m}
On 2011-09-22 Thu 01:53, Ulrich Mueller wrote: > In the course of the old-style to new-style transition of virtuals, > I had taken maintainership of several new-style virtual packages. > After several months have passed without any bugs showing up, I > believe it's time that I drop maintainership of these: >virtual/cron >virtual/dev-manager >virtual/inetd >virtual/libc >virtual/linux-sources >virtual/man >virtual/os-headers >virtual/package-manager >virtual/skkserv >virtual/ssh >virtual/w3m > As these are virtuals, I won't expect that there will be much > maintenance required. Also, all of them will fall back to (at least) > one herd. Please check the respective metadata.xml files for details. Personally I don't see why all of these need specific maintainers beyond the herds they fall under already, especially if they are very low maintenance. Tim pgpg6mqzHx5D1.pgp Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due tanderson retirement
On 2011-09-13 Tue 11:31, Pacho Ramos wrote: > Due tanderson retirement the following packages need a new maintainer: > dev-libs/stfl I'll take this since newsbeuter depends on it. Tim pgpx5yj9g9A9m.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Implicit system dependencies
On 2011-08-24 Wed 00:21, Diego Elio Pettenò wrote: > Il giorno mar, 23/08/2011 alle 23.52 -0700, Tim Harder ha scritto: > > I thought xz-utils can be assumed as well since it was added to the > > system set almost six months ago [1]. > It has really very little to do with being in the system set or not. And > the answer is no, you cannot assume that... So then why do bzip2 and gzip get special exceptions? Majority rule? :) Anyway, I think getting implicit unpack depends based on SRC_URI suffixes like Mike mentioned will be great. Tim pgpG153mkT8f5.pgp Description: PGP signature
Re: [gentoo-dev] Re: Implicit system dependencies
On 2011-08-23 Tue 12:12, Mike Frysinger wrote: > assuming you're referring to them because the SRC_URI is compressed by the > relevant formats, atm only bzip2 and gzip is allowed to be assumed. > everything else has to be in DEPEND. there is work/discussion to automate > this (implicit unpack depends based on SRC_URI suffixes). I thought xz-utils can be assumed as well since it was added to the system set almost six months ago [1]. Tim [1]: http://archives.gentoo.org/gentoo-dev/msg_998b4e7fdf578346bb5cfc66be340f7d.xml pgpar3hDzxWgS.pgp Description: PGP signature
Re: [gentoo-dev] About merging "mms" and "libmms" USE flags
On 2011-07-06 Wed 03:24, Pacho Ramos wrote: > Maybe they should be merged on a unique USE flag (probably "mms" as it's > usually more recognizable due being needed when trying to play mms:// > streams) and, probably, converted to a global USE flag. > What do you think? As the current, primary maintainer of (lib)mediainfo I'm fine with switching them to use the mms flag and making that global. If you want to do the work, feel free to update the (lib)mediainfo ebuilds. :) Thanks, Tim pgp20voJTgxLy.pgp Description: PGP signature
[gentoo-dev] automated testing framework for Gentoo on Supercell at the OSL
Hi all, Is anyone interested in getting some type of automated Gentoo testing framework setup on the new Supercell infrastructure [1] at the OSUOSL? In a nutshell, Supercell allows projects to spin up their own VMs on demand using Ganeti Web Manager [2]. For those who don't know, a lot of infrastructure at the OSL runs on Gentoo (including Supercell) and there are two Gentoo devs working full-time for the OSL so I think we have a good chance of getting access to some of Supercell's resources if we can come up with a decent proposal and submit a feedback form [3]. Tim [1] http://supercell.osuosl.org/ [2] http://code.osuosl.org/projects/ganeti-webmgr [3] http://supercell.osuosl.org/feedback
[gentoo-dev] Adding postfix-2.8 experimental releases to the tree
Hi all, For those of you running postfix, I was wondering if there is any interest in having the 2.8 experimental releases added to the tree. According to upstream [1] they are production quality so they should run as expected but the config setup may change a lot compared to the final release. Anyway, I'm considering adding them, masked of course, if there is interest in using them for testing purposes. Thanks, Tim [1] http://www.tigertech.net/mirrors/postfix-release/index.html
