[gentoo-dev] x11-plugins/pidgin-sipe: Maintainer Needed
Ive dropped myself as maintainer on x11-plugins/pidgin-sipe, leaving it as maintainer needed. It has a few open bugs, nothing serious. If you are a poor soul who still uses Skype For Business access, please pick it up. x11-plugins/pidgin-sipe Cheers, Ian -- Ian Whyman gentoo.org
Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-misc/openssh/
On Wed, 10 Jan 2018, at 12:52 PM, Michał Górny wrote:
> W dniu śro, 10.01.2018 o godzinie 08∶35 +, użytkownik Mike Frysinger
> napisał:
> > commit: e65003579e31be4ff949cfa66df2511ecd4c44a0
> > Author: Mike Frysinger gentoo org>
> > AuthorDate: Wed Jan 10 08:28:35 2018 +
> > Commit: Mike Frysinger gentoo org>
> > CommitDate: Wed Jan 10 08:34:18 2018 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e6500357
> >
> > net-misc/openssh: mark 7.5_p1-r3 m68k/s390/sh stable
> >
> > net-misc/openssh/openssh-7.5_p1-r3.ebuild | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > index 83dcb1db429..1f173bc6211 100644
> > --- a/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > +++ b/net-misc/openssh/openssh-7.5_p1-r3.ebuild
> > @@ -25,7 +25,7 @@ SRC_URI="mirror://openbsd/OpenSSH/portable/${PARCH}.tar.gz
> >
> > LICENSE="BSD GPL-2"
> > SLOT="0"
> > -KEYWORDS="alpha amd64 arm arm64 hppa ia64 ~m68k ~mips ppc ppc64 ~s390 ~sh
> > sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
> > ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos
> > ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
> > +KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 s390 sh
> > sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~sparc-fbsd ~x86-fbsd
> > ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos
> > ~m68k-mint ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
> > # Probably want to drop ssl defaulting to on in a future version.
> > IUSE="abi_mips_n32 audit bindist debug ${HPN_PATCH:++}hpn kerberos
> > kernel_linux ldap ldns libedit libressl livecd pam +pie sctp selinux skey
> > ssh1 +ssl static test X X509"
> > REQUIRED_USE="ldns? ( ssl )
> >
>
> This package has unkeyworded arm64 deps, so you've effectively
> introduced new depgraph breakage here:
>
> https://qa-reports.gentoo.org/output/gentoo-ci/b4c5efa7f/output.html#net-misc/openssh
>
> Please take care to do things properly, and stabilize dependencies
> *before* adding stable keywords to a package. Using repoman would also
> be appreciated.
>
> --
> Best regards,
> Michał Górny
>
As broken as this seems to be, I'm not sure why you chose Mike's commit to
reply to here, as clearly he didn't change the ARM64 keywords in this diff...
Cheers,
Ian
[gentoo-dev] Last rites: net-misc/mediatomb
# Ian Whyman (04 Dec 2017) # Declared dead upstream. Masked for removal in 30 days # Please see net-misc/gerbera for a replacement. net-misc/mediatomb
Re: [gentoo-dev] [warning] the bug queue has 85 bugs
On 9 January 2017 at 22:00, Alex Alexander wrote: > Our bug queue has 85 bugs! > > If you have some spare time, please help assign/sort a few bugs. > > To view the bug queue, click here: http://bit.ly/m8PQS5 > > Thanks! I'm almost certain this has been asked before but... As gentoo-bot can ping me when my packages have Github PRs opened against them, can we not get something set up to assign bugs automatically, at least for the "easy" stuff. There is a chance this has already been set up - and its not on by default because someone may get a rogue bug assigned once in a while - in which case how do I opt in? I am happy to reassign if the bot gets it wrong once in a while. Cheers! Ian
Re: [gentoo-dev] Referencing bug reports in git (WAS: Re: [gentoo-commits] repo/gentoo:master commit in: sci-libs/opencascade/)
On 9 August 2015 at 15:09, hasufell wrote: > On 08/09/2015 03:58 PM, Michael Weber wrote: > > commit: 40b3fd64ec9c5d6d94f0f0897740bc77622c24a1 > > Author: Michael Weber gentoo org> > > AuthorDate: Sun Aug 9 13:58:26 2015 + > > Commit: Michael Weber gentoo org> > > CommitDate: Sun Aug 9 13:58:26 2015 + > > URL: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40b3fd64 > > > > sci-libs/opencascade: add USE=vtk (bug 557022, thanks Helmut Jarausch). > > > > I was wondering if we should set a standard for referencing bug reports. > The portage team already does something like that: > > https://github.com/gentoo/portage/commit/b7149002bf23889f280c502afe6ceda0b1345ca3 > > Following that, the commit could have been: > = > sci-libs/opencascade: add USE=vtk > > thanks to Helmut Jarausch > > X-Gentoo-Bug: 557022 > X-Gentoo-Bug-url: https://bugs.gentoo.org/show_bug.cgi?id=557022 > = > > Having the URL and number seems like a duplication of effort, but X-Gentoo-Bug works for me. -- Ian Whyman www.gentoo.org
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-video/handbrake/files/, media-video/handbrake/
On 9 August 2015 at 15:01, hasufell wrote: > On 08/09/2015 03:43 PM, Ian Whyman wrote: > > commit: b8f141afeb0e183298fe227672ac9338e0e8e12c > > Author: Ian Whyman gentoo org> > > AuthorDate: Sun Aug 9 12:30:22 2015 +0000 > > Commit: Ian Whyman gentoo org> > > CommitDate: Sun Aug 9 13:43:25 2015 + > > URL: > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b8f141af > > > > media-video/handbrake: Version Bump to 0.10.2, enable x265, tidyup > > > > - Version bump to 0.10.2 > > - Cleanup of old versions and patches > > - Enable x265: thanks to Peter Foley pefoley.com> > > for the patch > > > > Signed-off-by: Ian Whyman gentoo.org> > > > > Package-Manager: portage-2.2.20 > > > > > https://wiki.gentoo.org/wiki/Gentoo_git_workflow#atomicity > > > don't do version bumps and ebuild cleanup in one commit (makes > reverting ebuild removals more difficult) > Yeah, sorry about that, as I mentioned on IRC, didn't read the whole page before committing, it is rather a wall of bullet points. -- Ian Whyman www.gentoo.org
Re: [gentoo-dev] Re: ffmpeg vs libav choice of default
On 8 February 2015 at 03:20, Jason A. Donenfeld wrote: > The votes keep pouring in. Ffmpeg is the preference of Gentoo users, as well > as the majority of Gentoo developers, and by a very relevant upstream > author. I don't think a forum poll, or a poll of users for that matter is great way to build a distribution, in fact it may be very worst way I can think of. I wouldn't like to comment of the preferences of my fellow developers, but I might suggest to put this to bed with a vote. With regards to packages both Gstreamer and Handbrake upstreams prefer libav, though again I don't think that is great way to pick. So long as libav is effectively dictating the API then by defaulting to ffmpeg we are just delaying the inevitable breakage htting the tree. I know there are people who think we shouldn't break unstable, but I personally prefer a faster moving model with an amount of breakage. -- Ian Whyman www.gentoo.org
Re: [gentoo-dev] net-p2p/deluge needs a maintainer
I will help out with this package as well if needed. On 31 Mar 2013 13:10, "Markos Chandras" wrote: > On 31 March 2013 12:23, Rich Freeman wrote: > > On Sun, Mar 31, 2013 at 7:01 AM, Markos Chandras > wrote: > >> Hi, > >> > >> net-p2p/deluge has open bugs for years[1] and I don't see anybody from > >> the net-p2p herd > >> to actually maintain it. It would be nice to find a new dedicated > >> maintainer for it. If a user is interested in helping us maintain it, > >> please contact proxy-maint_at_gentoo_dot_org[2]. > > > > I'll potentially grab this one, though proxy maintainers are still > > welcome (especially if you run it under openrc and would like to fix > > some of the init.d bugs, as I do not due to its tendency to crash). > > > > Thanks for calling for help prior to treecleaning... > > > > Rich > > > > If a user wants to help, proxy-maintainers will also join you. I don't > want to treeclean this package as it > seems to have a large user base so there are chances for people to > step up and maintain it. > > -- > Regards, > Markos Chandras - Gentoo Linux Developer > http://dev.gentoo.org/~hwoarang > >
Re: Discussing defaults (Was: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild)
Guys, Can we not just have a developer wide vote or something? This instance clearly not going to resole itself. Sometimes it seems that endless mailing list threads are the Gentoo way, its a surprise we get anything done! Ian
Re: [gentoo-dev] !!! ERROR !!!
> !!! ERROR !!! SYSTEM ERROR !!! SYSTEM FAIL !!! Yikes. I didn't touch anything, honest!
Re: [gentoo-dev] RFC: new "qt" category
Much nicer naming IMHO. +1 from me.
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
> In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. > > In that case we should go forward and add these kind of policies to the devmanual. +1 from me
Re: [gentoo-dev] Github.com tarballs eclass idea
On 11 June 2012 14:41, Michael Weber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi folks,
>
> i've some packages fetching SRC_URI from github.com
> tarballs/tags/files like x11-misc/trayer-srg.
>
> Fortunately, github.com provides (mostly) stable tarballs that are fit
> for manifestations (file sizes and checksums don't change).
> There is no need to create/host tarballs to be picked up by mirrors.
>
> Unfortunately, these tarballs contain $author-$repository-$commitidabrev
> (e.g. sargon-trayer-srg-5353f80) ad top directory.
>
> One approach is to define ${S} to match these additional data, but to
> easy version bumps, I've started to rename the extracted directory
> within src_unpack, to avoid mentioning the $author, $commitid and
> modifying ${S}.
>
> """
> SRC_URI="https://github.com/sargon/${PN}/tarball/${P/-srg/} ->
> ${P}.tar.gz"
>
> src_unpack() {
> unpack ${A}
> mv *-${PN}-* ${P} || die
> }
> """
>
> I wonder if others have similar workarounds?
>
> And does this src_unpack qualify for an eclass or being added to an
> existing one, to avoid code replication?
>
> Maybe fetch filename " -> ${P}.tar.gz" can be mangled into SRC_URI by
> this eclass/function, too.
>
> Michael
>
> - --
> Gentoo Dev
> http://xmw.de/
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk/V9YwACgkQknrdDGLu8JBbzgD/aZ0USZEnfa2bQaoHOjKglMN/
> BJHuAOv0At95B4ARSXkA/A79qARFSCCAryjv55A1f6+3LafaRJlP0QKLp+zHoKvq
> =W1YG
> -END PGP SIGNATURE-
>
This sounds like what the vcs-snapshot[1] eclass is for?
1 . http://devmanual.gentoo.org/eclass-reference/vcs-snapshot.eclass/index.html
--
Ian Whyman
www.gentoo.org
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On May 23, 2012 1:55 PM, "Johannes Huber" wrote: > > Am Mittwoch 23 Mai 2012, 14:42:37 schrieb Michael Weber: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > Hi, > > > > > > i've looked at the blockers of "[TRACKER] portage migration to git" > > > [1] and want to discuss "testing git-cvsserver" [2]. > > > > > > There are two proposed scenarios how to migrate the developers write > > > access to the portage tree. > > > > > > "Clean cut" turns of cvs access on a given and announced timestamp, > > > rsync-generation/updates is suspended (no input -> no changes), some > > > magic scripts prepare the git repo (according to [3], some hours > > > duration) and we all checkout the tree (might be some funny massive load). > > > > > > "testing git-cvsserver" proses "Clean cut" with the additional ability > > > to continue using cvs update/commit, - in best case - on the old > > > checkout w/o alteration on the developers side. > > > > > > "Clean cut" forces us to clean up out dirty checkouts (I have some > > > added directories, added ebuilds i hesitated to `repoman commit`). > > > Plus we have to alter all our hot-wired portage mangling scripts from > > > cvs'ish to git'ish (I use my read/write checkout as portage tree (cvs > > > checkout + egencache for checkout) and have an automated google-chrome > > > bump script). But this can be accomplished on a per developer basis, > > > and slackers don't stall the process. > > > > > > "testing git-cvsserver" forces us all to test these cvs'ish scripts > > > and behaviours against a git-cvsserver and report. > > > We all know that this test-runs will never happen, stalling this bug > > > till infinity. > > > Plus infra/"subset of devs marshalling the migration" get stuck > > > between fixing git issues and git-cvsserver. > > > > > > *if you still read this* *wow* > > > > > > Please discuss my arguments and come to the conclusions to > > > RESO/WONT-FIX "testing git-cvsserver", make a "clean cut" and remove > > > this bug from the blockers of "[TRACKER] portage migration to git". > > > > > > My lengthy 2 cents. > > > > > > [1] https://bugs.gentoo.org/333531 > > > [2] https://bugs.gentoo.org/333699 > > > [3] https://bugs.gentoo.org/333705#c2 > > > - -- > > > Gentoo Dev > > > http://xmw.de/ > > > -BEGIN PGP SIGNATURE- > > > Version: GnuPG v2.0.17 (GNU/Linux) > > > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > > > > > iF4EAREIAAYFAk+82z0ACgkQknrdDGLu8JBUWAD/dmuqyES/mYDrMam+/txnHmgd > > > VaQaqwHMlwzzqQwbpY4A/0h+5Vp8sLbOE78k4SCaGE2dCQtmeOz0jd1YxkDzP+YW > > > =jXLQ > > > -END PGP SIGNATURE- > > > > I support RESOLUTION WONTFIX, if nobody cares about the bug since it was opened it is obvious out of interest. There is no reason to support jurassic software. > > > > Clean cut++ > > > > Cheers > > -- > > Johannes Huber (johu) > > Gentoo Linux Developer / KDE Team > > GPG Key ID F3CFD2BD > > Another vote for clean cut from me.
Re: [gentoo-dev] rfc: location of portage tree
> Just use categories from repos? I've always thought splitting distfiles by category would make a huge amount of sense.
Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token
On 27 March 2012 08:33, Dirkjan Ochtman wrote: > On Mon, Mar 26, 2012 at 20:44, Alec Warner wrote: >>> Long term, we may want to consider porting pybugz to use Bugzilla's >>> XML-RPC api to avoid such breakage. >> >> XML-RPC is shit. > > https://wiki.mozilla.org/Bugzilla:REST_API > Shame that it requires custom patches to BZ, personally I think the preferable (and offically supported) method would be JSON-RPC[1] Ian 1.http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService/Server/JSONRPC.html
