On 2025-03-30 Sun 02:11, Michael Mair-Keimberger wrote:
I guess i'm a bit late in this discussion but i wanted to let you know
this would also affect my gentoo qa scripts.
(https://gentooqa.levelnine.at). Right now i'm checking the gentoo,
guru, kde, science and pentoo repositories, syncing the
Hi all,
I've been working for a while on pkgcraft[1] and related tooling that
could have the potential to run various CI checks server-side as a
pre-receive git hook verifying commits. Previously, this wasn't at all
possible due to portage/repoman and pkgcore/pkgcheck being too slow to
feasibly r
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 standard
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
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 as
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 mi
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 packa
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 simpl
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
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
> int
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
initiall
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
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-actio
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 du
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
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 in
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
> StableRequestChec
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
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 fo
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 rem
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 figur
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
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
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 prac
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 the
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 (
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) s
# Tim Harder (05 Feb 2018)
# Unmaintained, replaced by newsboat fork.
# Masked for removal in 30 days.
net-news/newsbeuter
signature.asc
Description: PGP signature
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
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 el
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
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
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 ch
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 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
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 pink
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 an
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 l
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 to
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
D
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 rat
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
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 pkgco
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-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
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 ar
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 n
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 ce
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
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 fast
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 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
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-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 lovel
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-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
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
# 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
# Tim Harder (25 Oct 2014)
# Deprecated project, devwlopment continues in dev-util/cmocka
# Tim Harder (25 Oct 2014)
# Upstream migrated to nose for testing instead of their own framework
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 signific
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
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 gam
# 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
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 thi
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 re
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
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/ft
On 2013-12-23 08:01, Pacho Ramos wrote:
> sys-process/cronutils
I'll maintain this.
Tim
pgptQxCZkO57Z.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 ea
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-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
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-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
# 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
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
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}
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 k
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 app
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
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
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-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-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
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-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
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-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 mai
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 infrast
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.
A
93 matches
Mail list logo
