Re: [arch-general] immediate sleep after resume

[P .NIKOLIC]

On Thu, 15 Nov 2012 08:37:00 -0800
Curtis Shimamoto  wrote:

> On 11/15/12 at 11:18am, Genes MailLists wrote:
> > 
> > 
> >   Forgot to mention in original post - it seems well understood that
> > the window managers may or may not play nicely with systemd - as to
> > who will do power management.
> > 
> >   If a user is not logged in - it is still nice to have systemd
> > sleep system on lid close for example - and for this reason the
> > window managers are given the ability to "inhibit" systemd when they
> > are claiming to do the power management. And when they are not, then
> > systemd does not get the "inhibit". [1]
> > 
> >   Several window managers, KDE among them are supposed to "play
> > nice" with systemd in this regard.
> > 
> >  So, one suggestion some have is not to use KDE at all for this -
> > and rely solely on systemd - it is of course less configurable. I
> > have not yet tried this approach. This can be done via the same
> > login.conf.
> > 
> >  It's not a huge deal, as I just press power button to wake it up
> > again, but curious what others have found.
> > 
> >  gene
> > 
> >  [1] I'd rather have a positive than a triple negative
> > LidSwitchIgnoreInhibited=no
> >   might be easier to read as
> > LidSwitchInhibitIsActive=yes
> > 
> > 
> > 
> 
> Personally I just use xautolock, so I don't have to deal with these
> competing systemd.  I just use the native systemd (actually in its
> default form), and it works well.
> 
> I was not aware that you were working towards teh goal of having
> systemd actually handle the stuff, as other users typically wanted
> their DE to handle the power management, and have systemd do
> nothing.  This is why I directed you to the man page, in hopes that
> you would find the HandleLidSwitch= setting.  
> 
> As far as doing it the way you want, I have heard (though I don't use
> KDE so I have no personal experience) that it's power management does
> not play nicely with this system.  I am not sure what power management
> setups do play nicely, but every KDE user that I have come across all
> ended up just setting HandleLidSwitch=ignore and being done with it.
> 
> If you can get your proposed setup working, I would love to hear about
> it.  I do not use said systems, but I still welcome knowledge.
> 
> Maybe a DE user can weigh in here. Best of luck.
> 
> Regards,

Hi .

Well thou not using a laptop i am using systemd and the latest 
kde 4.9.3   . I use the sleep button on the keyboard (logotech internet
navigator usb)  it all works perfectly  apart from a complaint about
shutting down 3 of the 4 CPU cores  prior to full shutdown

Reboot is almost instant working after approximately 3 seconds 


Pete .


-- 
Linux 7-of-9 3.6.6-1-ARCH #1 SMP PREEMPT Mon Nov 5 11:57:22 CET 2012
x86_64 GNU/Linux

Re: [arch-general] Can not assign static IP address with net-auto-wired.service

[Thanos Zygouris]

On Thu 15 Nov 14:51, Mikhail Strizhov wrote:
> 
> Hello,
> 
> I am having a trouble configuring static IP address on fresh arch
> installation.
> 
> As beginners guide point, I installed ifplugd (with dhcp), copied
> ethernet-static in /etc/network.d. Here is my
> /etc/network.d/ethernet-static
> 
You installed netcfg package, right?

Re: [arch-general] Can not assign static IP address with net-auto-wired.service

[Ray Kohler]

On Thu, Nov 15, 2012 at 4:51 PM, Mikhail Strizhov
 wrote:

> ROUTES=('129.82.44.0/22 via 129.82.44.1')

You don't need this - it's for extra static routes. netcfg will set up
the default route for you.

You do need to add "NETMASK=22" to your config, otherwise netcfg
assumes it to be a /24 network and will set up a wrong default route.

[arch-general] Can not assign static IP address with net-auto-wired.service

[Mikhail Strizhov]

Hello,

I am having a trouble configuring static IP address on fresh arch 
installation.


As beginners guide point, I installed ifplugd (with dhcp), copied 
ethernet-static in /etc/network.d. Here is my /etc/network.d/ethernet-static


CONNECTION='ethernet'
DESCRIPTION='A basic static ethernet connection using iproute'
INTERFACE='eth0'
IP='static'
ADDR='129.82.47.19'
ROUTES=('129.82.44.0/22 via 129.82.44.1')
GATEWAY='129.82.44.1'
DNS=('129.82.45.181')

## For IPv6 autoconfiguration
#IP6=stateless

## For IPv6 static address configuration
#IP6='static'
#ADDR6=('1234:5678:9abc:def::1/64' '1234:3456::123/96')
#ROUTES6=('abcd::1234')
#GATEWAY6='1234:0:123::abcd'



systemctl enable net-auto-wired.service
systemctl start  net-auto-wired.service   fails with a error "Network is 
unreachable, Adding gateway 129.82.44.1 failed".



$ cat /etc/conf.d/netcfg
NETWORKS=(last)

WIRED_INTERFACE="eth0"

WIRELESS_INTERFACE="wlan0"

#AUTO_PROFILES=("profile1" "profile2")


My network settings are:
Ip: 129.82.47.19/22
Gw: 129.82.44.1
DNS: 129.82.45.181

Any help is appreciated.

Thank you.

Re: [arch-general] immediate sleep after resume

[William Giokas]

On Thu, Nov 15, 2012 at 08:52:09AM -0500, Genes MailLists wrote:
> This started happening sometime after I switched to systemd (tho I
> am not finger pointing).
> 
> Upon resume - the laptop immediately sleeps - the second resume is fine.
> Not every time either. Fresh boot - sleep - resume cycle seems to
> work fine.
> 

I had this same error not too long ago, don't know if it's related, but
I didn'thave my suspend hooks set up right. [1]

>  Googling suggested putting this in /etc/systemd/login.conf
> 
> LidSwitchIgnoreInhibited=no
> 
> However this makes no sense to me - as surely systemd knows the
> difference between the open and close lid events. The argument made
> was that there was competition between kde and systemd to
> sleep/resume and this would keep systemd from doing anything.
> 
> Anyway - above makes no difference :-)
> 
> Anyone have any ideas?
> 
>   testing repo fully updated - using kde and systemd.
> 
> gene/

[1] https://wiki.archlinux.org/index.php/Systemd#Sleep_hooks

-- 
William Giokas | KaiSforza
GnuPG Key: 0xE99A7F0F
Fingerprint: F078 CFF2 45E8 1E72 6D5A  8653 CDF5 E7A5 E99A 7F0F


pgpmtTqgoXjLf.pgp
Description: PGP signature

Re: [arch-general] [arch-dev-public] steam in our repos?

[Bjørn Øivind Bjørnsen]

On 15/11/12 09:30, Joakim Hernberg wrote:
> On Thu, 15 Nov 2012 03:06:36 -0500
> Daniel Micay  wrote:
> 
>> On Thu, Nov 15, 2012 at 3:00 AM, Joakim Hernberg 
>> wrote:
>>>
>>> Not to mention that the package seems to install a wine version of
>>> steam that is in closed beta, which makes it less than useful for
>>> the majority of us.
>>
>> It doesn't use Wine (it's native), and it works without being in the
>> private beta (chat, installing a couple dozen indie games). You just
>> can't play the native ports of big titles (tf2, serious sam 3, etc.)
>> without being in the private beta.
> 
> Ah, sorry about the wine allegation, it looked just like running it
> in wine and is multiilb with lib32 stuff.  My mistake, I should
> have verified before opening my mouth.
> 
> When I try to login with my steam account I get told that: "This version
> of Steam is currently in closed beta. Login with an enrolled account to
> continue" http://dl.dropbox.com/u/879835/steam-beta.png
> 

There is a way around this by opening specific steam URLs. Not the same
as proper beta participation, but it allowed me to install and run
Amnesia at least.

Try running "steam steam://open/games" :)

Regards,
Bjørn Øivind



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] LUKS, SD card reader and initramfs

[BxS]

I also use a SD card with the keyfile to unlock / luks volume and works 
fine, no need to udev rules.


My setup also failed at first, I needed to follow the module chain 
dependency and found a needed module not present in initramfs, just 
added it and started working like a charm.

Re: [arch-general] immediate sleep after resume

[Daniel Egeberg]

On Thu, Nov 15, 2012 at 2:52 PM, Genes MailLists  wrote:

> This started happening sometime after I switched to systemd (tho I am not
> finger pointing).
>
> Upon resume - the laptop immediately sleeps - the second resume is fine.
> Not every time either. Fresh boot - sleep - resume cycle seems to work
> fine.
>
>  Googling suggested putting this in /etc/systemd/login.conf
>
> LidSwitchIgnoreInhibited=no
>
> However this makes no sense to me - as surely systemd knows the difference
> between the open and close lid events. The argument made was that there was
> competition between kde and systemd to sleep/resume and this would keep
> systemd from doing anything.
>
> Anyway - above makes no difference :-)
>
> Anyone have any ideas?
>
>   testing repo fully updated - using kde and systemd.
>
> gene/
>

I used to have that problem as well. I fixed it by setting
  HandleLidSwitch=ignore
in /etc/systemd/login.conf.

-- 
Daniel Egeberg

Re: [arch-general] immediate sleep after resume

[Luke Johnson]

On Thu, Nov 15, 2012 at 11:37 AM, Curtis Shimamoto <
sugar.and.scru...@gmail.com> wrote:

> On 11/15/12 at 11:18am, Genes MailLists wrote:
> >
> >
> >   Forgot to mention in original post - it seems well understood that
> > the window managers may or may not play nicely with systemd - as to
> > who will do power management.
> >
> >   If a user is not logged in - it is still nice to have systemd
> > sleep system on lid close for example - and for this reason the
> > window managers are given the ability to "inhibit" systemd when they
> > are claiming to do the power management. And when they are not, then
> > systemd does not get the "inhibit". [1]
> >
> >   Several window managers, KDE among them are supposed to "play
> > nice" with systemd in this regard.
> >
> >  So, one suggestion some have is not to use KDE at all for this -
> > and rely solely on systemd - it is of course less configurable. I
> > have not yet tried this approach. This can be done via the same
> > login.conf.
> >
> >  It's not a huge deal, as I just press power button to wake it up
> > again, but curious what others have found.
> >
> >  gene
> >
> >  [1] I'd rather have a positive than a triple negative
> > LidSwitchIgnoreInhibited=no
> >   might be easier to read as
> > LidSwitchInhibitIsActive=yes
> >
> >
> >
>
> Personally I just use xautolock, so I don't have to deal with these
> competing systemd.  I just use the native systemd (actually in its
> default form), and it works well.
>
> I was not aware that you were working towards teh goal of having systemd
> actually handle the stuff, as other users typically wanted their DE to
> handle the power management, and have systemd do nothing.  This is why I
> directed you to the man page, in hopes that you would find the
> HandleLidSwitch= setting.
>
> As far as doing it the way you want, I have heard (though I don't use
> KDE so I have no personal experience) that it's power management does
> not play nicely with this system.  I am not sure what power management
> setups do play nicely, but every KDE user that I have come across all
> ended up just setting HandleLidSwitch=ignore and being done with it.
>
> If you can get your proposed setup working, I would love to hear about
> it.  I do not use said systems, but I still welcome knowledge.
>
> Maybe a DE user can weigh in here. Best of luck.
>
> Regards,
> --
> Curtis Shimamoto
> sugar.and.scru...@gmail.com
>

On the wiki 
herein
the warning section it says that only Gnome and KDE play nice right
now
and you can put ignore in all the Handle fields in logind.conf to allow
your DE or WM to manage it instead. Seems to be working for me on XFCE.

Re: [arch-general] immediate sleep after resume

[Maciej Sitarz]

Hi
I had a similar problem using systemd+KDE. I think I manged to fix it by
setting these values in /etc/systemd/logind.conf:

HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=ignore

As I understand the manual for these options, this will prevent systemd
from handling all those Power/Suspend/Lid events. They will be handled
by KDE.
Also I tried to disable power management in KDE, as I remember it fixed
the immediate sleep, but then I was not able to sleep/hibernate using
KDE menus.

Best regards
-- 
Maciej Sitarz

Re: [arch-general] [arch-dev-public] steam in our repos?

[Marti Raudsepp]

> steam steam://open/games

Awesome!

On Thu, Nov 15, 2012 at 10:06 AM, Daniel Micay  wrote:
> and it works without being in the
> private beta (chat, installing a couple dozen indie games).

Did you try installing and running the games?

I can tell Steam to install games; it tells me they're downloaded
immediately, but it doesn't actually download anything. When I try to
run the games, I get "Failed to start game (missing executable)."

Regards,
Marti

Re: [arch-general] immediate sleep after resume

[Curtis Shimamoto]

On 11/15/12 at 11:18am, Genes MailLists wrote:
> 
> 
>   Forgot to mention in original post - it seems well understood that
> the window managers may or may not play nicely with systemd - as to
> who will do power management.
> 
>   If a user is not logged in - it is still nice to have systemd
> sleep system on lid close for example - and for this reason the
> window managers are given the ability to "inhibit" systemd when they
> are claiming to do the power management. And when they are not, then
> systemd does not get the "inhibit". [1]
> 
>   Several window managers, KDE among them are supposed to "play
> nice" with systemd in this regard.
> 
>  So, one suggestion some have is not to use KDE at all for this -
> and rely solely on systemd - it is of course less configurable. I
> have not yet tried this approach. This can be done via the same
> login.conf.
> 
>  It's not a huge deal, as I just press power button to wake it up
> again, but curious what others have found.
> 
>  gene
> 
>  [1] I'd rather have a positive than a triple negative
> LidSwitchIgnoreInhibited=no
>   might be easier to read as
> LidSwitchInhibitIsActive=yes
> 
> 
> 

Personally I just use xautolock, so I don't have to deal with these
competing systemd.  I just use the native systemd (actually in its
default form), and it works well.

I was not aware that you were working towards teh goal of having systemd
actually handle the stuff, as other users typically wanted their DE to
handle the power management, and have systemd do nothing.  This is why I
directed you to the man page, in hopes that you would find the
HandleLidSwitch= setting.  

As far as doing it the way you want, I have heard (though I don't use
KDE so I have no personal experience) that it's power management does
not play nicely with this system.  I am not sure what power management
setups do play nicely, but every KDE user that I have come across all
ended up just setting HandleLidSwitch=ignore and being done with it.

If you can get your proposed setup working, I would love to hear about
it.  I do not use said systems, but I still welcome knowledge.

Maybe a DE user can weigh in here. Best of luck.

Regards,
-- 
Curtis Shimamoto
sugar.and.scru...@gmail.com

Re: [arch-general] immediate sleep after resume

[Genes MailLists]

  Forgot to mention in original post - it seems well understood that 
the window managers may or may not play nicely with systemd - as to who 
will do power management.


  If a user is not logged in - it is still nice to have systemd sleep 
system on lid close for example - and for this reason the window 
managers are given the ability to "inhibit" systemd when they are 
claiming to do the power management. And when they are not, then systemd 
does not get the "inhibit". [1]


  Several window managers, KDE among them are supposed to "play nice" 
with systemd in this regard.


 So, one suggestion some have is not to use KDE at all for this - and 
rely solely on systemd - it is of course less configurable. I have not 
yet tried this approach. This can be done via the same login.conf.


 It's not a huge deal, as I just press power button to wake it up 
again, but curious what others have found.


 gene

 [1] I'd rather have a positive than a triple negative
LidSwitchIgnoreInhibited=no
  might be easier to read as
LidSwitchInhibitIsActive=yes

Re: [arch-general] immediate sleep after resume

[Curtis Shimamoto]

On 11/15/12 at 02:11pm, Leonidas Spyropoulos wrote:
> On 15 Nov 2012 13:52, "Genes MailLists"  wrote:
> >
> > This started happening sometime after I switched to systemd (tho I am not
> finger pointing).
> >
> > Upon resume - the laptop immediately sleeps - the second resume is fine.
> > Not every time either. Fresh boot - sleep - resume cycle seems to work
> fine.
> >
> >  Googling suggested putting this in /etc/systemd/login.conf
> >
> > LidSwitchIgnoreInhibited=no
> >
> > However this makes no sense to me - as surely systemd knows the
> difference between the open and close lid events. The argument made was
> that there was competition between kde and systemd to sleep/resume and this
> would keep systemd from doing anything.
> >
> > Anyway - above makes no difference :-)
> >
> > Anyone have any ideas?
> >
> >   testing repo fully updated - using kde and systemd.
> >
> > gene/
> 
> Hmm I am having the same behaviour without testing repos enabled, up to
> date, and with slim + xfce.
> I am also using systemd.
> 
> It might have to do with the WiFi. Mine is a broadcom chip and
> unfortunately i found only the closed source drivers work (wl).
> 
> I will try the suggested from Google config.
> 
> Thanks,
> Leonidas

In your apparent google adventure, I find it suprising yuo did not find
the correct answer as I have seen it come up in the forums many many
times.

Also suprising is that when you found the suggestion to use
LidSwitchIgnoreInhibited=no, you didn't then find that logind.conf has
other options in that file.  

See the logind.conf man page for the answer.

-- 
Curtis Shimamoto
sugar.and.scru...@gmail.com

Re: [arch-general] LUKS, SD card reader and initramfs

[Mauro Santos]

On 14-11-2012 19:06, Krzysztof Warzecha wrote:
> Hi,
> 
> 2012/11/14 Mauro Santos :
>> (1) Why SD card? Because my laptop has a card reader and by using it I
>> don't need to occupy a USB port, so when I'm at home I could insert the
>> SD card and forget about it, then when I take the laptop out I don't
>> carry the card with me or I remove it as soon as it isn't needed.
> 
> Nice idea. I have entire disk encrypted and I keep my /boot on usb
> stick (that I carry with me). With unencrypted /boot anyone can access
> and modify kernel image and initramfs (for example, to intercept
> passphrase).
> 

I have a script that checks all files in /boot and the space from lba 0
up to the first partition for any changes and issues a warning if
anything changed. It doesn't prevent from all nasty things but at least
gives me a heads up.

> 
> Boot with 'break=y' in kernel commandline, this will drop you to shell
> in initramfs. Check if you are able to access sd card. If not, try to
> add some modules to initramfs and try again.
> 

Thanks for the tip, I didn't know I could use break=y, I was using
init=/bin/sh.

I think I have it more or less figured out now. I was doing things
correctly from the start(1) it's just that either the card reader, the
card or both(2) don't play well in certain cases, it goes like this:

If I do a cold boot things always work well.
If I reboot sometimes it works fine, sometimes it works but I would need
to use a long rootdelay, which I don't want to use because of the case
when I boot without the card inserted. Other times it fails miserably
with lots of errors and I need to remove the card so boot can continue.

The compromise I've found is that if I reboot without the card inserted
and wait until the kernel starts to boot to insert the card (around the
time early kms kicks in) things seem to always work fine too. The only
quirk is that using /dev/disk/by-id/mmc-whatever seems to be more
reliable than using /dev/mmcblk0 directly (less change of getting errors).

(1) I was adding the correct drivers to the initramfs but I was testing
things after a reboot and not with cold boots.

(2) It might be due to the cheap card I bought, since I didn't know from
the start if I was going to be able to make this work (currently I don't
have any other devices that use sd cards). It could also be a case of
funky hardware and something the bios does (or does not do) on reboots,
could be a combination of cheap card + funky hardware or the driver does
not do some reset it should do when being loaded.

-- 
Mauro Santos

Re: [arch-general] immediate sleep after resume

[Leonidas Spyropoulos]

On 15 Nov 2012 13:52, "Genes MailLists"  wrote:
>
> This started happening sometime after I switched to systemd (tho I am not
finger pointing).
>
> Upon resume - the laptop immediately sleeps - the second resume is fine.
> Not every time either. Fresh boot - sleep - resume cycle seems to work
fine.
>
>  Googling suggested putting this in /etc/systemd/login.conf
>
> LidSwitchIgnoreInhibited=no
>
> However this makes no sense to me - as surely systemd knows the
difference between the open and close lid events. The argument made was
that there was competition between kde and systemd to sleep/resume and this
would keep systemd from doing anything.
>
> Anyway - above makes no difference :-)
>
> Anyone have any ideas?
>
>   testing repo fully updated - using kde and systemd.
>
> gene/

Hmm I am having the same behaviour without testing repos enabled, up to
date, and with slim + xfce.
I am also using systemd.

It might have to do with the WiFi. Mine is a broadcom chip and
unfortunately i found only the closed source drivers work (wl).

I will try the suggested from Google config.

Thanks,
Leonidas

[arch-general] immediate sleep after resume

[Genes MailLists]

This started happening sometime after I switched to systemd (tho I am 
not finger pointing).


Upon resume - the laptop immediately sleeps - the second resume is fine.
Not every time either. Fresh boot - sleep - resume cycle seems to work 
fine.


 Googling suggested putting this in /etc/systemd/login.conf

LidSwitchIgnoreInhibited=no

However this makes no sense to me - as surely systemd knows the 
difference between the open and close lid events. The argument made was 
that there was competition between kde and systemd to sleep/resume and 
this would keep systemd from doing anything.


Anyway - above makes no difference :-)

Anyone have any ideas?

  testing repo fully updated - using kde and systemd.

gene/

Re: [arch-general] [arch-dev-public] steam in our repos?

[Gaetan Bisson]

[2012-11-15 12:59:23 +0100] Alexander Rødseth:
> Supporting packages that meet the conditions for being eligible for
> moving from AUR surely is a good thing, though?

Not really: those conditions are way too permissive - they would allow,
I don't know, like 30% of the AUR to be moved to [community]. They are
here to prevent moving blatantly useless packages to our repos, not to
be understood as sufficient conditions for moving.

> Also, steam is not just any old app. Getting this level of support for
> gaming on Linux, for the first time, is a big deal.

If you say so. But that does not balance out the legal issues.

-- 
Gaetan

Re: [arch-general] [arch-dev-public] steam in our repos?

[Alexander Rødseth]

> Of course nobody cares; people just want to throw more and more binary
> blobs in [community] because it's cool and the AUR is for losers...

Supporting packages that meet the conditions for being eligible for
moving from AUR surely is a good thing, though?
Also, steam is not just any old app. Getting this level of support for
gaming on Linux, for the first time, is a big deal.

-- 
Sincerely,
  Alexander Rødseth
  xyproto / TU

Re: [arch-general] [arch-dev-public] steam in our repos?

[Gaetan Bisson]

[2012-11-15 11:35:06 +] Leonidas Spyropoulos:
> On 15 Nov 2012 10:15, "Gaetan Bisson"  wrote:
> >
> > [2012-11-15 09:23:43 +] Leonidas Spyropoulos:
> > > And written permission should be the emails, thus I believe we are fine.
> >
> > Written permission should be a legally binding document. An email
> > stating the personal opinion of somebody who is neither a lawyer nor
> > official representative of the copyright holder (the company) has no
> > legal value.
> >
> > Of course nobody cares; people just want to throw more and more binary
> > blobs in [community] because it's cool and the AUR is for losers...
> 
> Fair enough I can understand that, so having it in the AUR instead will
> save us from all that discussion since it's not binary, it's just a link
> for fetching and unzipping it, right?

Roughly yes: https://wiki.archlinux.org/index.php/Arch_User_Repository

Use the AUR - you will love it. I don't know when people started
thinking the AUR wasn't good enough for their packages anymore...

-- 
Gaetan

Re: [arch-general] [arch-dev-public] steam in our repos?

[Leonidas Spyropoulos]

On 15 Nov 2012 10:15, "Gaetan Bisson"  wrote:
>
> [2012-11-15 09:23:43 +] Leonidas Spyropoulos:
> > And written permission should be the emails, thus I believe we are fine.
>
> Written permission should be a legally binding document. An email
> stating the personal opinion of somebody who is neither a lawyer nor
> official representative of the copyright holder (the company) has no
> legal value.
>
> Of course nobody cares; people just want to throw more and more binary
> blobs in [community] because it's cool and the AUR is for losers...

Fair enough I can understand that, so having it in the AUR instead will
save us from all that discussion since it's not binary, it's just a link
for fetching and unzipping it, right?

>
> --
> Gaetan

Re: [arch-general] [arch-dev-public] steam in our repos?

[Gaetan Bisson]

[2012-11-15 09:23:43 +] Leonidas Spyropoulos:
> And written permission should be the emails, thus I believe we are fine.

Written permission should be a legally binding document. An email
stating the personal opinion of somebody who is neither a lawyer nor
official representative of the copyright holder (the company) has no
legal value.

Of course nobody cares; people just want to throw more and more binary
blobs in [community] because it's cool and the AUR is for losers...

-- 
Gaetan

Re: [arch-general] [arch-dev-public] steam in our repos?

[Leonidas Spyropoulos]

On 15 Nov 2012 08:55, "Joakim Hernberg"  wrote:
>
> On Thu, 15 Nov 2012 03:40:47 -0500
> Daniel Micay  wrote:
>
> > steam://open/games
>
> Wow, this is all that clawsmail managed to quote from your msg...:)
>
> Indeed, it does work somewhat when started as "steam
> steam://open/games", even though I don't find a single game to
> play :(  Thanks for the package, I guess it might become more useful at
> some later date.
>
> --
>
>Joakim

It is not clear to me if we can distribute the package or not. I think the
package was in AUR until a couple of days ago.
As for the legal parts, if we get permission we should be fine, right [1]?
And written permission should be the emails, thus I believe we are fine.

[1]: […] without the prior written consent of Valve. […]

Re: [arch-general] [arch-dev-public] steam in our repos?

[Joakim Hernberg]

On Thu, 15 Nov 2012 03:40:47 -0500
Daniel Micay  wrote:

> steam://open/games

Wow, this is all that clawsmail managed to quote from your msg...:)

Indeed, it does work somewhat when started as "steam
steam://open/games", even though I don't find a single game to
play :(  Thanks for the package, I guess it might become more useful at
some later date.

-- 

   Joakim

Re: [arch-general] [arch-dev-public] steam in our repos?

[Daniel Micay]

On Thu, Nov 15, 2012 at 3:30 AM, Joakim Hernberg  wrote:
> On Thu, 15 Nov 2012 03:06:36 -0500
> Daniel Micay  wrote:
>
>> On Thu, Nov 15, 2012 at 3:00 AM, Joakim Hernberg 
>> wrote:
>> >
>> > Not to mention that the package seems to install a wine version of
>> > steam that is in closed beta, which makes it less than useful for
>> > the majority of us.
>>
>> It doesn't use Wine (it's native), and it works without being in the
>> private beta (chat, installing a couple dozen indie games). You just
>> can't play the native ports of big titles (tf2, serious sam 3, etc.)
>> without being in the private beta.
>
> Ah, sorry about the wine allegation, it looked just like running it
> in wine and is multiilb with lib32 stuff.  My mistake, I should
> have verified before opening my mouth.
>
> When I try to login with my steam account I get told that: "This version
> of Steam is currently in closed beta. Login with an enrolled account to
> continue" http://dl.dropbox.com/u/879835/steam-beta.png
>
> --
>
>Joakim

If you aren't in the beta, you can start it by running `steam
steam://open/games' (or another steam page), or by clicking a steam
link from your browser. As far as I can tell, they made it easy to
work around the "private" part intentionally, but it makes it clear
that you shouldn't expect support yet.

Re: [arch-general] [arch-dev-public] steam in our repos?

[Joakim Hernberg]

On Thu, 15 Nov 2012 03:06:36 -0500
Daniel Micay  wrote:

> On Thu, Nov 15, 2012 at 3:00 AM, Joakim Hernberg 
> wrote:
> >
> > Not to mention that the package seems to install a wine version of
> > steam that is in closed beta, which makes it less than useful for
> > the majority of us.
> 
> It doesn't use Wine (it's native), and it works without being in the
> private beta (chat, installing a couple dozen indie games). You just
> can't play the native ports of big titles (tf2, serious sam 3, etc.)
> without being in the private beta.

Ah, sorry about the wine allegation, it looked just like running it
in wine and is multiilb with lib32 stuff.  My mistake, I should
have verified before opening my mouth.

When I try to login with my steam account I get told that: "This version
of Steam is currently in closed beta. Login with an enrolled account to
continue" http://dl.dropbox.com/u/879835/steam-beta.png

-- 

   Joakim

Re: [arch-general] [arch-dev-public] steam in our repos?

[Daniel Micay]

On Thu, Nov 15, 2012 at 3:00 AM, Joakim Hernberg  wrote:
> On Thu, 15 Nov 2012 16:27:30 +1100
> Gaetan Bisson  wrote:
>
>> [2012-11-15 00:04:43 -0500] Daniel Wallace:
>> > I read through the entire license.  It seemed ok to me but as I am
>> > not a lawyer I emailed them to request permission first to
>> > redistribute the package in community/multilib.
>>
>> I am not a lawyer either but I understand sentences such as:
>>
>>   "You may not, in whole or in part: copy, photocopy, reproduce,
>>   [...] the Program; [...] You may not [...] transfer
>>   reproductions of the Program to other parties in any way [...]
>>   without the prior written consent of Valve."
>>
>> Note that there is a huge difference between written and express
>> consent (the latter is what I believe you have obtained by email). So
>> as best as I understand we do not have legal right to distribute this
>> program.
>>
>
> Not to mention that the package seems to install a wine version of
> steam that is in closed beta, which makes it less than useful for the
> majority of us.
>
> --
>
>Joakim

It doesn't use Wine (it's native), and it works without being in the
private beta (chat, installing a couple dozen indie games). You just
can't play the native ports of big titles (tf2, serious sam 3, etc.)
without being in the private beta.

Re: [arch-general] [arch-dev-public] steam in our repos?

[Joakim Hernberg]

On Thu, 15 Nov 2012 16:27:30 +1100
Gaetan Bisson  wrote:

> [2012-11-15 00:04:43 -0500] Daniel Wallace:
> > I read through the entire license.  It seemed ok to me but as I am
> > not a lawyer I emailed them to request permission first to
> > redistribute the package in community/multilib.
> 
> I am not a lawyer either but I understand sentences such as:
> 
>   "You may not, in whole or in part: copy, photocopy, reproduce,
>   [...] the Program; [...] You may not [...] transfer
>   reproductions of the Program to other parties in any way [...]
>   without the prior written consent of Valve."
> 
> Note that there is a huge difference between written and express
> consent (the latter is what I believe you have obtained by email). So
> as best as I understand we do not have legal right to distribute this
> program.
> 

Not to mention that the package seems to install a wine version of
steam that is in closed beta, which makes it less than useful for the
majority of us.

-- 

   Joakim