Re: [gentoo-dev] News Item: LastPass package migration

On 08/05/16 16:56, Andrew Udvare wrote: > On 07/05/16 22:25, Göktürk Yüksek wrote: >> Users of Chrome/Chromium and Opera browsers need to switch to >> app-admin/lastpass-binary-features and follow the instructions >> displayed on the screen after the installation to complete

Re: [gentoo-dev] News Item: LastPass package migration

On 07/05/16 22:25, Göktürk Yüksek wrote: > Users of Chrome/Chromium and Opera browsers need to switch to > app-admin/lastpass-binary-features and follow the instructions > displayed on the screen after the installation to complete the process. > For Chromium, is there supposed to be a plugin liste

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

On 20/04/16 12:58, Ian Stakenvicius wrote: > On 20/04/16 03:41 PM, Anthony G. Basile wrote: >>> According to 'file' the binary format is actually "PE32 executable >>> (console) Intel 80386, for MS Windows" for a random *.exe file in my >>> /usr/i686-w64-mingw32/usr/bin That is because Mingw is for

Re: [gentoo-dev] New desktop environment: Lumina

Is Lumina built on Qt 4/5? They are obviously taking icons from KDE 4. I might give this a try. Andrew

Re: [gentoo-dev] Google API Go Client packages; slotting?

On 21/03/16 02:27, Zac Medico wrote: > Yeah, I know. Anyway, I went ahead and packaged it. Please try it out > and file bugs if there's anything wrong: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f2ebd6535d66e0ba011c1a1beeb33df570dcff8d > Works well, except on hardened I get this: d

Re: [gentoo-dev] Google API Go Client packages; slotting?

On 21/03/16 00:05, Zac Medico wrote: > On 03/20/2016 11:45 PM, Andrew Udvare wrote: >> https://github.com/google/google-api-go-client/ >> >> Looking at these to generate ebuilds for (with a script and GitHub API). >> There might be an issue with assuming versions supers

[gentoo-dev] Google API Go Client packages; slotting?

https://github.com/google/google-api-go-client/ Looking at these to generate ebuilds for (with a script and GitHub API). There might be an issue with assuming versions supersede (otherwise why would they keep multiple versions up?). I think slotting may be the real solution to that. Is that ugly?

Re: [gentoo-dev] [Proposal] Eclass for nodejs modules

On 29/02/16 03:23, Geaaru wrote: > > In conclusion, it seems that is not accepted use of nodejs modules > ebuild inside portage. It is right? > > There used to be a CoffeeScript ebuild if you search back. I do not remember how it worked but IIRC I think it was basically just creating a fake root

Re: [gentoo-dev] [Proposal] Eclass for nodejs modules

> On 2016-02-29, at 01:38, Geaaru wrote: > > Hi guys, > > I create an eclass that permit to create ebuild for nodejs modules > without define every times ebuild phases and avoid install of > dependencies already present on system. > My mission is create a module like perl-gpan that permit of cr

Re: [gentoo-dev] [RFC] Wine Project

> On 2015-12-31, at 17:03, NP-Hardass wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Mostly just a formality... > > Firing off an email RFC for the Wine Project[1]. The only purpose of > this project is to maintain Wine and Wine related packages, taking over > the place of t

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

> On 2015-10-14, at 23:39, Mike Frysinger wrote: > > iputils is currently in @system for everyone. by default, it only > installs `ping`. do we feel strongly enough about this to require > all systems include it ? or should this wait for the long idea of > releasing stage4's instead of stage3

Re: [gentoo-dev] Re: Better way to direct upstream bugs upstream?

On 03/09/15 04:28, Kent Fredric wrote: > Or for instance, when GMail overhauled their email service, despite > the pleas of developers to have a "Don't top-post by default" toggle > in the settings, the whole developer community was deemed unimportant > and that such a feature could never happen.

Re: [gentoo-dev] How to correctly use golang-vcs with the Google API libraries?

On 26/08/15 12:41, William Hubbs wrote: > On Mon, Aug 24, 2015 at 05:35:39PM -0700, Andrew Udvare wrote: > > Let me know what you think about how we could automate it. I think > we'll have to manually create the ebuilds. It appears they either use GitHub as the official place

[gentoo-dev] How to correctly use golang-vcs with the Google API libraries?

To correctly support the entire Google API library set, do we need a separate ebuild for every single one? This definitely can be automated. https://godoc.org/google.golang.org/api With golang-vcs, using google.golang.org/api for GO_PN is not working and I think it is because each package must be

Re: [gentoo-dev] NPM / NodeJS project

> On 2015-06-28, at 09:30, Michael Orlitzky wrote: > > https://github.com/orlitzky/npm We don't > have any standalone javascript packages in the tree at the > moment but I know there's been some interest before. Is anyone still > (planning on) working on javasc

Re: [gentoo-dev] new eclass: golang.eclass for compiling go packages

> On 2015-06-11, at 08:38, William Hubbs wrote: > > this eclass is meant to provide a common src_compile function for > packages written in the Go programming language. > > Let me know what you think. > I am wondering about bug 503324 and the issue of needing to create a GOROOT with everythi

Re: [gentoo-dev] Re: [OT] Re: Re: RFC: Indention in metadata.xml

On 07/06/15 18:54, Allan Wegan wrote: >> [1] Of course, 320x108 chars /is/ with a 42-inch TV as a monitor, but >> it's not exactly tiny print, either. I sit farther away from it than >> many people sit from their monitor. But even half of that is 160 >> chars width, which is what I used to use on

Re: [gentoo-dev] RFC: Indention in metadata.xml

On 07/06/15 05:12, Alexis Ballier wrote: > On Sat, 6 Jun 2015 22:00:14 -0400 > Mike Gilbert wrote: > >> Compatibility with sed scripts is not something I care about. > > and is something nobody should care about: xml is not a regular > language :) > If you are enforcing split lines on every si

Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds

> On 2015-06-04, at 12:10, William Hubbs wrote: > > All, > > we are starting to get more go packages in the tree, so we need an > eclass that properly deals with go live ebuilds. Why live only? Your eclass does what every other live and non-live ebuild does for Go: create a temporary Go envi

Re: [gentoo-dev] New basic systemd profile

> On 2015-05-01, at 08:28, Mike Gilbert wrote: > > Due to popular demand, I have added a basic systemd profile for amd64: > > default/linux/amd64/13.0/systemd > > Previously, the systemd profile was only available in combination with > gnome or kde. This new profile will make it easier for use