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
# Tim Harder radher...@gentoo.org (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
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
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
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
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
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
On 2012-03-12 Mon 10:54, Nathan Phillip Brink wrote:
# Samuli Suominen ssuomi...@gentoo.org (12 Mar 2012)
# Severely broken wrt bugs #179178, #331181, #334835, #350059,
# #372839, #380155, #380627, #381055, #383515, #383553, #384687,
# and #403399. Search bugzilla with keyword
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
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
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}
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.
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
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
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
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
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
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
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
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
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
On 2013-12-23 08:01, Pacho Ramos wrote:
sys-process/cronutils
I'll maintain this.
Tim
pgptQxCZkO57Z.pgp
Description: PGP signature
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]:
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
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
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
# Tim Harder radher...@gentoo.org (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
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
On 2014-09-14 10:46, Michał Górny wrote:
Dnia 2014-09-14, o godz. 15:40:06
Davide Pesavento p...@gentoo.org 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
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
# Tim Harder radher...@gentoo.org (25 Oct 2014)
# Upstream migrated to nose for testing instead of their own framework
# Tim Harder radher...@gentoo.org (25 Oct 2014)
# Deprecated project, devwlopment continues in dev-util/cmocka
# Tim Harder radher...@gentoo.org (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
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
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
On 2014-11-23 20:17, hasufell wrote:
dev-python/jedi
I'll help maintain this.
Tim
pgpeY1d3cCgA7.pgp
Description: PGP signature
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.
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
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
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
On 2015-01-17 23:48, Zac Medico wrote:
Actually, Arfrever tells me that the multiprocessing module is not
available if python is built without threading support. So, we need to
handle the ImportError and either do nothing or parse /proc/cpuinfo or
something like that.
Feel free to
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 patr...@gentoo.org wrote:
* AutoRepoman catches on average maybe 2 user-visible breakages.
Mostly removing stable on HPPA ;)
Fix: Make repoman
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
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
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
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
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
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
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
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
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
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
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
On 2015-11-11 14:42, Zac Medico wrote:
> Please unset all new internal function inside bin/save-ebuild-env.sh.
> Note that it already uses this line to unset functions beginning with
> ___eapi:
>unset -f $(compgen -A function ___eapi_)
> However, your __eapi functions will not be matched
On 2015-11-12 21:25, Zac Medico wrote:
> > Just to note another approach, pkgcore generates global and per-eapi
> > function lists at install time (or uses the generation scripts when
> > running from a checkout) so manually tracking lists of functions isn't
> > required.
> That seems like a
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
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.
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
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
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
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 <
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
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
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
# Tim Harder <radher...@gentoo.org> (05 Feb 2018)
# Unmaintained, replaced by newsboat fork.
# Masked for removal in 30 days.
net-news/newsbeuter
signature.asc
Description: PGP signature
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
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
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
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
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)
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
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
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
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
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,
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
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
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
>
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
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
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
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
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
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
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
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
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 collect
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
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
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
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
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
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
93 matches
Mail list logo
