~sorrow

Recent activity

Re: -s/-S/-d options do not work as expected 2 years ago

From Sorrow to ~kennylevinsen/wlsunset-devel

I tested it, it works absolutely the same.

On 04/05/2022 19.13, Kenny Levinsen wrote:
> Can I get you to try the timezone branch? 
> https://git.sr.ht/~kennylevinsen/wlsunset/log/timezone

Re: -s/-S/-d options do not work as expected 2 years ago

From Sorrow to ~kennylevinsen/wlsunset-devel

I started wlsunset yesterday with desirable for me -S and -s option 
values (by local time). At the specified time of sunset it started 
gradually decreasing the colour temperature until the calculated time of 
dusk. But at the calculated time of dawn happened as well as at the 
specified time of sunrise. Only at 10:00 it suddenly reverted the colour 
temperature back to normal, without any gradual change. I must say that 
I live in UTC+10 timezone, so my local 10:00 is UTC 0:00.

On 02/05/2022 22.04, Kenny Levinsen wrote:
> Just specify what the time would be in UTC-land - if you want sunrise 
> at 6AM your time, and you're in UTC+4, you say 2AM instead.
>
> It's a little clumsy, but it'll take a bit before I have time to look 
> at fixing the manual time input. Automatic calculation using 

Re: -s/-S/-d options do not work as expected 2 years ago

From Sorrow to ~kennylevinsen/wlsunset-devel

Nah, this doesn't work. At least sunset time is interpreted as a local 
time, that's for sure.

On 02/05/2022 22.04, Kenny Levinsen wrote:
> Just specify what the time would be in UTC-land - if you want sunrise 
> at 6AM your time, and you're in UTC+4, you say 2AM instead.
>
> It's a little clumsy, but it'll take a bit before I have time to look 
> at fixing the manual time input. Automatic calculation using 
> latitude/longitude is the primary way to use wlsunset.
>
>

Re: -s/-S/-d options do not work as expected 2 years ago

From Sorrow to ~kennylevinsen/wlsunset-devel

How to input the time as UTC? Is there some kind of format to input a 
timezone with the time?

On 02/05/2022 19.19, Kenny Levinsen wrote:
> This could be a timezone issue. Can you try to input the time as UTC?
>
> wlsunset operates entirely in UTC internally to normalize time against 
> orbit calculations, but as a side-effect the manual time input is 
> currently also UTC. It's a little annoying to fix in a portable way 
> (i.e. works both on Linux and FreeBSD), so I haven't looked at it yet.
>
>

-s/-S/-d options do not work as expected 2 years ago

From Sorrow to ~kennylevinsen/wlsunset-devel

I run wlsunset as `wlsunset -S 6:00 -s 20:00 -d 3600 -t 2800`, I even 
tried changing it to `-S 4:00`, but no matter what I do, in the morning 
the colour temperature change persists until 10:00 and then changes to 
normal suddenly without any transition. Why could it be?

Ability to control screen backlight brightness 2 years ago

From Sorrow to ~kennylevinsen/wlsunset-devel

The only reason I still haven't moved from gammastep is it's ability to 
dim the screen backlight at night. Is it possible to add this feature to 
this project?

Re: Mercurial tag tarball download gives dfferent checksum every time 4 years ago

From Eternal Sorrow to ~sircmpwn/sr.ht-discuss

On 3/7/20 11:07 PM, Malcolm Matalka wrote:
> Eternal Sorrow <lynx1534@gmail.com> writes:
>
>> On 3/7/20 10:47 PM, Malcolm Matalka wrote:
>>> Eternal Sorrow <lynx1534@gmail.com> writes:
>>>
>>>>> When I download the tarball generated for Mercurial tag (for example
>>>>> https://hg.sr.ht/~scoopta/wofi/archive/v1.0.tar.gz), it has different
>>>>> checksum every time I download it. Is there something that can be done
>>>>> with this, so that the checksum would be consistent, like GitHub
>>>>> downloads for example?
>>>> Is anyone interested in this?
>>> I don't believe hg archive guarantees the output will match between

Re: Mercurial tag tarball download gives dfferent checksum every time 4 years ago

From Eternal Sorrow to ~sircmpwn/sr.ht-discuss

On 3/7/20 10:47 PM, Malcolm Matalka wrote:
> Eternal Sorrow <lynx1534@gmail.com> writes:
>
>>> When I download the tarball generated for Mercurial tag (for example
>>> https://hg.sr.ht/~scoopta/wofi/archive/v1.0.tar.gz), it has different
>>> checksum every time I download it. Is there something that can be done
>>> with this, so that the checksum would be consistent, like GitHub
>>> downloads for example?
>> Is anyone interested in this?
> I don't believe hg archive guarantees the output will match between
> runs, although you might get lucky.
>
> I have a build job that performs an archive and tosses the result on S3

Re: Mercurial tag tarball download gives dfferent checksum every time 4 years ago

From Eternal Sorrow to ~sircmpwn/sr.ht-discuss

> When I download the tarball generated for Mercurial tag (for example
> https://hg.sr.ht/~scoopta/wofi/archive/v1.0.tar.gz), it has different
> checksum every time I download it. Is there something that can be done
> with this, so that the checksum would be consistent, like GitHub
> downloads for example?
Is anyone interested in this?

Mercurial tag tarball download gives dfferent checksum every time 4 years ago

From Eternal Sorrow to ~sircmpwn/sr.ht-discuss

When I download the tarball generated for Mercurial tag (for example 
https://hg.sr.ht/~scoopta/wofi/archive/v1.0.tar.gz), it has different 
checksum every time I download it. Is there something that can be done 
with this, so that the checksum would be consistent, like GitHub 
downloads for example?