Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Am 2023-05-15 um 22:36 schrieb Yuri:

Yuri wrote:

Michael Osipov wrote:

Am 2023-05-15 um 22:19 schrieb Yuri:

Michael Osipov wrote:

Am 2023-05-15 um 21:37 schrieb Glen Barber:

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.



I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.


Thank you! I have verified the patch back then, will happily re-verify
if requested to.


I just tried this (without patching):

$ cat ~/.login_conf
me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
$ env | egrep 'FOO|BAR|BAZ'
BAZ=foo,bar
BAR=baz
FOO=bar


Not in /etc/login.conf:

$ grep NO /etc/login.conf
     :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4
-R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO
NO_PROXY='localhost


Weird, works for me running main-n262913-bee3d4bf8ed5:

$ grep NO_PROXY /etc/login.conf
 :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO_PROXY
NO_PROXY=localhost,*.siemens.net


Oh, the fix is in there:

commit f32db406504ece1b28f43dc816736e081fe22826
Author: Sean Eric Fagan 
Date:   Sat Jan 14 10:37:31 2023 -0800

 Allow a comma-separated list in login class capabilities,
 by adding a version of strcspn that allows quoting.

So what exactly are we talking about here? :-)


I am on 12-STABLE, and reported on that. Tried back than on 13, it was 
broken as well. You might want to try 14 with double quotes and see if 
it works. If at least one works, docs need to be updated for sure, and 
also make sure that in single quotes escapes like \c for colon still work.


I'll try a VM with a main snapshot as well tomorrow.

M

Re: Delay in 14.0-RELEASE cycle and blocking items

[Yuri]

Yuri wrote:
> Michael Osipov wrote:
>> Am 2023-05-15 um 22:19 schrieb Yuri:
>>> Michael Osipov wrote:
 Am 2023-05-15 um 21:37 schrieb Glen Barber:
> On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
>> Glen,
>>
>> do you see any chance to get this finally merged:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
>>
>> It seriously affects people (in enterprises) behind a proxy, curl will
>> be a problem and py-requests is already a serious problem.
>>
>
> I have bumped the bug, and pinged sef@ and cc'd re@ as a result.
>
> I do not see a problem with it, as long as it is a proper fix.

 Thank you! I have verified the patch back then, will happily re-verify
 if requested to.
>>>
>>> I just tried this (without patching):
>>>
>>> $ cat ~/.login_conf
>>> me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
>>> $ env | egrep 'FOO|BAR|BAZ'
>>> BAZ=foo,bar
>>> BAR=baz
>>> FOO=bar
>>
>> Not in /etc/login.conf:
>>> $ grep NO /etc/login.conf
>>>     :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4
>>> -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
>>> $ env | grep NO
>>> NO_PROXY='localhost
> 
> Weird, works for me running main-n262913-bee3d4bf8ed5:
> 
> $ grep NO_PROXY /etc/login.conf
> :setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\
> $ env | grep NO_PROXY
> NO_PROXY=localhost,*.siemens.net

Oh, the fix is in there:

commit f32db406504ece1b28f43dc816736e081fe22826
Author: Sean Eric Fagan 
Date:   Sat Jan 14 10:37:31 2023 -0800

Allow a comma-separated list in login class capabilities,
by adding a version of strcspn that allows quoting.

So what exactly are we talking about here? :-)

Re: Delay in 14.0-RELEASE cycle and blocking items

[Yuri]

Michael Osipov wrote:
> Am 2023-05-15 um 22:19 schrieb Yuri:
>> Michael Osipov wrote:
>>> Am 2023-05-15 um 21:37 schrieb Glen Barber:
 On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
> Glen,
>
> do you see any chance to get this finally merged:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
>
> It seriously affects people (in enterprises) behind a proxy, curl will
> be a problem and py-requests is already a serious problem.
>

 I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

 I do not see a problem with it, as long as it is a proper fix.
>>>
>>> Thank you! I have verified the patch back then, will happily re-verify
>>> if requested to.
>>
>> I just tried this (without patching):
>>
>> $ cat ~/.login_conf
>> me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
>> $ env | egrep 'FOO|BAR|BAZ'
>> BAZ=foo,bar
>> BAR=baz
>> FOO=bar
> 
> Not in /etc/login.conf:
>> $ grep NO /etc/login.conf
>>     :setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4
>> -R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
>> $ env | grep NO
>> NO_PROXY='localhost

Weird, works for me running main-n262913-bee3d4bf8ed5:

$ grep NO_PROXY /etc/login.conf
:setenv=BLOCKSIZE=K,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO_PROXY
NO_PROXY=localhost,*.siemens.net

Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Am 2023-05-15 um 22:19 schrieb Yuri:

Michael Osipov wrote:

Am 2023-05-15 um 21:37 schrieb Glen Barber:

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.



I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.


Thank you! I have verified the patch back then, will happily re-verify
if requested to.


I just tried this (without patching):

$ cat ~/.login_conf
me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
$ env | egrep 'FOO|BAR|BAZ'
BAZ=foo,bar
BAR=baz
FOO=bar


Not in /etc/login.conf:

$ grep NO /etc/login.conf
:setenv=BLOCKSIZE=K,LSCOLORS=ExGxFxdxCxDxDxhbadExEx,LESS=-x4 
-R,EDITOR=vim,LANG=de_DE.UTF-8,CLICOLOR=YES,NO_PROXY='localhost,*.siemens.net':\
$ env | grep NO
NO_PROXY='localhost

Re: Delay in 14.0-RELEASE cycle and blocking items

[Yuri]

Michael Osipov wrote:
> Am 2023-05-15 um 21:37 schrieb Glen Barber:
>> On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
>>> Glen,
>>>
>>> do you see any chance to get this finally merged:
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
>>>
>>> It seriously affects people (in enterprises) behind a proxy, curl will
>>> be a problem and py-requests is already a serious problem.
>>>
>>
>> I have bumped the bug, and pinged sef@ and cc'd re@ as a result.
>>
>> I do not see a problem with it, as long as it is a proper fix.
> 
> Thank you! I have verified the patch back then, will happily re-verify
> if requested to.

I just tried this (without patching):

$ cat ~/.login_conf
me:setenv=FOO=bar,BAR=baz,BAZ='foo,bar':
$ env | egrep 'FOO|BAR|BAZ'
BAZ=foo,bar
BAR=baz
FOO=bar

It looks like single-quotes should do the trick, and we simply need to
document this?

Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Am 2023-05-15 um 21:37 schrieb Glen Barber:

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.



I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.


Thank you! I have verified the patch back then, will happily re-verify
if requested to.

Michael

Re: Delay in 14.0-RELEASE cycle and blocking items

[Glen Barber]

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
> Glen,
> 
> do you see any chance to get this finally merged:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
> 
> It seriously affects people (in enterprises) behind a proxy, curl will
> be a problem and py-requests is already a serious problem.
> 

I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.

Glen



signature.asc
Description: PGP signature

Re: Delay in 14.0-RELEASE cycle and blocking items

[Tomek CEDRO]

Thanks Glen, no rush, quality first, it takes time :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Delay in 14.0-RELEASE cycle and blocking items

[Michael Osipov]

Glen,

do you see any chance to get this finally merged:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?

It seriously affects people (in enterprises) behind a proxy, curl will
be a problem and py-requests is already a serious problem.

Michael

Re: 20230504 -CURRENT snapshot panics during install at zfs probing

[Rebecca Cran]

On 5/15/23 07:17, Rebecca Cran wrote:


I'll open a bug report so the details don't get lost.


I've created https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271438 .

--

Rebecca Cran

Re: 20230504 -CURRENT snapshot panics during install at zfs probing

[Rebecca Cran]

On 5/15/23 07:09, José Pérez wrote:



I recall exepriencing a similar issue with a SuperMicro server and I 
think I worked this around by adding hw.mfi.mrsas_enable="1" to 
/boot/device.hints in order to have FreeBSD booting from the SAS disks.


Unfortunately I do not have access to that hardware anymore (it is 
running AnotherOS and cannot be taken out of production).


I still recommend you do open a bug with the details you have so far, 
having FreeBSD on server with SAS disks is not a sin ;) and software 
causing memory corruption shall be fixed anyways.


Thanks. I wanted to boot FreeBSD from the BOSS-1 drive (NVMe) so I 
worked around it by disabling the mrsas controller during install then 
re-enabling it later.


I'll open a bug report so the details don't get lost.


--

Rebecca Cran

Re: 20230504 -CURRENT snapshot panics during install at zfs probing

[José Pérez]

El 2023-05-05 13:31, Rebecca Cran escribió:

I also tried FreeBSD 13.2 and it's unhappy too, and ends up panicing
and rebooting when trying to restart the installer after it segfaults.
So it's apparently _not_ a new problem.

I'm guessing there's something about my disks that's causing memory
corruption. The only thing that's changed recently is installing
Windows Server 2022 on a different disk.

If I disable the mrsas controller, installation proceeds.


--
Rebecca Cran


On 5/4/23 19:02, Rebecca Cran wrote:
I'm seeing a panic during install during the zfs probing on the 
14-CURRENT 20230504 amd64 snapshot on a PowerEdge R7525 dual-EPYC 
system.


I haven't submitted a bug report for a while, so let me know what 
other information is needed.



Unfortunately the stack backtrace looks useless:


Hi,
I recall exepriencing a similar issue with a SuperMicro server and I 
think I worked this around by adding hw.mfi.mrsas_enable="1" to 
/boot/device.hints in order to have FreeBSD booting from the SAS disks.


Unfortunately I do not have access to that hardware anymore (it is 
running AnotherOS and cannot be taken out of production).


I still recommend you do open a bug with the details you have so far, 
having FreeBSD on server with SAS disks is not a sin ;) and software 
causing memory corruption shall be fixed anyways.


--
José Pérez

Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?

[Oleg Lelchuk]

I got it.

On Mon, May 15, 2023, 8:32 AM Toomas Soome  wrote:

>
>
> On 15. May 2023, at 15:22, Oleg Lelchuk  wrote:
>
> Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned
> in the previous email message... I find it a bit surprising that I only had
> to make one tiny change to the source code of stand to make the graphical
> logo appear, to start playing with the EFI resolution, and etc.
>
>
> The font size/resolution is difficult topic. The implementation itself can
> choose “good enough” variant and then some people are happy and some people
> are unhappy.
>
> The current loader UI is built on terminal dimensions (which depend on
> glyph size and resolution), and there the traditional assumption is that we
> have 80x24 terminal. With different fonts and depending on how much screen
> space we want to leave unused, we can get different dimensions for terminal.
>
> And since there is quite a variation of displays, the challenge is to get
> decent enough visual on most commonly used displays - so there can be
> pressure to use fixed resolution etc. And this is also the reason, why you
> see very simple boot screens with something like spinning wheel on some
> other systems.
>
> rgds,
> toomas
>
>
> On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk  wrote:
>
>> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced
>> ConOut with ConIn in this line: rv = efi_global_getenv("ConIn", buf, );
>> . Now I am able to see the beautiful graphical logo in the efi boot menu!
>> But why are the boot menu and the logo shown in the top left corner of my
>> computer screen? My monitor is 1080p and the setting
>> efi_max_resolution=1080p in loader.conf only affects what happens after the
>> kernel starts booting up, but it doesn't affect what happens before it: the
>> boot menu and the logo remain in the top left corner of the screen. Why is
>> this the case? You can see the photo in the provided attachment... And
>> thank you, guys, for your work!
>>
>> On Sat, May 13, 2023 at 9:35 AM Warner Losh  wrote:
>>
>>>
>>>
>>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk 
>>> wrote:
>>>
 I've been reading the documentation for loader.efi and it says this:
 "If there is no ConOut variable, both serial and video are attempted.
  loader.efi uses the "efi" console for the video (which may or may
 not
  work) and "comconsole" for the serial on COM1 at the default baud
 rate.
  The kernel will use a dual console, with the video console primary
 if a
  UEFI graphics device is detected, or the serial console as primary
 if
  not."
 I find this language confusing because I don't know what is meant by "a
 UEFI graphics device". In my situation, is my Intel Integrated Graphics
 card an UEFI graphics device? Does it mean that once i915kms is loaded, I
 no longer deal with UEFI graphics? I think lots of people whose native
 language is English will find the documentation describing loader.efi
 confusing. The documentation page also mentions this: "BUGS
  Systems that do not have a ConOut variable set are not conformant
 with
  the standard, and likely have unexpected results." But I think you
 guys already implied that the UEFI specification doesn't mandate having
 such a variable.

>>>
>>> That's unclear. The standard refers to it many times. Earlier versions
>>> especially. It doesn't say it's optional, unlike some other variables. Yet
>>> later versions don't say it's mandatory.  I've yet to own or use a system
>>> without it... such systems exist but they are quite new...
>>>
>>> Warner
>>>
>>> On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk 
 wrote:

> I got it. Thanks.
>
> On Fri, May 12, 2023 at 7:45 PM Ed Maste  wrote:
>
>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk 
>> wrote:
>> >
>> > I don't want to go through the hassle of filling a bug with my
>> vendor. I will just wait for you, guys, to update the stand 
>> implementation.
>> Thank you for explaining to me what causes this issue.
>>
>> This issue is tracked in PR 265980 if you want to follow it.
>> https://bugs.freebsd.org/265980
>>
>
>

Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?

[Toomas Soome]

> On 15. May 2023, at 15:22, Oleg Lelchuk  wrote:
> 
> Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned in 
> the previous email message... I find it a bit surprising that I only had to 
> make one tiny change to the source code of stand to make the graphical logo 
> appear, to start playing with the EFI resolution, and etc.

The font size/resolution is difficult topic. The implementation itself can 
choose “good enough” variant and then some people are happy and some people are 
unhappy.

The current loader UI is built on terminal dimensions (which depend on glyph 
size and resolution), and there the traditional assumption is that we have 
80x24 terminal. With different fonts and depending on how much screen space we 
want to leave unused, we can get different dimensions for terminal.

And since there is quite a variation of displays, the challenge is to get 
decent enough visual on most commonly used displays - so there can be pressure 
to use fixed resolution etc. And this is also the reason, why you see very 
simple boot screens with something like spinning wheel on some other systems.

rgds,
toomas

> 
> On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk  > wrote:
>> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced ConOut 
>> with ConIn in this line: rv = efi_global_getenv("ConIn", buf, ); . Now I 
>> am able to see the beautiful graphical logo in the efi boot menu! But why 
>> are the boot menu and the logo shown in the top left corner of my computer 
>> screen? My monitor is 1080p and the setting efi_max_resolution=1080p in 
>> loader.conf only affects what happens after the kernel starts booting up, 
>> but it doesn't affect what happens before it: the boot menu and the logo 
>> remain in the top left corner of the screen. Why is this the case? You can 
>> see the photo in the provided attachment... And thank you, guys, for your 
>> work!
>> 
>> On Sat, May 13, 2023 at 9:35 AM Warner Losh > > wrote:
>>> 
>>> 
>>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk >> > wrote:
 I've been reading the documentation for loader.efi and it says this: "If 
 there is no ConOut variable, both serial and video are attempted.
  loader.efi uses the "efi" console for the video (which may or may not
  work) and "comconsole" for the serial on COM1 at the default baud 
 rate.
  The kernel will use a dual console, with the video console primary if 
 a
  UEFI graphics device is detected, or the serial console as primary if
  not."
 I find this language confusing because I don't know what is meant by "a 
 UEFI graphics device". In my situation, is my Intel Integrated Graphics 
 card an UEFI graphics device? Does it mean that once i915kms is loaded, I 
 no longer deal with UEFI graphics? I think lots of people whose native 
 language is English will find the documentation describing loader.efi 
 confusing. The documentation page also mentions this: "BUGS
  Systems that do not have a ConOut variable set are not conformant with
  the standard, and likely have unexpected results." But I think you 
 guys already implied that the UEFI specification doesn't mandate having 
 such a variable.
>>> 
>>> 
>>> That's unclear. The standard refers to it many times. Earlier versions 
>>> especially. It doesn't say it's optional, unlike some other variables. Yet 
>>> later versions don't say it's mandatory.  I've yet to own or use a system 
>>> without it... such systems exist but they are quite new...
>>> 
>>> Warner
>>> 
 On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk >>> > wrote:
> I got it. Thanks.
> 
> On Fri, May 12, 2023 at 7:45 PM Ed Maste  > wrote:
>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk > > wrote:
>> >
>> > I don't want to go through the hassle of filling a bug with my vendor. 
>> > I will just wait for you, guys, to update the stand implementation. 
>> > Thank you for explaining to me what causes this issue.
>> 
>> This issue is tracked in PR 265980 if you want to follow it.
>> https://bugs.freebsd.org/265980

Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?

[Oleg Lelchuk]

Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned
in the previous email message... I find it a bit surprising that I only had
to make one tiny change to the source code of stand to make the graphical
logo appear, to start playing with the EFI resolution, and etc.

On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk  wrote:

> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced ConOut
> with ConIn in this line: rv = efi_global_getenv("ConIn", buf, ); . Now I
> am able to see the beautiful graphical logo in the efi boot menu! But why
> are the boot menu and the logo shown in the top left corner of my computer
> screen? My monitor is 1080p and the setting efi_max_resolution=1080p in
> loader.conf only affects what happens after the kernel starts booting up,
> but it doesn't affect what happens before it: the boot menu and the logo
> remain in the top left corner of the screen. Why is this the case? You can
> see the photo in the provided attachment... And thank you, guys, for your
> work!
>
> On Sat, May 13, 2023 at 9:35 AM Warner Losh  wrote:
>
>>
>>
>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk  wrote:
>>
>>> I've been reading the documentation for loader.efi and it says this: "If
>>> there is no ConOut variable, both serial and video are attempted.
>>>  loader.efi uses the "efi" console for the video (which may or may
>>> not
>>>  work) and "comconsole" for the serial on COM1 at the default baud
>>> rate.
>>>  The kernel will use a dual console, with the video console primary
>>> if a
>>>  UEFI graphics device is detected, or the serial console as primary
>>> if
>>>  not."
>>> I find this language confusing because I don't know what is meant by "a
>>> UEFI graphics device". In my situation, is my Intel Integrated Graphics
>>> card an UEFI graphics device? Does it mean that once i915kms is loaded, I
>>> no longer deal with UEFI graphics? I think lots of people whose native
>>> language is English will find the documentation describing loader.efi
>>> confusing. The documentation page also mentions this: "BUGS
>>>  Systems that do not have a ConOut variable set are not conformant
>>> with
>>>  the standard, and likely have unexpected results." But I think you
>>> guys already implied that the UEFI specification doesn't mandate having
>>> such a variable.
>>>
>>
>> That's unclear. The standard refers to it many times. Earlier versions
>> especially. It doesn't say it's optional, unlike some other variables. Yet
>> later versions don't say it's mandatory.  I've yet to own or use a system
>> without it... such systems exist but they are quite new...
>>
>> Warner
>>
>> On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk 
>>> wrote:
>>>
 I got it. Thanks.

 On Fri, May 12, 2023 at 7:45 PM Ed Maste  wrote:

> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk 
> wrote:
> >
> > I don't want to go through the hassle of filling a bug with my
> vendor. I will just wait for you, guys, to update the stand 
> implementation.
> Thank you for explaining to me what causes this issue.
>
> This issue is tracked in PR 265980 if you want to follow it.
> https://bugs.freebsd.org/265980
>