Re: [arch-general] :D

2015-06-22 Thread Hugo Osvaldo Barrera
On 2015-06-03 13:27, Ralf Mardorf wrote:
 On Wed, 3 Jun 2015 13:04:38 +0200, Carsten Mattner wrote:
 On Tue, Jun 2, 2015 at 4:28 AM, Ralf Mardorf wrote:  
  $ cat /etc/pacman.conf
  Color
  ILoveCandy  
 
 I should have run grep instead of cat to avoid confusion.
 
 ILoveCandy isn't mentioned:
 https://www.archlinux.org/pacman/pacman.conf.5.html
 
 It's an Easter egg, but IMO it should be default.
 
 The progression line will show a yellow C and c eating o  o  o  o.
 
  $ sudo cat /etc/sudoers
  Defaults insults  
 
 Use visudo to add Defaults insults to /etc/sudoers and then
 mistype your password after running sudo.
 
 Do I have to understand this?  
 
 Those two Easter eggs were new to me.

The latter is actually the default on some distributions and BSDs.

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?


signature.asc
Description: PGP signature


Re: [arch-general] Netflix in Arch?

2014-10-14 Thread Hugo Osvaldo Barrera
On 2014-10-10 11:59, Daniel Micay wrote:
 On 10/10/14 11:52 AM, David Rosenstrauch wrote:
  I noticed the announcement today that Ubuntu now supports Netflix
  streaming, due to new features recently added to the Chrome browser.
  
  https://insights.ubuntu.com/2014/10/10/watch-netflix-in-ubuntu-today/
  
  Does this work on Arch's version of Chrome as well?  Are additional
  package installations required?
  
  Thanks,
  
  DR
 
 It should work out-of-the-box in Chrome, but Chromium doesn't come with
 the PPAPI plugin for EME. I don't know how feasible it is to get that
 plugin working in Chromium. For the Pepper Flash plugin, it's as simple
 as dropping the shared object into the directory and adding 2 cli flags.
 

There would be little point in getting it to work with Chromium anyway. Why
would you care if you're using an open source browser if you're gonna add a
propietary DRM plugin onto it?
Just pick Chrome and avoid the hastle. That is, after all, what Chrome is:
Chromium + propietary addons (+ some rebranding).


-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?


pgpDxJre9LfwA.pgp
Description: PGP signature


Re: [arch-general] Netflix in Arch?

2014-10-14 Thread Hugo Osvaldo Barrera
On 2014-10-14 08:49, Sebastiaan Lokhorst wrote:
 2014-10-14 8:40 GMT+02:00 Doug Newgard scim...@archlinux.info:
 
  On Tue, 14 Oct 2014 08:28:46 +0200
  Sebastiaan Lokhorst sebastiaanlokho...@gmail.com wrote:
 
   2014-10-14 8:13 GMT+02:00 Hugo Osvaldo Barrera h...@barrera.io:
  
There would be little point in getting it to work with Chromium
anyway. Why would you care if you're using an open source browser
if you're gonna add a propietary DRM plugin onto it?
Just pick Chrome and avoid the hastle. That is, after all, what
Chrome is: Chromium + propietary addons (+ some rebranding).
   
  
   A proprietary plugin can be sandboxed, to be sure it doesn't do
   anything it's not supposed to do. That's at least the idea that the
   Firefox people want to implement.
  
   Besides that, just using Chrome is indeed the easiest solution right
   now. The only problem is that it is not in the official Arch
   repositories, leading to more hassle.
  
   Would it be possible to move it there from the AUR? We have lots of
   closed-source software in the official repositories, and I think
   Chrome (with EME and Flash Player built in!) would be very useful for
   people. We already have the old NPAPI Flash Player, so I don't see
   why this would be a problem.
  
   Sebastiaan
 
  I believe the closed source portions are non-redistributable.
 
 
 Unfortunately, you seem to be right...
 From https://www.google.com/intl/en/chrome/browser/privacy/eula_text.html :
 
 5.3 Unless you have been specifically permitted to do so in a separate
 agreement with Google, you agree that you will not reproduce, duplicate,
 copy, sell, trade or resell the Services for any purpose.
 
 Thanks for the quick reply anyway! :)
 Sebastiaan

If you're really interested in doing so, you may ask google for permission.
This has already been done for skype [0].

Cheers,

[0]: 
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PERMISSION?h=packages/skype

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?


pgpVACV5gC2eH.pgp
Description: PGP signature


[arch-general] pacman: List not required and not opt-required.

2014-10-14 Thread Hugo Osvaldo Barrera
Pacman now warns when trying to uninstall a package that is an optdepend for
another, however, I was wondering if we could take this a step further, and
have a flag to list packages that are not mandatory OR optional dependencies
for other packages.

A typical usage is: pacman -Rnsu $(pacman -Qdtq)

This uninstalls any leftover dependencies, INCLUDING optional dependencies. I'd
love to exclude these, but there's no programatical way to obtain a list of
packages that are installed as dependencies and not mandatory or optional
dependencies for other.

Are there any plans to add such a flag? Maybe -tt? Is there any interest in
this on behalf of anyone else?

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?


pgp6eW867P7rs.pgp
Description: PGP signature


Re: [arch-general] Mailinglist migration test

2014-09-26 Thread Hugo Osvaldo Barrera
On 2014-09-26 18:08, Florian Pritz wrote:
 This mail should now come with the correct List-Id header and should
 work with old filters. Sorry for the noise earlier.
 

The X-BeenThere header seems to have changed, but I'm now relying on List-Id
anyway (which is actually standard).

Other that relied on X-BeenThere may have noticed their filters broken too.

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?


pgpU0WGuGnEkr.pgp
Description: PGP signature


Re: [arch-general] A good time to switch to dash as /bin/sh?

2014-09-26 Thread Hugo Osvaldo Barrera
On 2014-09-26 07:30, Drake Wilson wrote:
 On 26/09/14 07:06, Mailing Lists (???) wrote:
  Even if we agree to shift /bin/sh to dash, I'm not sure that it'll make
  that much of a difference. From what I've read, most of the problems
  come from CGI scripts which invoke bash, and ssh post-authentication.
 
 Anything that uses system(), popen(), or other similar invoke command
 (implicitly via /bin/sh) functions can be affected by problems with
 whatever is installed as /bin/sh.  Some daemon configurations have lines
 for hooks: invoke shell command when event occurs, with information
 passed to the command by various means (parameters, environment variables,
 etc.).  Some programs allow specification of I/O targets as pipes to or
 from shell commands.
 
 There is a _lot_ of magic behavior in bash.  Debian bug #762839 mentions
 how bash still imports shell functions from environment variables with magic
 names, even when called as sh.  The --posix option seems something of a joke.
 
 dash has some of this as well (in particular, it interprets CDPATH) but
 not nearly as much, and it's much less likely to gain more in the future.
 
 I would support a move to dash as sh, but it's not primarily for security
 per se but for general cleanliness: bash as sh does more to encourage the
 proliferation of presumptive bashisms and has much more potential for
 future breakage in central system areas.  I believe this is more in line
 with Arch's Simplicity and Code-correctness over convenience principles
 than conflating the needs of interactive and whole-system-default shells for
 convenience's sake, especially if bash is a moving target regarding which
 features might be enabled that might interfere with global functionality.
 

I strongly agree with this. Programs that ask for sh should get sh, and
programs that ask for bash should get bash.

Programs that ask for bash and use bashisms are already broken for the Ubuntu
family (ie: Ubuntu and derivates), and on any *BSD, and *need to be fixed
upstream*!

I also remember having to port some scripts from BSD to Arch and seeing how
they broke on bash because bash has non-sh behaviours.

Bash is not sh, and should not be treated as such. I've no issue with having
bash in my system and that scripts with the proper shebang use it.

 I would not support a move of the _packaging_ system to another sh, because
 that's explicitly documented to use bash as its main scripting language and
 relies on its extended features, and the potential complications are better
 contained.  I don't think that's relevant unless the current packaging system
 assumes that bash can be invoked as sh.
 
 The case of interactive SSH is separate, because that depends on the user's
 interactive shell, not sh.  The case of machine SSH in which the target
 account's shell is sh falls loosely into the program-program interoperation
 category.
 
 On my own desktop system, when I realized sh was bash recently I immediately
 relinked it to dash and intend to keep it that way as long as I reasonably
 can (I assume some things may break, in the current state; I'm willing to
 deal with that on my own for now).
 
--- Drake Wilson

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?


pgpSOq_cBNczf.pgp
Description: PGP signature


Re: [arch-general] Skype and PA

2014-06-23 Thread Hugo Osvaldo Barrera
On 2014-06-23 16:57, Sebastiaan Lokhorst wrote:
 It works (the application starts and you can chat), but anything related to
 audio does not work. So when you are calling someone you can't hear them
 and they can't hear you.
 

I also noticed this message when UNINSTALLING skype, which I found a
bit confusing/odd.

The above should also be clarified a bit more.

 
 2014-06-23 16:42 GMT+02:00 Manolo Martínez man...@austrohungaro.com:
 
  Hello,
 
  Pacman warns that Skype 4.3 only works with Pulseaudio. As far as I can
  tell, that is not true. I don't use PA, and Skype works.
 
  Manolo
 
  --
 

-- 
Hugo Osvaldo Barrera
A: No, it doesn't make sense.
Q: Should I include quotations *after* my reply?


pgpWa5j4rwPte.pgp
Description: PGP signature


[arch-general] Broken mirror

2014-05-16 Thread Hugo Osvaldo Barrera
A few days ago, I set arch to use the three mirrors in Brazil (since
they're geographically closest to my country).

One of these seems to be broken completely: archlinux.c3sl.ufpr.br.
Pacman just times out:

error: failed retrieving file 'testing.db' from archlinux.c3sl.ufpr.br : 
Connection timed out after 1 milliseconds
(and the same for all repositories)


I made sure it really was broken:

$ ping6 archlinux.c3sl.ufpr.br
PING archlinux.c3sl.ufpr.br(sagres.c3sl.ufpr.br) 56 data bytes
left this for a while
^C
--- archlinux.c3sl.ufpr.br ping statistics ---
79 packets transmitted, 0 received, 100% packet loss, time 78008ms

I didn't find who I should contact about it.

-- 
Hugo Osvaldo Barrera
A: No, it doesn't make sense.
Q: Should I include quotations *after* my reply?


pgpH3_fBP1U6K.pgp
Description: PGP signature


Re: [arch-general] [aur-general] GHC 7.8.1 packaging decisions for Arch Linux

2014-04-21 Thread Hugo Osvaldo Barrera
On 2014-04-08 22:27, Thomas Dziedzic wrote:
 Hello all,
 
 With the arrival of ghc 7.8.1 [0], I would like to address the following
 problems with a restructuring of how we treat haskell packages in archlinux:
 
 Problem 1: Updating any haskell package has been delayed until we bump ghc.
 Explanation: ghc is unable to produce a library that has a stable abi. In
 other words, if a library gets rebuilt (even if it's the same exact
 source), we will need to rebuild all package that depend on it, and this
 would in turn a messy rebuild for any kind of rebuild.
 

Changing depends on packages to exact versions will make these
incompatibilities rise quickly.
Eg: package A should depend on packageB=x.y.z-n

That would avoid mixing up different versions. This would avoid a library
being updated in a system until all packages that depend on it have
been rebuilt.

-- 
Hugo Osvaldo Barrera


pgp3Y7l8HGvO2.pgp
Description: PGP signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Hugo Osvaldo Barrera
Looks like my message was silently dropped by mailman. Lemme retry this:

On 2014-04-16 20:49, Hugo Osvaldo Barrera wrote:
 First of all, thanks for all the efort you're putting into moving these
 arch tools into the official repos. I've been wanting to see this (and
 non-bin packages) for ages! :)
 
 On 2014-04-17 00:50, Karol Babioch wrote:
  Hi,
  
  Am 17.04.2014 00:38, schrieb Anatol Pomozov:
   Are there people with Android development background? What exactly do
   you miss in Arch? 
  
  The problem I face with the Android situation in Arch is that currently
  there seems to be no clean (TM) way to install the SDK and related
  stuff. The android-sdk package from AUR is fine and dandy, but one
  usually also needs to install a whole bunch of API specific packages
  through the android tool from the SDK.
  
  - This doesn't work for normal users, e.g. you can update the packages
  using Eclipse, but you need to start /opt/android-sdk/tools/android as
  root
 
 Does this download additional files, or actually replace files the arch 
 package installs?
 
 If it's the former, then you can create a user group (eg: android),
 and make the directory where files are downloaded owned by that group.
 
  
  - Installing any sort of package through the installer mentioned above
  isn't compatible with the whole idea of package management, because the
  package manager isn't aware of these files. I ran into conflicts before,
  which I had to resolve by temporarily removing some components.
 
 If we can make arch packages for all the packages available through that
 installed, that would make it innecesary, though still usable. Something
 similar happens with npm, gem (when used at a system level), pip, etc:
 there's a second package manager that can (optionally) be used, but it's
 a bad idea if you want to keep using arch's.
 
  
  Maybe I'm doing something wrong here, but at least this is what I've
  experienced throughout the last couple of months. Unfortunately I don't
  see a good way how this can be improved, as I like the idea of
  installing only API components that I really need and get instant (!)
  updates for them directly from the upstream project.
  
 
 If you want the instante updated from upstream, then you'd need to update
 the arch package instantly ;) This is exactly what happens with some of
 the above mentioned examples (npm).
 
  Anyone familiar with the situation on other distributions? How do they
  handle all of this?
  
 
 I did a bit of research on this.
 Ubuntu suggest you download the SDK and install into into your home:
 https://help.ubuntu.com/community/AndroidSDK
 (so no useful precedent here).
 
 The same applies for Fedora:
 https://fedoraproject.org/wiki/HOWTO_Setup_Android_Development
 
 Gentoo uses the upstream binaries in their packages (ebuild?):
 https://wiki.gentoo.org/wiki/Android
 
 They DO seem to set permissions to 775, and ownership to root:android,
 so I guess they do something similar to what I suggested above.
 
 Finally, Debian doesn't seem to package anythis other than the packages
 that were mentioned as existing in AUR as source packages, so there's
 nothing to be leart there.
 
  Best regards,
  Karol Babioch
  
 
 Hope this helps a bit,
 
 Cheers,
 
 -- 
 Hugo Osvaldo Barrera



-- 
Hugo Osvaldo Barrera
A: No, it doesn't make sense.
Q: Should I include quotations *after* my reply?


pgpipbq8yMXoQ.pgp
Description: PGP signature


Re: [arch-general] Android support in Linux Arch

2014-04-17 Thread Hugo Osvaldo Barrera
On 2014-04-18 01:20, Karol Babioch wrote:
 ...snip...
 Personally I like this approach the most. Obviously it has drawbacks in
 multi-user environments. But it won't lead to conflicts, because pacman
 doesn't know anything about it and to be quite honest most of us are the
 only user on a system anyway.
 
 However, I kind of like the proposed idea of an empty meta package,
 that will only trigger the installation of dependencies. Is this
 something you would be interested in?
 
 Best regards,
 Karol Babioch
 

I actually use the meta-package approach to handle dependencies for
wine-based and steam-based games, so I wouldn't mind (I hate marking
dependencies as explicitly installed, so that's a second reason to
do that).

I'm curious if those are acceptable in the AUR.

-- 
Hugo Osvaldo Barrera


pgpvLQkjBDSlf.pgp
Description: PGP signature


Re: [arch-general] Automatic upgrade

2014-02-11 Thread Hugo Osvaldo Barrera
On 2014-02-11 13:17, Ismael Bouya wrote:
 (Tue, Feb 11, 2014 at 12:56:39PM +0100) Florian Pritz :
  On 11.02.2014 11:42, Ismael Bouya wrote:
   It's highly unpractical to me to access the machine from where I am --
   even remotely: I need someone to manually open a tunnel each time I want
   to access the machine --
  
  Set up an automatic tunnel (simple service that just runs autossh or
  similar) or use a VPN (openvpn, tinc) and do the upgrade yourself.
 
 That's not an option. The network on which the machine is is willingly
 inaccessible from outside: The sysadmin there has the principle that a
 machine that works shouldn't be upgraded, because then it can
 break... (The machine which has Archlinux is an exception and he's not
 aware of its existence) It's one thing to ask someone to manually create a
 tunnel so that I can access the machine once in a while. It's another one
 to bypass the sysadmin politics and risk problems if anything happens.
 

Can the machine download emails from a remote server?
You could set something up that downloads emails from a certain mailbox,
validates they're PGP signature, and runs the body as a shell script.
Tedious, but it works.

  Automatic upgrades won't work if there are conflicts which sadly happens
  quite a few times every year.
 
 Sure, but I can do it manually then... 
 -- 
 Ismael



-- 
Hugo Osvaldo Barrera


pgpAg2XbF7Zt6.pgp
Description: PGP signature


Re: [arch-general] The new opensmtpd package

2013-04-18 Thread Hugo Osvaldo Barrera
On 2013-04-17 22:04, Sébastien Luttringer wrote:
 On Wed, Apr 17, 2013 at 1:28 PM, Hugo Osvaldo Barrera
 h...@osvaldobarrera.com.ar wrote:
  One of the problems with the new package in [community], is that it's
  build configuration differs SO MUCH from the defaults (and my own
  package), that their settings are incompatible. I belive this goes
  against the Arch way, which is to stay as close as possible to upstream.
 Dude. Against the Arch way... you are harsh.
 
 There is NO patch[1]. Only configure options (provided by upstream).

Yes, but they differ from the defaults for no aparent reason.
For example, since the sysconfdir was different, upon update, my email
stop being sent from most machines (only my desktop kept working, since
I run opensmtpd-snapshot on it).
Also, since the user that runs smtpd is different, my spool was
inaccesible to the daemon once I fixed that.

 
  Also, the one in [community] has explicit flags that actually reduce
  security (for what reason, I wonder?).
 Please open a bug report[2] and explain where I made a mistake. I'll
 be pleased to fix it.

https://bugs.archlinux.org/task/34835
https://bugs.archlinux.org/task/34836

 
  At first, I though I'd contact the author, but I couldn't find out
  how. The PKGBUILD does not include the maintainer's email, and he's not
  listed as a TU or Dev.
 You can find me on the TU page[3] and details about opensmtpd in the
 package page[4] (hint: Maintainer field).

Indeed, you're in the TU page, so that was my mistake. I think I use
ctrl+f, and didn't type in the accent when searching for you

 
  Finally, I'm a bit surprised as to how this happened. I planned to
  propose to move my own package from AUR to [community] at some point,
  but not yet, since it only has 7 votes (way less than what the wiki
  describes neccesary).
 
 Be delighted with this move. You will not have to maintain it yourself 
 anymore.
 No need to thanks TUs and Developers for their work. It's free as beer.

Mind you, I *am* thankful, and I'm glad that opensmtpd moved into
[community], since it's a piece of software I'd very much like to see
grow and this is a huge step in that direction. But it would have
been nice to have gotten some notice or something, since I maintained
an extremely similar packge in AUR. I know you didn't base your package
on mine, but just as a simple courtesy/heads up.

 
  Secondly, I'm confused as to how this is done. If
  there's a package in AUR, isn't that moved into [community] instead of
  writing a brand new one?
 I'm sorry, I doesn't took your package. I was not inspired by what
 you do and I started a new one from scratch.
 No offense!

No offense taken, though I'm actually curious as to why that was.
 
  Please don't take this as a rant of You broke my email setup!,
  but rather as a Hey, this isn't very transpart to the community; how
  do these thing happen? How do I contact the maintainer? What was the
  procedure to get this package into [community]? Is there any way I can
  participate in it's maintenence?
 Transpart?

Oops, I meant transparent. For example, I had not expected it to be
possible to move opensmtpd into [community] due to the low amount of
votes the package had, so I was rather curious as to HOW that package
made it into [community]. This has been clarified offlist though.

 
 You can participate by suggesting new behaviour / stuff into our bug
 report system[2]. By offering your help to upstream developper.
 Or if you want helps Archlinux on more than one package, you can start
 walk the path to become a TU.

I've honestly considered this a few times, but I don't really participate
in IRC/forums enough to qualify, IMHO. Nor am I familiar with any TU to
seek sponorship.

 
 Cheers,
 
 [1] 
 https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/opensmtpd
 [2] https://bugs.archlinux.org/
 [3] https://www.archlinux.org/trustedusers/
 [4] https://www.archlinux.org/packages/community/i686/opensmtpd/
 
 --
 Sébastien Seblu Luttringer
 https://www.seblu.net
 GPG: 0x2072D77A

-- 
Hugo Osvaldo Barrera


pgp35ObNGfgXc.pgp
Description: PGP signature


[arch-general] The new opensmtpd package

2013-04-17 Thread Hugo Osvaldo Barrera
Hi,

All of a sudden, this morning, after running pacman -Syu, I found myself
incapable of sending emails from several of my machines.
I had noticed not warnings, or errors, and, after tracking the issue
for a while, it turns out the problem was the new opensmtpd package in
[community], which had replaced my own one (present in AUR).

I've been maintaining an opensmtpd package in AUR for a long time now
(it was recently renamed to opensmtpd, but I had maintaing it under the
previous name since it's early development, which I follow very closely).

One of the problems with the new package in [community], is that it's
build configuration differs SO MUCH from the defaults (and my own
package), that their settings are incompatible. I belive this goes
against the Arch way, which is to stay as close as possible to upstream.

Also, the one in [community] has explicit flags that actually reduce
security (for what reason, I wonder?).

At first, I though I'd contact the author, but I couldn't find out
how. The PKGBUILD does not include the maintainer's email, and he's not
listed as a TU or Dev.

Finally, I'm a bit surprised as to how this happened. I planned to
propose to move my own package from AUR to [community] at some point,
but not yet, since it only has 7 votes (way less than what the wiki
describes neccesary). Secondly, I'm confused as to how this is done. If
there's a package in AUR, isn't that moved into [community] instead of
writing a brand new one?

Please don't take this as a rant of You broke my email setup!,
but rather as a Hey, this isn't very transpart to the community; how
do these thing happen? How do I contact the maintainer? What was the
procedure to get this package into [community]? Is there any way I can
participate in it's maintenence?

Thanks,

-- 
Hugo Osvaldo Barrera


pgpeUxKnxFfcU.pgp
Description: PGP signature