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

[Andrew Udvare]

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 the process.
>>
> For Chromium, is there supposed to be a plugin listed in
> chrome://plugins after installation? Supposedly I enabled native
> messaging for the plugin but nothing for LastPass is listed at
> chrome://plugins.
> 
> Andrew
> 
Actually I think I got it. Once you do everything correctly, and you go to

chrome://extensions/?options=hdokiejnpimakedhajhdlcegeplioahd (LastPass
extension options)

under 'Advanced', you will not see a link to install the binary
component anymore.

Andrew



signature.asc
Description: OpenPGP digital signature

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

[Andrew Udvare]

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 listed in
chrome://plugins after installation? Supposedly I enabled native
messaging for the plugin but nothing for LastPass is listed at
chrome://plugins.

Andrew



signature.asc
Description: OpenPGP digital signature

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

[Andrew Udvare]

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 making native executables for Windows, not
ELF files. I do not recall Gentoo Prefix supporting Mingw in a
meaningful way (it supports Cygwin IIRC). It sounds like a bit of work,
but I sure would like to see it. The problem is still that on Windows,
cmd is terrible and mintty only gives a partial solution to having such
bad terminals. Viability seems very low as every one who uses Mingw
seems to have mostly their own undocumented ways to get things to work.
You can find this pattern among many open source projects.

>> yes and while it is reported by `file` as PE32, it is sometimes referred
>> to as just win32.  its proper name, if i recall correctly is "Win32
>> Portable Executable File Format".  it is the equivalent of ELF, COFF and
>> a.out in the Linux world and Mach-O in the Mac world.  basically its the
>> format the linker/loader is looking for.

PE is essentially COFF with extensions applied. On top of that PE+ came
around the time of Windows Vista, and the format is not readable by
prior Windows versions like XP. Interestingly, even on a non-x86
platform the file will still have the MS-DOS stub (you can see this in
an XEX for Xbox 360).

Realistically, you only need to call it PE since XP is so dead.

>> with gentoo portage in there, i think
>> we'll expand in to a whole new market.

It is not easy. Ubuntu has always had trouble with Gentoo Prefix due to
a 'broken' toolchain that is kind of Debian-specific. A Debian-specific
bootstrap has to be made for this to work.

Andrew



signature.asc
Description: OpenPGP digital signature

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

[Andrew Udvare]

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?

[Andrew Udvare]

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:

drive: error while loading shared libraries: cannot make segment
writable for relocation: Permission denied

strace output:

execve("/usr/bin/drive", ["drive"], [/* 59 vars */]) = 0
brk(0)  = 0x1b63e83750
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x3d6f913c000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=82250, ...}) = 0
mmap(NULL, 82250, PROT_READ, MAP_PRIVATE, 3, 0) = 0x3d6f911d000
close(3)= 0
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360`\0\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=133656, ...}) = 0
mmap(NULL, 2212496, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x3d6f8cf5000
mprotect(0x3d6f8d0d000, 2093056, PROT_NONE) = 0
mmap(0x3d6f8f0c000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x3d6f8f0c000
mmap(0x3d6f8f0e000, 12944, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3d6f8f0e000
close(3)= 0
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\v\2\0\0\0\0\0"...,
832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1730032, ...}) = 0
mmap(NULL, 3838936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0x3d6f8945000
mprotect(0x3d6f8ae5000, 2093056, PROT_NONE) = 0
mmap(0x3d6f8ce4000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19f000) = 0x3d6f8ce4000
mmap(0x3d6f8cea000, 17368, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3d6f8cea000
close(3)= 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x3d6f913b000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x3d6f9135000
arch_prctl(ARCH_SET_FS, 0x3d6f9135740)  = 0
mprotect(0x3d6f8ce4000, 16384, PROT_READ) = 0
mprotect(0x3d6f8f0c000, 4096, PROT_READ) = 0

mprotect(0x1b617f6000, 12369920, PROT_READ|PROT_WRITE) = -1 EACCES
(Permission denied)

writev(2, [{"drive", 5}, {": ", 2}, {"error while loading shared
libra"..., 36}, {": ", 2}, {"", 0}, {"", 0}, {"cannot make segment
writable for"..., 43}, {": ", 2}, {"Permission denied", 17}, {"\n", 1}],
10drive: error while loading shared libraries: cannot make segment
writable for relocation: Permission denied
) = 108
exit_group(127) = ?
+++ exited with 127 +++

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

[Andrew Udvare]

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 supersede (otherwise why
>> would they keep multiple versions up?).
> 
> Can you clarify which versions you're talking about? We shouldn't slot
> it if the new versions are backward compatible.

The version numbers are the packages like:

google.golang.org/api/adexchangebuyer/v1.2
google.golang.org/api/adexchangebuyer/v1.3
google.golang.org/api/adexchangebuyer/v1.4

I was thinking to make something like:

dev-go/go-google-api-adexchangebuyer1.2
dev-go/go-google-api-adexchangebuyer1.3
dev-go/go-google-api-adexchangebuyer1.4

Then of course slotting seems valid so the version suffix can go away,
if these are not compatible.

> Only slot if the new version is not backward compatible.

I agree on this slotting policy. It definitely is a bit hard to tell if
they are backward compatible in an automated fashion.

I think these may be compatible in many cases, however even though some
things may remain the same between versions, the API endpoint changes
with these numbers. It is hard to figure out compatibility and I think
the general assumption by developers is none.

>> Currently I'm re-wrapping https://github.com/odeke-em/drive (I had done
>> this before when there were no Go helper eclasses).
> 
> Oh, that could be handy for drive users.
> 
It's a decent alternative to what was Grive. Although I have only
learned recently of the fork to fix Grive for the newer APIs (already on
Portage).

The other option on building Drive is to emulate `go get` (put itself
and all deps in SRC_URI and fix up a GOROOT to compile with). Some
packages already do this partially, like go-oauth2 which grabs other
things in SRC_URI that could be separated out.

Go is nice, but is difficult to package.

Andrew

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

[Andrew Udvare]

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? Or should multiple versions installed
never be supported?

Currently I'm re-wrapping https://github.com/odeke-em/drive (I had done
this before when there were no Go helper eclasses).

Andrew

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

[Andrew Udvare]

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 for itself. The distfile itself was just that node_modules/
directory in a tarball. No direction on how those dependencies could be
shared, so it is no longer in the tree.

Andrew

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

[Andrew Udvare]

> 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 create
> automatically all ebuilds of every dependencies (not devDependencies)
> of a particular package and npmv1 eclass if first step for this.

http://search.gmane.org/?query=nodejs&group=gmane.linux.gentoo.devel

Unfortunately the conversation has already happened and it has sort of been 
determined that the community (even worse than Go) is terrible at defining 
dependencies for a lot of projects, even major ones. Personally for ebuilds I'm 
only interested in the end user packages that often documentation says to 
install using `npm install -g` (which I never do); packages that are useful for 
command line generally. I have resorted to using nvm for a few reasons: ease of 
use, compatibility, testing, and the fact that nodejs is not slotted in the 
Portage tree. Even if Gentoo had slots for nodejs/npm, it would not make it 
easier to test against different versions the way nvm does. In particular with 
time some versions would go away before other distros upgrade.

Your eclass kind of does something, as far as i can tell, which is very 
discouraged. Line 84 shows it downloading the dependencies with npm install to 
create sort of a separate root of the package, and then you generate a script 
to launch with the correct environment variables (and yes you avoid getting 
stuff already on the system). It's like nvm but done with Portage, but for each 
package. Users are not in control of the ebuild if they cannot specify how 
things get downloaded (make.conf can customise the command). NPM_DEFAULT_OPTS 
does not document how one could add proxy options. Even if you undid the npm 
install by invoking the user's command to download the packages, it would still 
not be acceptable as packages must be able to live in distfiles. I also do not 
see what you are going to do when package1 is already installed depending on 
dep1 version 1.2 but now package2 wants to be installed wanting dep1 on version 
2.2. Automagic slotting?

> 
> ...like for perl I think that manage nodejs modules as gentoo package is more 
> clear than use directly npm features.

I kind of disagree. The current state of nodejs packaging just does not allow 
for easy external packaging except for basically what you are doing which is 
using npm install, or vendoring every package to avoid conflicts.

You must get the individual packages and set up separate ebuilds and they must 
be able to share dependencies in most cases. The problem is the contents of 
package.json is often to just get 'the latest' version of every dependency or 
extremely incompatible versions. The community is moving too quickly for 
Portage to always be up-to-date with this.

The same problem exists with Java packages that use Maven for dependency 
management. It is almost as bad as Go, but the importance of some Go packages 
(Docker) is outweighing the complexity of reverse-engineering the `go get` 
mentality of that community. They basically do not want users to not use `go 
get` if it's available. They really want users to stick to their 
language-specific package managers. As a result of the Go unpredictability with 
versions, there are plenty of projects that 'vendor' their dependencies 
including Docker.

https://gist.github.com/datagrok/8577287

In particular, Python and Ruby seem to have settled versioning a lot more. Most 
packages do not specify Git repositories @ HEAD or any strange things like 
that. Releases get made in a predictable manner for the popular packages, 
because the consumers demand stability and predictability. (Ruby is not 
non-guilty, take a look at Vagrant.)

Also line 236:

npm_pkg_mods=( $(ls --color=none node_modules/) )

This should be npm_pkg_mods=( node_modules/* ) (and then call basename on each 
when iterating).

Andrew

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

[Andrew Udvare]

> 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 the former Wine herd.

Just saying, since Wine updates relatively infrequently compared to bugs 
reported for newer apps, I would love to see more support for the patched Wine 
versions somehow.

https://github.com/wine-compholio/wine-patched in particular.

Andrew

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

[Andrew Udvare]

> 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's ?
> -mike

If I had got on a machine lacking the ping command, I would immediately install 
it and otherwise avoid that machine (it's 'broken'). It really should not get 
removed, plus it is tiny.

A lot of hosts now block ICMP requests but it's just habit for many to type 
`ping google.com` or similar to test when they suspect their internet is down.

Andrew

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

[Andrew Udvare]

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.

Chromium team is no different in this regard. No options, for anything.
It is extremely annoying when they implement 'privacy-violating'
features like the previously visited sites in the New tab (before you've
entered a URL), with no option to disable despite pleas to give that option.

Developers and other habits (perhaps not seen at Google internally) are
apparently not important. Even privacy can be compromised at times. Most
certainly Google mostly cares for those outside the organisation who
'evangelise' with the Google way of doing things.

> So now every time I reply to something, I have to fight with GMail to
> make sure I highlight the whole message manually first, making sure
> not to have my selector accidentally slip outside the email text, and
> *then* hit reply, which makes it quote it instead.

This is why I moved back to a client. Right now Thunderbird.

> 

We have nearly the same tirade. :|

Andrew

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

[Andrew Udvare]

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 to get the API
or it is a mirror. Either way, it is on GitHub so the API can be
utilised. This can be scripted more astutely but jq can be used against
the GitHub API (and no login is required; however unauthenticated users
have limits).

Example getting all the directories at the top level (uses app-misc/jq):

curl -H 'Accept: application/vnd.github.v3+json'
https://api.github.com/repos/google/google-api-go-client/contents/ | jq
-r '.[] | select(type="dir") | .name'

Once you have this, for each one you have to get the v1, v2, etc. I do
not know how that should work in Portage because I think it is very
likely one package would require v1 while another will require v2. This
would seem to indicate slotting.

An ugly example to generate GO_PN lines:

contents_uri='https://api.github.com/repos/google/google-api-go-client/contents/'
accept='Accept: application/vnd.github.v3+json'
pn_prefix=github.com/google/google-api-go-client/
jq_filter='.[] | select(.type=="dir") | .name')


for i in $(curl -H $accept "$contents_uri" | jq -r "$jq_filter"); do
versions=$(curl -H $accept "${contents_uri}${i}" | jq -r "$jq_filter")
for j in versions; do
echo "SLOT=\"${j/v/ }\""  # Remove v prefix
echo "GO_PN="${pn_prefix}${i}/${j}"
done

break # Added to not exceed the very small API limit
done

As for the actual version number for the ebuild, from the API I think
you can get the last modified date for the directory. This would be to
create a version number like some of the others: 0_pre, e.g.
0_pre20150729.

Andrew

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

[Andrew Udvare]

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 dealt with separately.

Back story:

I have an ebuild I made a while ago back when the norm was to hack up a
copy of GOROOT minus the package and build the package with that root,
then install. It is located here:

https://github.com/Tatsh/tatsh-overlay/blob/master/dev-go/google-api-go-client/google-api-go-client-0_p20150428.ebuild

I do need to update all my Go ebuilds for golang-* eclasses, not just
this one, because the old way was to install to /usr/lib/go rather than
/usr/lib/go-gentoo.

But besides that, this ebuild was only intended to fulfil the
dependencies of Odeke Drive (a Google Drive client, especially since
Grive is now dead due to API changes). You can see this in the loop that
only deals with the packages drive/v2 and googleapi. (Just to note, I
would love to see Odeke Drive in the tree as there is no longer a
working Google Drive client in the tree.)

Thanks
Andrew

Re: [gentoo-dev] NPM / NodeJS project

[Andrew Udvare]

> 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 javascript stuff in-tree?

Not in tree, but I was planning on an idea called enpm but I realised resolving 
dependencies in npm is horrible, almost as bad as the live code on building 
with Go. The only way I could see this work is to package the dependencies with 
the app in a single tarball similar to what Vagrant does now. It is not the 
Gentoo way but these new systems (gem, Composer, even Go) seem to not care very 
much about having packages you can consider stable, nor predictable 
dependencies.

I would still find it useful to install CoffeeScript (among others like 
PhantomJS) via Portage for global use. Right now I hack on ~/node_modules/.bin 
to PATH in my shell (luckily that works).

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

[Andrew Udvare]

> 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 everything except the package to be compiled. Is your way solving this 
issue?

My ebuild's src_compile() is based on ones in the tree:

https://github.com/Tatsh/tatsh-overlay/blob/master/dev-go/go-isatty/go-isatty-0_p20150408.ebuild#L31

Andrew

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

[Andrew Udvare]

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 my 21-inch.
> 
> Now 160 sounds like two perfectly legible terminals side by side with 80
> chars each. ;)
> 
> 
> 
I tend to like agreeing with others ;)

I have 2 30" monitors running KDE and I often run Konsole in a window
1280 in width but this is really to enable me to easily split tmux panes
(terminal on left, log on right). As such 80 (79 in PEP8 in Python)
characters per line makes it much easier than relying upon (usually
horrible) word wrapping.

120 is a thing I have seen but I think anything above that is pushing it
in terms of readable. Obviously there are times when you break these
rules, but most of time you can find a way not to that does not change
your code or make it less optimal (for example, splitting by assigning a
new variable just to break lines up, which could (prior to an
optimisation stage) introduce a few opcodes that were not there before).

Andrew

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

[Andrew Udvare]

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 single tag except ones that
can be shortened like , then it does not matter if you use 4
spaces or tabs. Both would be compatible with sed assuming the indenting
is correct in either case. With regard to white space within tags is
another story. The rule should still apply there and so compatibility
would remain.

However, I do not disagree an XML parser is better than sed for the
purpose. There are plenty of XML pretty printers.

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

[Andrew Udvare]

> 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 environment without the package in question. This is fine (I 
hate how Go is designed in this respect). I just think non-live Go packages 
definitely need an eclass.

Andrew

Re: [gentoo-dev] New basic systemd profile

[Andrew Udvare]

> 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 users to switch
> to systemd from an unpacked stage3 tarball.
> 
> To avoid an explosion in profiles, I will not be adding this for other
> archs at this time. I'm not opposed to it, but I also don't want to be
> responsible for making repoman that much slower.
> 

I would like to see a hardened version of this. Making a hardened Gentoo kernel 
(there is no 'systemd' option in hardened-sources menuconfig) and system with 
systemd is almost entirely undocumented. I managed to do it though.