Re: [arch-general] text console no longer turns off (it blanks, but powered) after 4.12.5 or xf86-video-ati update

[Ralf Mardorf]

PPS: A few days ago I tested a LCD monitor. Screen blanking already
caused the monitor to completely power off (after hat it was needed to
turn on the monitor by the monitor's power button). Perhaps you changed
some Eco settings of your monitor? Maybe your monitor powered off
triggered by screen blanking and now it doesn't do it anymore?

Re: [arch-general] text console no longer turns off (it blanks, but powered) after 4.12.5 or xf86-video-ati update

[Ralf Mardorf]

On Tue, 15 Aug 2017 22:14:42 -0500, David C. Rankin wrote:
> With X at least there is xset, but I'm not sure what to look at for
> the default terminal?

Since I'm using X I didn't know setterm, but the Arch Wiki mentions
it:

https://wiki.archlinux.org/index.php/Display_Power_Management_Signaling#DPMS_interaction_in_a_Linux_console_with_setterm

Re: [arch-general] text console no longer turns off (it blanks, but powered) after 4.12.5 or xf86-video-ati update

[Ralf Mardorf]

On Tue, 15 Aug 2017 22:14:42 -0500, David C. Rankin wrote:
>It has always properly blanked (DPMS power off) after the default
>timeout (6-7 min?).

Hi,

I'm using X and an Intel graphics, so I only could try to interpret the
manpage.


$ man setterm | grep powerdown
   --powerdown [0-60]
  Sets the VESA powerdown interval in minutes.  Without an 
argument, it defaults to 0 (disable powerdown).  If the console is blanked or 
the monitor is in suspend mode, then
  the monitor will go into vsync suspend mode or powerdown mode 
respectively after this period of time has elapsed.
   --powersave powerdown
  Puts the monitor into VESA powerdown mode.

IIUC it's turned off by default. It's turned on by default, when using
X.


$ man xorg.conf | grep OffTime -A4
   Option "OffTime"  "time"
  sets the inactivity timeout for the off phase of DPMS mode.  time 
is in minutes, and the value can be changed at run-time with xset(1).  Default: 
10 minutes.  This is only
  suitable for VESA DPMS compatible monitors, and may not be 
supported by all video drivers.  It is only enabled for screens that have the 
"DPMS" option set (see the MONITOR
  section below).

$ man xorg.conf | grep n\ \"DPMS -A2
   Option "DPMS" "bool"
  This option controls whether the server should enable the DPMS 
extension for power management for this screen.  The default is to enable the 
extension.

Regards,
Ralf

[arch-general] text console no longer turns off (it blanks, but powered) after 4.12.5 or xf86-video-ati update

[David C. Rankin]

All,

  I have 2 Arch servers that boot to the default text console. It has always
properly blanked (DPMS power off) after the default timeout (6-7 min?). After
update to the 4.12.5 kernel, which occurred at the same time of the
xf86-video-ati (1:7.9.0-1 -> 1:7.9.0-2) update, the monitor no longer powers
off when the screen blanks. An hour later there is still the
blanked-but-powered light from the monitor (I don't know if this is called
backlight power for the text console rather than X).

  The problem continues after the 4.12.6 update. So there was either something
in the 4.12.5 kernel update that is preventing the console power-off from
working, or something in the xf86-video-ati update that did it.

  There is nothing in the journal about video or dpms. What else can I check
to help figure out what broke? With X at least there is xset, but I'm not sure
what to look at for the default terminal?

-- 
David C. Rankin, J.D.,P.E.

[arch-general] Unit dbus-org.freedesktop.Avahi.service not found ?

[David C. Rankin]

All,

  This isn't new, I've seen it for the past few weeks or so, but on boot, dbus
throws a journal error that avahi service cannot be found?

Aug 15 20:31:40 2pi dbus[230]: [system] Activating via systemd: service
name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
Aug 15 20:31:40 2pi dbus[230]: [system] Activation via systemd failed for unit
'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service
not found.

  It is not in /usr/share/dbus-1/services/, but it is in
/usr/share/dbus-1/system-services, e.g.

$ l /usr/share/dbus-1/system-services
total 68
drwxr-xr-x 2 root root 4096 Aug  9 03:44 .
drwxr-xr-x 8 root root 4096 Aug 10 05:18 ..
-rw-r--r-- 1 root root  971 Jul 11 15:46 org.freedesktop.Avahi.service


  I shouldn't have to manually create a link for i in
/usr/share/dbus-1/services/ should I? The wiki doesn't mention anything about
this issue.

  Can someone confirm to make sure I'm just not doing something dumb.

-- 
David C. Rankin, J.D.,P.E.

Re: [arch-general] pacman doesn't show download progress

[Ralf Mardorf]

On Tue, 15 Aug 2017 23:04:35 +0200, SET wrote:
># Misc options
>#UseSyslog
>Color
>#TotalDownload
>CheckSpace

Here a progress bar is displayed, but I'm using the "ILoveCandy" Easter
egg.

[root@archlinux ~]# grep Misc\ options -A8 /etc/pacman.conf 
# Misc options
#UseSyslog
#UseDelta
#TotalDownload
CheckSpace
#VerbosePkgLists
Color
ILoveCandy

[root@archlinux ~]# pacman -Q pacman
pacman 5.0.2-2

Re: [arch-general] pacman doesn't show download progress

[Moses Miller via arch-general]

Can you explain in more detail what the problem is, and show actual and
expected output?

On 08/15/2017 02:04 PM, SET wrote:
> Le mardi 15 août 2017 21:43:46 CEST Eli Schwartz a écrit :
>> Have you set an external downloader?
> 
> No, I'm using the default downloader.
> 
> [options]
> #RootDir = /
> #DBPath  = /var/lib/pacman/
> #CacheDir= /var/cache/pacman/pkg/
> #LogFile = /var/log/pacman.log
> #GPGDir  = /etc/pacman.d/gnupg/
> HoldPkg = pacman glibc
> #XferCommand = /usr/bin/curl -C - -f %u > %o
> #XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
> #CleanMethod = KeepInstalled
> #UseDelta= 0.7
> Architecture = auto
> IgnoreGroup = xorg
> IgnorePkg   = xf86-input-keyboard xf86-input-mouse xf86-video-vmware
> IgnorePkg   = qt5-doc minuet ocaml
> #NoUpgrade   =
> #NoExtract   =
> # Misc options
> #UseSyslog
> Color
> #TotalDownload
> CheckSpace
> 



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] pacman doesn't show download progress

[SET]

Le mardi 15 août 2017 21:43:46 CEST Eli Schwartz a écrit :
> Have you set an external downloader?

No, I'm using the default downloader.

[options]
#RootDir = /
#DBPath  = /var/lib/pacman/
#CacheDir= /var/cache/pacman/pkg/
#LogFile = /var/log/pacman.log
#GPGDir  = /etc/pacman.d/gnupg/
HoldPkg = pacman glibc
#XferCommand = /usr/bin/curl -C - -f %u > %o
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
#CleanMethod = KeepInstalled
#UseDelta= 0.7
Architecture = auto
IgnoreGroup = xorg
IgnorePkg   = xf86-input-keyboard xf86-input-mouse xf86-video-vmware
IgnorePkg   = qt5-doc minuet ocaml
#NoUpgrade   =
#NoExtract   =
# Misc options
#UseSyslog
Color
#TotalDownload
CheckSpace

Re: [arch-general] pacman doesn't show download progress

[Eli Schwartz]

On 08/15/2017 03:37 PM, SET wrote:
> pacman -Syu show database download progress but not packages being 
> downloaded. 
> They do get downloaded and installation progress is rightly displayed. This 
> can be annoying when connection speed is poor. This has been observed on 
> three 
> machines.
> 
> I am obviously requesting a solution and am ready to provide any additional 
> required information.

I'm not sure what to say, other than that I see progress every time I
download packages, unless they are already cached and therefore do not
need to be downloaded.

Have you set an external downloader?

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature

[arch-general] pacman doesn't show download progress

[SET]

pacman -Syu show database download progress but not packages being downloaded. 
They do get downloaded and installation progress is rightly displayed. This 
can be annoying when connection speed is poor. This has been observed on three 
machines.

I am obviously requesting a solution and am ready to provide any additional 
required information.

Thanks.

Re: [arch-general] Depends on foo-bar=10.0-3

[Giancarlo Razzolini]

Em agosto 15, 2017 15:58 Henrik Danielsson via arch-general escreveu:

The Gmail Android app sends HTML emails - which I forgot when replying
during my lunch break - and I'm sorry for that, but it's not something
I can do anything about.


Actually it sends multipart MIME, both HTML and text.


Unless maybe if you know of another app which behaves exactly the same
in all other regards. I'm not asking you to find one, as you probably
have no patience to help me look for one either, just name it if you
know it. Would love to use one, if it's FOSS, but so far everything
else I've seen has not even been half-decent in comparison.



Ditch HTML and use only text.


I could also suggest you instead use a client capable of displaying
HTML, then the quotes don't look that bad, but you're probably just as
unlikely to change as anyone else. ;)



The text part of your email was completely mangled, there is no quoting
whatsoever. And the HTML part does not get through because mailman removes
attachments for obvious reasons.

Now, can we please get back on topic on this thread?

Cheers,
Giancarlo Razzolini


pgpQAktBdTD0c.pgp
Description: PGP signature

Re: [arch-general] Depends on foo-bar=10.0-3

[Henrik Danielsson via arch-general]

2017-08-15 21:10 GMT+02:00 Eli Schwartz :
> Oddly enough, I use Thunderbird, which displays HTML mail fine, and
> viewing the message source tells me that message was formatted as
> (mangled) plaintext.
The one I sent first, from my phone, clearly has the header for
"multipart/alternative" and then after the delimeter we have
"text/html" and "quoted-printable".
My first response to you, and this one, are sent as text/plain from
the web interface.
Just to be sure, I checked my original message in Thunderbird as well
and I think it's still fairly readable. It's actually very close to
what all quotes on this list looks like in Gmail so maybe it's just
that I'm used to it.

Re: [arch-general] Depends on foo-bar=10.0-3

[Eli Schwartz]

On 08/15/2017 02:58 PM, Henrik Danielsson via arch-general wrote:
> I could also suggest you instead use a client capable of displaying
> HTML, then the quotes don't look that bad, but you're probably just as
> unlikely to change as anyone else. ;)

Oddly enough, I use Thunderbird, which displays HTML mail fine, and
viewing the message source tells me that message was formatted as
(mangled) plaintext.

¯\_(ツ)_/¯

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Depends on foo-bar=10.0-3

[Henrik Danielsson via arch-general]

2017-08-15 15:32 GMT+02:00 Eli Schwartz :
> I have no patience for reading people's broken quoting. Please try
> again, this time using a decent email client.
>
The Gmail Android app sends HTML emails - which I forgot when replying
during my lunch break - and I'm sorry for that, but it's not something
I can do anything about.
Unless maybe if you know of another app which behaves exactly the same
in all other regards. I'm not asking you to find one, as you probably
have no patience to help me look for one either, just name it if you
know it. Would love to use one, if it's FOSS, but so far everything
else I've seen has not even been half-decent in comparison.

I could also suggest you instead use a client capable of displaying
HTML, then the quotes don't look that bad, but you're probably just as
unlikely to change as anyone else. ;)

Re: [arch-general] Depends on foo-bar=10.0-3

[Martin Kühne via arch-general]

Someone call 911, another trainwreck thread on [arch-general].
Watching the carnage ensue is not as much fun as it should be though,
so long after responders no longer pretend to care.

That being said, we should definitely add a versioned dependency
between fuse-common and sshfs. Just because my mirror failed me
recently.

cheers!
mar77i

Re: [arch-general] Depends on foo-bar=10.0-3

[Eli Schwartz]

I have no patience for reading people's broken quoting. Please try
again, this time using a decent email client.



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Depends on foo-bar=10.0-3

[Ralf Mardorf]

OT: If for some reason proper quoting should be broken, top-posting
could be a better solution, than very broken bottom-posting, let
alone the broken interleaved posting of a previous reply.

Re: [arch-general] Depends on foo-bar=10.0-3

[Henrik Danielsson via arch-general]

Den 15 aug. 2017 13:46 skrev "Eli Schwartz" :

On 08/15/2017 03:47 AM, Paul Gideon Dann via arch-general wrote:
> Yes, partial upgrades are unsupported, but in practice this still happens,
> usually not deliberately. For instance, I will quite often do a "pacman -S
> " without doing a full system update first, assuming that
> *probably* nothing important has changed since the last update. It's a
> sloppy practice, but humans cut corners: it happens. When a plugin relies
> on a potentially unstable ABI (not many applications offer stable ABIs),
> specifying that the plugin package requires that exact version of the
> application will ensure that mistakes like this don't happen.
>
> If I see an error like "package x requires y=1.2.3" when installing a
> package, the first thing I'll try is a system update, an obscure segfault
> is avoided, and everyone's happy. So the failsafe does the job. It's good
> defensive practice by the packaging team, I think.

What.

No, the packaging team explicitly does not care about you, and official
policy is to yell at you for having once upon a time run pacman -Sy
without -u

I'm guessing that happens a lot though. Being explicit about the version
for a module makes pacman itself handle the most obvious problems that
would generate "support requests". If something did break long after you
did those steps it may not be obvious you installed the main package and
the module out-of-sync, so someone may yell at the packagers or devs for
"introducing regressions/bugs" causes by this.

Maybe they do care about the time they would spend yelling back at you if
this was not the case?

That is pretty deliberate on your part.

--
Eli Schwartz

Re: [arch-general] Depends on foo-bar=10.0-3

[Eli Schwartz]

On 08/15/2017 03:47 AM, Paul Gideon Dann via arch-general wrote:
> Yes, partial upgrades are unsupported, but in practice this still happens,
> usually not deliberately. For instance, I will quite often do a "pacman -S
> " without doing a full system update first, assuming that
> *probably* nothing important has changed since the last update. It's a
> sloppy practice, but humans cut corners: it happens. When a plugin relies
> on a potentially unstable ABI (not many applications offer stable ABIs),
> specifying that the plugin package requires that exact version of the
> application will ensure that mistakes like this don't happen.
> 
> If I see an error like "package x requires y=1.2.3" when installing a
> package, the first thing I'll try is a system update, an obscure segfault
> is avoided, and everyone's happy. So the failsafe does the job. It's good
> defensive practice by the packaging team, I think.

What.

No, the packaging team explicitly does not care about you, and official
policy is to yell at you for having once upon a time run pacman -Sy
without -u
That is pretty deliberate on your part.

-- 
Eli Schwartz



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] Depends on foo-bar=10.0-3

[Paul Gideon Dann via arch-general]

On 14 August 2017 at 13:48, Ralf Mardorf  wrote:

> On Mon, 14 Aug 2017 14:03:45 +0200, mpan wrote:
> >> why does a package from official repositories mentions what version
> >> of a dependency is required?
> >Because it may be that it is working only with that particular
> >version.
>
> That doesn't explain why it is needed or in any way useful for a package
> provided by official Arch repositories? Partial upgrades are
> unsupported [1]. Actually it could be vary annoying, if packages now
> start including the version of a dependency. I didn't notice that
> packages mention dependency versions for at least the last 4 years [2].
> It's not the only dummy package I'm using for at least that long.
>

Yes, partial upgrades are unsupported, but in practice this still happens,
usually not deliberately. For instance, I will quite often do a "pacman -S
" without doing a full system update first, assuming that
*probably* nothing important has changed since the last update. It's a
sloppy practice, but humans cut corners: it happens. When a plugin relies
on a potentially unstable ABI (not many applications offer stable ABIs),
specifying that the plugin package requires that exact version of the
application will ensure that mistakes like this don't happen.

If I see an error like "package x requires y=1.2.3" when installing a
package, the first thing I'll try is a system update, an obscure segfault
is avoided, and everyone's happy. So the failsafe does the job. It's good
defensive practice by the packaging team, I think.

Paul