Re: adding a disk to a Volume group

[mick crane]

On 2020-12-20 20:38, Charles Curley wrote:

On Sun, 20 Dec 2020 19:05:45 +
mick crane  wrote:


It's a more or less new bullseye installation.
The installer kindly set up a Volume Group and added Logical Volumes
of a couple of the partitions on the disk with the OS on it.
I want to add another disk to use for data.


A couple of thoughts here.

* Are you adding the new disk permanently or as removable media?

  If the latter, put a separate VG on it. Or don't bother. The reason I
  suggest this is if the new disk is removable, having the same VG span
  both disks may make the permanent disk unusable if the removable one
  is gone.

  If it is permanent, consider redoing both of them as a RAID level
  1, with encryption and LVM on top of that. Be sure to leave a boot
  partition on at least one of them.

* You said nothing about encryption. That may impact the order in which
  you do things.


From what I can gather there's not much point adding new disk to the LVM 
if I'm going to use the whole disk as one partition so I formatted it 
ext4 and mount it somewhere in my home directory.


The default netinstaller doesn't seem to make the boot partition big 
enough as with the vmlinux off the install media then vmlinux.old and 
new vmlinux the device was out of space if upgrade so had to remove the 
original kernel gubbins from the install media. At least that seems to 
be what happened.
I'll have to understand LVM at some point to see if I can make boot LV 
bigger.


mick

--
Key ID4BFEBB31

Re: pinentry-{qt,gtk2,gnome3} stopped working pinentry-fltk works, why?

[deloptes]

Gregor Zattler wrote:

> This is on a buster system with gpg* packages from backports,
> pinentry* packages from buster (since there are no backports).
> 
> Any ideas how to re-enable pinentry-qt (which displays most
> info about the key in question)?

why would you install gpg from backports?

If you install one - install all. Things changing in gpg impact the other
systems too.
I can not exclude issues with the related (pinentry* packages), but either
install all from the current or from the backports

Re: NULL pointer dereference

[deloptes]

Grzesiek Sójka wrote:

> btw I think it started after installing HPE Ethernet 1Gb 4-port 331T
> Adapter. This is server adapter end requires PCIe pin B5 and B6 covering
> to disconnect SMBus

come on, this is important and you did not mention it! Shame on you :)

now try removing the card and see if it is happening again.

Why would you disconnect SMBus?

pinentry-{qt,gtk2,gnome3} stopped working pinentry-fltk works, why?

[Gregor Zattler]

Dear fellow debian users, since yesterday pinentry-{qt,gtk2,gnome3}
stopped working.  When I want to decrypt some .gpg file, no dialog
appears and gpg-agent times out.  Luckily pinentry-curses and
pinentry-fltk still do work.

This is on a buster system with gpg* packages from backports,
pinentry* packages from buster (since there are no backports).

Any ideas how to re-enable pinentry-qt (which displays most
info about the key in question)?


Ciao, Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

Re: NULL pointer dereference

[Grzesiek Sójka]

On 12/20/20 10:22 PM, Marko Randjelovic wrote:
> How often does this happen?

Not too often, once per few days.

Does it happen only on high load?

Difficult to say, rather not.

> I'm asking
> because you might boot live system with newest kernel possible to see
> if this will happen. Also you can simply try with backported kernel
> 5.9.6.

Thanks for the tip

btw I think it started after installing HPE Ethernet 1Gb 4-port 331T 
Adapter. This is server adapter end requires PCIe pin B5 and B6 covering 
to disconnect SMBus

Re: NULL pointer dereference

[Grzesiek Sójka]

On 12/19/20 9:57 PM, Alexander V. Makartsev wrote:
If this is recurring error, was it identical in terms of codes, trace 
and register data?


Errors look similar but I'm not an expert. Some numbers are different.

I think it started after installing HPE Ethernet 1Gb 4-port 331T 
Adapter. This is server adapter end requires PCIe pin B5 and B6 covering 
to disconnect SMBus

Re: [1/2HS] un virus Mirai offensif pour Linux

[l0f4r0]

Discussions sur :
* https://linuxfr.org/users/devede/journaux/virus-mirai-dans-ventoy
* https://github.com/ventoy/Ventoy/issues/660
* https://forums.linuxmint.com/viewtopic.php?f=61=337872
* 
http://www.gratilog.net/xoops/modules/newbb/viewtopic.php?start=0_id=17344=flat=ASC

l0f4r0

Re: Nieuwste versie tcl, sqlite en DB Browser

[Paul van der Vlis]

Op 20-12-2020 om 21:51 schreef Cecil Westerhof:

Paul van der Vlis  writes:



Ik heb (nog) niet naar SQLite en sqlitebrowser gekeken. Het gaat me in
eerste instantie om tcl. En testing heeft net als Buster versie 8.6.9
i.p.v. 8.6.10 van tcl.


Nee, toch wel versie 8.6.10:
https://packages.debian.org/search?keywords=tcl8.6


(Daarnaast heeft tcl 8.6.10 eigenlijk een net te oude versie van
SQLite ingebakken. 8.6.9 heeft 3.27.2 en 8.6.10 heeft 3.30.1 en ik ben
geïnteresseerd in 3.31.0 of hoger.)


In experimental heb je tcl8.7 en tcl9. Maar dat zijn alpha versies.

Groet,
Paul

--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: NULL pointer dereference

[Marko Randjelovic]

On Sat, 19 Dec 2020 17:13:13 +0100
Grzesiek Sójka  wrote:

> Hi there,
> 
> I found the following in my "server" log:
> 
> ==
> 
> BUG: unable to handle kernel NULL pointer dereference at 0008
> PGD 0 P4D 0
> Oops:  [#2] SMP PTI
> CPU: 5 PID: 12441 Comm: awk Tainted: G  D   4.19.0-13-amd64 
> #1 Debian 4.19.160-2
> Hardware name: FUJITSU D3162-B1/D3162-B1, BIOS V4.6.5.3 R1.23.0 for 
> D3162-B1x 12/01/2014
> RIP: 0010:unmap_page_range+0x561/0xa60
> Code: 80 00 00 00 01 e8 4f 2b 01 00 49 8b 07 f6 c4 80 0f 84 0e 03 00 00 
> 4c 89 ff e8 6b 91 fe ff 85 c0 0f 88 e6 02 00 00 49 8b 46 28 <8b> 50 08 
> 8d 4a 01 89 48 08 4c 89 7c d0 10 3b 48 0c 0f 84 d2 00 00
> RSP: 0018:9c3a49167cd0 EFLAGS: 00010206
> RAX:  RBX: 8e2f47a83a10 RCX: 0001
> RDX:  RSI:  RDI: 8e2f7dd2
> RBP: 7faa2ed43000 R08:  R09: 8e2ef8ae1c70
> R10: 8e2f9e5df000 R11:  R12: 7faa2ed42000
> R13: 00014fd44025 R14: 9c3a49167dd0 R15: d073853f5100
> FS:  () GS:8e2f7e14() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0008 CR3: 00015020a003 CR4: 000606e0
> Call Trace:
>   unmap_vmas+0x7f/0xb0
>   exit_mmap+0xaa/0x180
>   mmput+0x54/0x130
>   do_exit+0x33f/0xbb0
>   ? handle_mm_fault+0xd6/0x200
>   do_group_exit+0x3a/0xa0
>   __x64_sys_exit_group+0x14/0x20
>   do_syscall_64+0x53/0x110
>   entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7faa2eaa99d6
> Code: Bad RIP value.
> RSP: 002b:7ffd860931d8 EFLAGS: 0246 ORIG_RAX: 00e7
> RAX: ffda RBX: 7faa2eb9a760 RCX: 7faa2eaa99d6
> RDX:  RSI: 003c RDI: 
> RBP:  R08: 00e7 R09: ff80
> R10: 7ffd86093096 R11: 0246 R12: 7faa2eb9a760
> R13: 0001 R14: 7faa2eba3428 R15: 
> Modules linked in: ppp_deflate cfg80211 rfkill 8021q garp stp mrp llc 
> ppp_async crc_ccitt ppp_generic slhc nfsd auth_rpcgss nfs_acl lockd 
> grace sunrpc xt_nat nft_chain_nat_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
> nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ipt_REJECT nf_reject_ipv4 
> nft_limit xt_limit xt_tcpudp nft_compat x_tables nft_counter nf_tables 
> nfnetlink binfmt_misc bonding sch5636 sch56xx_common rc_it913x_v1 it913x 
> af9033 dvb_usb_af9035 dvb_usb_v2 dvb_core rc_core snd_hda_codec_hdmi 
> snd_hda_codec_conexant snd_hda_codec_generic intel_rapl i915 
> x86_pkg_temp_thermal snd_hda_intel intel_powerclamp snd_hda_codec 
> coretemp snd_hda_core snd_hwdep snd_pcm xhci_pci ehci_pci ahci snd_timer 
> xhci_hcd drm_kms_helper ehci_hcd libahci kvm snd mei_wdt tg3 iTCO_wdt 
> irqbypass mei_me e1000e drm libata usbcore
>   iTCO_vendor_support soundcore lpc_ich libphy mei i2c_algo_bit 
> usb_common mfd_core crct10dif_pclmul crc32_pclmul ppdev 
> ghash_clmulni_intel sg i2c_i801 intel_cstate evdev intel_uncore 
> pcc_cpufreq video parport_pc button intel_rapl_perf pcspkr parport ext4 
> crc16 mbcache jbd2 crc32c_generic fscrypto ecb sd_mod crc32c_intel 
> aacraid aesni_intel aes_x86_64 crypto_simd scsi_mod cryptd glue_helper 
> thermal fan
> CR2: 0008
> ---[ end trace 1f0672175c6e1ff0 ]---
> RIP: 0010:unmap_page_range+0x55d/0xa60
> Code: ff 83 ac 84 80 00 00 00 01 e8 4f 2b 01 00 49 8b 07 f6 c4 80 0f 84 
> 0e 03 00 00 4c 89 ff e8 6b 91 fe ff 85 c0 0f 88 e6 02 00 00 <49> 8b 46 
> 28 8b 50 08 8d 4a 01 89 48 08 4c 89 7c d0 10 3b 48 0c 0f
> RSP: 0018:9c3a43a67cd0 EFLAGS: 00010202
> RAX: 0004 RBX: 8e2f47a0deb0 RCX: 0001
> RDX:  RSI:  RDI: 8e2f7dd2
> RBP: 7f9f121d7000 R08:  R09: 8e2f6a6e09c0
> R10: 8e2f9e5df000 R11:  R12: 7f9f121d6000
> R13: 00081e49f025 R14: 9c3a43a67dd0 R15: d073a07927c0
> FS:  () GS:8e2f7e14() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 7faa2eaa99ac CR3: 00015020a003 CR4: 000606e0
> Fixing recursive fault but reboot is needed!
> 
> 
> 
> This is not the first time, so I suspect a persistent problem. I have no 
> idea how to look for the solution. Any suggestions??
> Just in case:
> 
> 
> 
> # lspci
> 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor 
> Family DRAM Controller (rev 09)
> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core 
> Processor Family PCI Express Root Port (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core 
> Processor Family Integrated Graphics Controller (rev 09)
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset 
> Family USB xHCI Host Controller 

Re: Nieuwste versie tcl, sqlite en DB Browser

[Cecil Westerhof]

Paul van der Vlis  writes:

> Op 20-12-2020 om 17:13 schreef Cecil Westerhof:
>
>>> Het is achteraf minder interessant als het leek. Het is vooral
>>> interessant voor de nieuwere versie van SQLite die wordt gebruikt.
>>> Maar de variant in 8.6.10 gebruikt net een variant te vroeg. Toch zou
>>> ik kunnen overwegen het te doen, want soms is het gewoon leuk je
>>> handen vies te maken. ;-)
>>
>> Toch niet: in backport kun je alleen krijgen wat in testing zit:
>>  Backports tracks testing and only package versions included in
>>  testing are allowed in it, subject to a few expedient exceptions.
>>
>> En ik denk dat ik geen expedient exception heb hier.
>
> De bedoeling is inderdaad dat je zaken eerst in testing ziet te krijgen.

Heb daar reeds een balletje over opgegooid.


> Maar het is me niet helemaal duidelijk wat je probleem is, is dat SQLite
> of sqlitebrowser?  In testing zitten van beide steeds de nieuwste
> versies!

Ik heb (nog) niet naar SQLite en sqlitebrowser gekeken. Het gaat me in
eerste instantie om tcl. En testing heeft net als Buster versie 8.6.9
i.p.v. 8.6.10 van tcl.
(Daarnaast heeft tcl 8.6.10 eigenlijk een net te oude versie van
SQLite ingebakken. 8.6.9 heeft 3.27.2 en 8.6.10 heeft 3.30.1 en ik ben
geïnteresseerd in 3.31.0 of hoger.)


> Bedenk dat er naast het pakket sqlite ook een pakket sqlite3 is.

Als ik het over SQLite heb, dan bedoel ik sqlite3.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: adding a disk to a Volume group

[Charles Curley]

On Sun, 20 Dec 2020 19:05:45 +
mick crane  wrote:

> It's a more or less new bullseye installation.
> The installer kindly set up a Volume Group and added Logical Volumes
> of a couple of the partitions on the disk with the OS on it.
> I want to add another disk to use for data.

A couple of thoughts here.

* Are you adding the new disk permanently or as removable media?

  If the latter, put a separate VG on it. Or don't bother. The reason I
  suggest this is if the new disk is removable, having the same VG span
  both disks may make the permanent disk unusable if the removable one
  is gone.

  If it is permanent, consider redoing both of them as a RAID level
  1, with encryption and LVM on top of that. Be sure to leave a boot
  partition on at least one of them.

* You said nothing about encryption. That may impact the order in which
  you do things.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: adding a disk to a Volume group

[deloptes]

mick crane wrote:

> I'll want to make an extended partition of the whole disk first with
> fdisk.
> but not sure the order I need to do things in after that.
> Can see what VG is called with "vgdisplay"
> will "vgextend my_VG /dev/sdx1"
> sort out making the Physical Volume and the Logical Volume ?
> I don't want to end up making 2 Volume Groups or something daft.
> Is there any difference making the ext4 filesystem on the /dev/VG/LV or
> /dev/sdx1 ?

you create first physical -> group -> logical volume and format.

you can also extend a logical group

https://wiki.debian.org/LVM

Re: Pulling free firmware-ath9k-htc into the CD images

[Nicholas Geovanis]

John I cant help right now. But for benefit of other readers and myself, I
would like to highlight this part of your changelog on the recent release.
On wpasupplicant fixes:

NEWS: Due to a bug in wpasupplicant, ath9k_htc devices often failed
  connections using MAC address randomization,

  which is enabled by default

  with NetworkManager. Fixes are available as wpasupplicant updates in

  releases Stretch and later.

  (Resolves: #870159, #895696, #939075, #954457, #954861)


On Sun, Dec 20, 2020, 1:02 PM John Scott  wrote:

> Hi,
>
> I'm not subscribed, please CC me. Also I've already sent a mail like this
> one
> to the kernel list; I hope this is the right place (as an outsider I don't
> know if I need to be reaching the d-i team instead).
>
> I'm adopting the firmware-ath9k-htc package, which has been FTBFS for a
> while
> but I've already found a sponsor (Paul Wise) and expect my fixes will be
> uploaded shortly [1].
>
> These are some of the flagship chipsets for free wireless adapters, and
> although it's good that the firmware gets built from source in a separate
> package, until now it's been segregated from the installer and Debian
> installations. I've sent a MR for the latter [2], so I'd like to know how
> to
> best tackle the former.
>
> I think I can build a udeb of my package before the freeze, but I wasn't
> sure
> if it would be easiest for you to do something else, such as copy the
> firmware
> into your udeb. I'm not familiar at all with the firmware/d-i aspects of
> the
> kernel packages, which doesn't appear well documented to me in code
> comments
> or the manual, but I'm willing to put in the work to make Debian more
> usable
> with free software and hardware.
>
> One hiccup though is that the firmware is included in firmware-nonfree; to
> avoid
> a filename clash I rename mine to 'htc_*-1.dev.0.fw' and set the kernel
> option
> to use the "development" firmware. This option would probably need to be
> set
> outright, or else the module needs to be reloaded. If it's appropriate,
> I'd be
> good to do a migration where it can be removed from firmware-nonfree and
> firmware-ath9k-htc can take back the file name.
>
> I would appreciate your advice on how I can proceed.
>
> Sincerely,
> John
>
> P.S. The reporter of [3] pointed out that, even if we're not building it
> from
> source, some of the firmware may be GPL and the Debian source packages do
> not
> ship the source code. Although I understand how meritocracy works, this
> does
> seem like a very serious problem which I'd like to mention in case you
> haven't
> considered.
>
> [1] https://mentors.debian.net/package/open-ath9k-htc-firmware/
> [2] https://salsa.debian.org/kernel-team/firmware-free/-/merge_requests/1
> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890601#15

Re: Nieuwste versie tcl, sqlite en DB Browser

[Paul van der Vlis]

Op 20-12-2020 om 17:13 schreef Cecil Westerhof:


Het is achteraf minder interessant als het leek. Het is vooral
interessant voor de nieuwere versie van SQLite die wordt gebruikt.
Maar de variant in 8.6.10 gebruikt net een variant te vroeg. Toch zou
ik kunnen overwegen het te doen, want soms is het gewoon leuk je
handen vies te maken. ;-)


Toch niet: in backport kun je alleen krijgen wat in testing zit:
 Backports tracks testing and only package versions included in
 testing are allowed in it, subject to a few expedient exceptions.

En ik denk dat ik geen expedient exception heb hier.


De bedoeling is inderdaad dat je zaken eerst in testing ziet te krijgen.

Maar het is me niet helemaal duidelijk wat je probleem is, is dat SQLite 
of sqlitebrowser?  In testing zitten van beide steeds de nieuwste versies!


Bedenk dat er naast het pakket sqlite ook een pakket sqlite3 is.

Groet,
Paul



--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

adding a disk to a Volume group

[mick crane]

hello,
It's a more or less new bullseye installation.
The installer kindly set up a Volume Group and added Logical Volumes of 
a couple of the partitions on the disk with the OS on it.

I want to add another disk to use for data.
Not had anything to do with LVM.
I'll want to make an extended partition of the whole disk first with 
fdisk.

but not sure the order I need to do things in after that.
Can see what VG is called with "vgdisplay"
will "vgextend my_VG /dev/sdx1"
sort out making the Physical Volume and the Logical Volume ?
I don't want to end up making 2 Volume Groups or something daft.
Is there any difference making the ext4 filesystem on the /dev/VG/LV or 
/dev/sdx1 ?


mick

--
Key ID4BFEBB31

Re: Nueva página web de Debian

[Osvaldo Salazar S.]

El 20/12/20 a las 8:46, Camaleón escribió:

> Aprovecho para recordaros que la web de Debian se ha renovado (hace un 
> par de días), para que os paséis y echéis un vistazo :-)
Me gustó el update :-D

-- 
Osvaldo R. Salazar S.

Future of X, fvwm and wayland

[Kamil Jońca]

It seems, that main graphical UI base will be Wayland instead of X
Window.
If I understand correctly Wayland has no separate window  manager
process.
As an user of FVWM (desktop box) and xfce (laptop) I feel little lost.
In particular it is not clear to me if it will be possible to use FVWM /
xfce on top (X)Wayland?
Will be possible to use emacsclient with ssh X tunneling?
KJ
-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: Debian 10 64bit

[Andy Smith]

Hello,

On Sun, Dec 20, 2020 at 11:32:33AM +, mick crane wrote:
> I noticed that if you add yourself to sudo group in /etc/group you
> have to logout and log back in for it to be noticed.

If you don't want to log out of the shell you can do this:

$ exec sg sudo "newgrp $(id -ng)"

The "exec" causes what follows to replace the current shell. Without
this you'd end up with two extra shells running and would have to
"exit" three times to close them.

"sg sudo" causes the following command to be executed with primary
group of "sudo".

"newgrp $(id -ng)" puts you back in your original primary group,
leaving you with group "sudo" as an additional group.

You can just do "newgroup sudo" but this:

- starts an extra shell so you'd have to "exit" it twice

- leaves you with "sudo" as your primary group

You can just do "su - $USER" but this will ask you for your
password.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Nieuwste versie tcl, sqlite en DB Browser

[Cecil Westerhof]

Cecil Westerhof  writes:

> Paul van der Vlis  writes:
>
>> Op 19-12-2020 om 17:56 schreef Cecil Westerhof:
>>> Ik gebruik tcl en SQLite veel en DB Browser regelmatig. Ik zit erover
>>> te denken om te zorgen dat ik de nieuwste versies op mijn systeem heb.
>>> Ik kan me voorstellen dat het voor anderen ook interessant kan zijn.
>>> Hoe moeilijk zou het zijn om die packages te maken en op te laten
>>> nemen in de Debian tree?
>>
>> TCL en SQlite zitten natuurlijk al in Debian.
>>
>> Ik neem aan dat je "DB browser for SQLite" bedoeld. In Debian zit een
>> pakket sqlitebrowser en ik krijg de indruk dat dat hetzelfde is.
>> https://sqlitebrowser.org/
>>
>> Als je een nieuwere versie wilt, dan zou je kunnen overwegen een
>> backport te maken. https://backports.debian.org/
>
> Oké, dan kijk ik daar eens naar. Testing en stable hebben namenlijk
> dezelfde versie. Experimental (wat me beter lijkt om niet te
> gebruiken) sprint meteen naar 8.7.0 (wat een preview release is).
>
> Het is achteraf minder interessant als het leek. Het is vooral
> interessant voor de nieuwere versie van SQLite die wordt gebruikt.
> Maar de variant in 8.6.10 gebruikt net een variant te vroeg. Toch zou
> ik kunnen overwegen het te doen, want soms is het gewoon leuk je
> handen vies te maken. ;-)

Toch niet: in backport kun je alleen krijgen wat in testing zit:
Backports tracks testing and only package versions included in
testing are allowed in it, subject to a few expedient exceptions.

En ik denk dat ik geen expedient exception heb hier.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Re: "Service restarts being deferred"

[Jesper Dybdal]

On 2020-12-19 21:05, Kushal Kumaran wrote:



Jesper Dybdal wrote:

I run Buster with unattended updates configured to allow reboots.

Sometimes after an update, the log contains:

Service restarts being deferred:
??systemctl restart systemd-logind.service
??systemctl restart unattended-upgrades.service



>From the documentation of Automatic-Reboot, it only has effect for
updates that result in the /var/run/reboot-required file being created.

For service restarts, the needrestart configuration would be a better
place to start.  The comments in /etc/needrestart/needrestart.conf are
instructive:

 # do not restart oneshot services, see also #862840
 qr(^apt-daily\.service$) => 0,
 qr(^apt-daily-upgrade\.service$) => 0,
 qr(^unattended-upgrades\.service$) => 0,

 # don't restart systemd-logind, see #798097
 qr(^systemd-logind) => 0,

Do go through those bug reports and experiment at a safe time before
changing things here.
Thanks.  Those bug reports explain why those services are not simply 
restarted, which seems very sensible.


But the "deferred" restarts seem to be deferred indefinitely, until the 
next reboot.  So I still don't quite understand why an automatic reboot 
is not scheduled in order to get those services restarted.
(Unless it is, strangely, the "Reboot with users" setting that has some 
influence here, even though there are no logged in users in my case.)


--
Jesper Dybdal
https://www.dybdal.dk

Re: Nieuwste versie tcl, sqlite en DB Browser

[Cecil Westerhof]

Paul van der Vlis  writes:

> Op 19-12-2020 om 17:56 schreef Cecil Westerhof:
>> Ik gebruik tcl en SQLite veel en DB Browser regelmatig. Ik zit erover
>> te denken om te zorgen dat ik de nieuwste versies op mijn systeem heb.
>> Ik kan me voorstellen dat het voor anderen ook interessant kan zijn.
>> Hoe moeilijk zou het zijn om die packages te maken en op te laten
>> nemen in de Debian tree?
>
> TCL en SQlite zitten natuurlijk al in Debian.
>
> Ik neem aan dat je "DB browser for SQLite" bedoeld. In Debian zit een
> pakket sqlitebrowser en ik krijg de indruk dat dat hetzelfde is.
> https://sqlitebrowser.org/
>
> Als je een nieuwere versie wilt, dan zou je kunnen overwegen een
> backport te maken. https://backports.debian.org/

Oké, dan kijk ik daar eens naar. Testing en stable hebben namenlijk
dezelfde versie. Experimental (wat me beter lijkt om niet te
gebruiken) sprint meteen naar 8.7.0 (wat een preview release is).

Het is achteraf minder interessant als het leek. Het is vooral
interessant voor de nieuwere versie van SQLite die wordt gebruikt.
Maar de variant in 8.6.10 gebruikt net een variant te vroeg. Toch zou
ik kunnen overwegen het te doen, want soms is het gewoon leuk je
handen vies te maken. ;-)

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

Nueva página web de Debian

[Camaleón]

Hola,

El equipo de traducción al español de Debian está haciendo un esfuerzo 
grande por traducir las páginas oficiales de la web de Debian, aunque 
me consta que también la wiki recibe su parte de atención por 
voluntarios que colaboran en traducir las páginas ya existentes y/o 
crear nuevas guías de ayuda en español.

Aprovecho para recordaros que la web de Debian se ha renovado (hace un 
par de días), para que os paséis y echéis un vistazo :-)

Saludos,

-- 
Camaleón 

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[Orestes Mas]

El diumenge, 20 de desembre de 2020, a les 10:40:27 CET, Joan Montané va 
escriure:

> Hola,
> 
> Anem a pams, que potser s'estan barrejant temes.
> 
> Els canvis a la glibc es van per fer coincidir els formats de data amb el
> CLDR. Objectivament, aquests canvis permeten escriure les dates
> correctament. És a dir, la iniciativa original no va ser des de Softcatalà,
> però sí a la glibc. En castellà no apostrofen els mesos, per això en el
> format de data tenen "hardcoded" la preposició "de". En francès no usen la
> preposició "de" en les dates (sospito que en el seu dia van triar fer-ho
> així per a evitar el problema de l'apostrofació)
> 
> En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o
> majúscula) en el format de date perquè usi el format sense proposició.
> Hauria de funcionar en tots els locales. P.ex: date -d "2018/04/01" +"%OB"
> retorna "abril" (sense preposició).
> 
> El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb
> això. És un altre problema que se suposa ja està corregit i tard o d'hora
> arribarà tothom [1]
> 
> Salutacions,
> Joan Montané
> 
> Més informació:
> https://rluzynski.fedorapeople.org/slides/2017-01-27-DevConf.cz/GenitiveMon
> ths-updated.pdf I, en concret per al català:
> https://www.softcatala.org/projectes/abril/ [1]
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963513


Desconeixia que "+%OB" retorna el nom del mes en "cas nominatiu". Molt 
interessant. En el cas que ens ocupa (català) això podria ser la solució, però 
desconec si en altres llengües arreglaria el problema o no.

En qualsevol cas, potser el desenvolupador de automysqlbackup desconeix aquest 
canvi a la glibc. Serà qüestió d'esbrinar-ho.

-- 
Cordialment,
Orestes Mas

Re: Linux Installation - MacBook Air 2020

[himani agarwal]

I tried installing all those things and the b43-fwcutter

I tried to install the modules

modprobe wl
modprobe applespi
modprobe appletouch

None of them are working, some extra lines appear in the dmesg output after
modprobe

[9.515203] r8152 2-2.4:1.0 enx00e04c680b71: carrier on
[9.564672] rfkill: input handler disabled
[   58.249582] rfkill: input handler enabled
[   59.806574] rfkill: input handler disabled
[   62.072574] applesmc: probe of applesmc.768 failed with error -5
[   67.168685] show_signal_msg: 6 callbacks suppressed
[   67.168686] packagekitd[816]: segfault at 8 ip 556fe0c51631 sp
7ffed178ffa0 error 4 in packagekitd[556fe0c4f000+24000]
[   67.168717] Code: 00 eb 81 66 0f 1f 44 00 00 48 8b 44 24 10 4c 89 e1 48
8d 15 25 1d 02 00 be 10 00 00 00 48 8d 3d e6 1c 02 00 41 bc ff ff ff ff
<4c> 8b 40 08 31 c0 e8 d4 f0 ff ff e9 4a ff ff ff 0f 1f 80 00 00 00
[  118.428252] applesmc: driver init failed (ret=-5)!
[  123.864611] usbcore: registered new interface driver appletouch

On Sat, Dec 19, 2020 at 1:01 AM Karthik  wrote:

> first you're using a mac with t2chip(as i can see it in lspci).
> As far as I know if T2 is not doing something crazy in the background the
> following standard steps should work.
>
> for the wireless card(broadcom):
> install broadcom-sta-dkms , firmware-brcm80211 , linux-firmware ,
> linux-firmware-free,,non-free packages
> i don't if your card source is available yet in these packages but if
> available they should work
>
> for the builtin keyboard,touchpad
> As i can see these are not connected to system through usb or i2c and not
> reported in ACPI tables in standard way(Apple way of doing things
> nonstandard) as a result they are not detected(assuming i read those files
> correctly).
> So you have to load the " applespi " module manually if it works after
> loading, then add etc/modprobe/... files.
> for the audio
> The audio modules are loaded correctly and should work fine.
> if they are not then i don't know why.
>
> On Fri, Dec 18, 2020 at 10:36 PM himani agarwal 
> wrote:
>
>> Hi Karthik,
>>
>> Please find the attached files.
>>
>> On Fri, Dec 18, 2020 at 11:01 AM Karthik 
>> wrote:
>>
>>>
>>> Attach the output of lspci ,lsusb, dmesg
>>> So that we can help you further
>>>
>>> On Fri, Dec 18, 2020, 2:38 PM himani agarwal  wrote:
>>>
 I downloaded the bullseye alpha 3 installer,
 firmware-bullseye-DI-alpha3-amd64-DVD-1.iso
 MD5: a1e967406869b1b0b64a1b808d39dd1a

 My computer is a Macbook Air 2020

 I shrank the Apple partition, disabled secure boot and I was able to
 boot with the Debian installer.

 The keyboard, mouse, wifi and sound don't work in the installer or in
 the installed system.  I had to use a USB keyboard and mouse connected
 with a USB-C dock.

 During install, the grub install failed.  I booted with the
 altlinux.org
 resuce image, entered the Debian partition with chroot and used apt to
 install the Debian refind boot manager package.  refind is working but I
 have to press Option every time I turn on the machine, otherwise it
 always goes to Mac.

 Can anybody tell me how to make the builtin keyboard, trackpad, wifi and
 sound work again?

 --
 Regards
 Himani Agarwal[image:
 https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

>>>
>>
>> --
>> Regards
>> Himani Agarwal[image: https://s3.amazonaws.com/htmlsig-assets/spacer.gif]
>>
>

-- 
Regards
Himani Agarwal[image: https://s3.amazonaws.com/htmlsig-assets/spacer.gif]

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[Orestes Mas]

El diumenge, 20 de desembre de 2020, a les 13:36:42 CET, Eloi va escriure:
Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] i l'he 
encertat de ple: 
com es pot veure a la funció shell, definida a partir de la línia 424, tant $1 
com $2 no estan 
degudament protegits. 
El fet que un espai en blanc trenqui la creació de còpies de seguretat, per si 
sol, entenc 
que mereix que el bug tingui una severitat major que normal. Ara bé, que $1 
tampoc 
estigui protegit i el paràmetre correspongui a una dada facilitada per 
l'usuari, el nom de la 
base de dades, em fa témer que podria arribar a explotar-se com a 
vulnerabilitat per a la 
injecció de comandes. Per exemple: una configuració que fes còpia d'una base de 
dades 
"foo; dropdb foo" (en el cas de treballar amb Postgres, on tinc experiència) 
podria, segons 
els permisos, destruir la base de dades, el que ho faria un bug crític [2]. Ara 
bé, no he 
comprovat fins a quin punt és explotable, però és quelcom que fa saltar totes 
les meves 
alarmes. 
També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es tractés 
d'una 
"cometa simple", causaria error i no completaria el backup. 
L'altre tema és el d'anomenar els backups en funció del locale, que està bé per 
a humans 
però és terrible per a gestió automàtica per a màquines. Si jo fes anar 
l'script (i, pel que he 
vist fins ara, el deixaria de fer servir immediatament) obriria dos bug 
reports: el primer, 
més greu, amb el problema d'escapament dels paràmetres de la funció dbdump; i 
el 
segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de forma 
humana 
(com fins ara) o mecànica (en un format -MM-DD o similar però respectant 
l'ordre 
any-mes-dia i 4-2-2 dígits). 
No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, doncs no 
podria 
donar respostes a preguntes addicionals del desenvolupador o de l'empaquetador, 
però 
puc ajudar a qui l'obri.


[1] 
[1]
 
cf. [2] 
[2] https://xkcd.com/327/[3]

Ostres, *moltes* gràcies a tots els qui heu respost aportant el vostre punt de 
vista. Ja em 
semblava que la cosa tenia més suc i transcendència del que hom podia pensar a 
primera 
vista, i el resultat no m'ha decebut gens :-)

Atès que sóc jo qui ha iniciat el fil veig que em tocarà a mi d'obrir el bug 
contra 
l'automysqlbackup. Passa que vaig una mica atrafegat amb el final de curs i no 
sé ben bé 
quan podré fer-ho. A més, tampoc no sóc gens expert en els temes de locale, 
libc, bash i 
demés. Vull dir que obrir el bug m'hi veig en cor, però proposar solucions més 
enllà de les 
que heu comentat (protegir les variables amb cometes, etc.) ja no tant.

En tot cas ho provo i si el desenvolupador demana més coses, aleshores ja us 
demanaré 
consell a vosaltres.

-- 
Cordialment,
Orestes Mas


[1] https://salsa.debian.org/zigo/automysqlbackup/-/blob/debian/automysqlbackup
[2] https://tracker.debian.org/pkg/automysqlbackup
[3] https://xkcd.com/327/

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[julio]

"Doble quote lost in space", m'encanten aquestes novel•les de misteri 
col•laboratives.
+1000

Le 20 décembre 2020 13:36:42 GMT+01:00, Eloi  a écrit :
>El 20/12/20 a les 12:27, Joan Montané ha escrit:
>>
>>
>> Missatge de Josep Lladonosa > > del dia dg., 20 de des. 2020 a les
>11:56:
>>
>> Hola,
>>
>> Sembla que ja està encaminada la solució però volia aportar la
>> meva opinió:
>>
>> Per a mi és un "bug" d'aquest script ja que no hauria de suposar
>> que les dates no tinguin espais si s'han d'usar en nom de fitxer
>> ja que un nom de fitxer pot contenir-ne, d'espais.
>>
>> Potser es pot reportar un bug al creador del script i fins i tot
>> fer una proposta per resoldre'l, "escapant" el nom de fitxer.
>>
>>
>> Efectivament, en el cas particular que ens ocupa hi ha dues coses que
>
>> coincideixen, i fan aparèixer el problema:
>>
>> 1. En algunes llengües, la variable que conté el nom del mes conté un
>
>> espai. És el cas de català si s'usa el format %B per a tots els mesos
>
>> menys abril, agost i octubre.
>> 2. L'script no escapa els possibles espais de les variables i si hi
>ha 
>> espais, aleshores l'script no fa el que se suposa que ha de fer.
>>
>> L'error és a 2 (no es pot assumir alegrement que una variable no té 
>> espais). El problema es podria rodejar usant "%OB" a l'script per a 
>> extraure els noms de mesos (totes les llengües que he mirat retornen 
>> els mesos sense espai), però això segueix sense garantir que les 
>> cadenes no tindran espais, i el problema descrit a 2 podria tornar a 
>> reproduir-se. La solució bona és escapar els espais de les variables,
>
>> amb les cometes dobles.
>>
>> Com diu el Josep, el millor és obrir un bug a automysqlbackup i, 
>> idealment, aportar-hi la solució.
>
>Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1]
>
>i l'he encertat de ple: com es pot veure a la funció shell, definida a 
>partir de la línia 424, tant $1 com $2 no estan degudament protegits.
>
>El fet que un espai en blanc trenqui la creació de còpies de seguretat,
>
>per si sol, entenc que mereix que el bug tingui una severitat major que
>
>normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre 
>correspongui a una dada facilitada per l'usuari, el nom de la base de 
>dades, em fa témer que podria arribar a explotar-se com a
>vulnerabilitat 
>per a la injecció de comandes. Per exemple: una configuració que fes 
>còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb
>
>Postgres, on tinc experiència) podria, segons els permisos, destruir la
>
>base de dades, el que ho faria un bug crític [2]. Ara bé, no he 
>comprovat fins a quin punt és explotable, però és quelcom que fa saltar
>
>totes les meves alarmes.
>
>També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es 
>tractés d'una "cometa simple", causaria error i no completaria el
>backup.
>
>L'altre tema és el d'anomenar els backups en funció del locale, que
>està 
>bé per a humans però és terrible per a gestió automàtica per a
>màquines. 
>Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de
>fer 
>servir immediatament) obriria dos bug reports: el primer, més greu, amb
>
>el problema d'escapament dels paràmetres de la funció dbdump; i el 
>segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de
>
>forma humana (com fins ara) o mecànica (en un format -MM-DD o 
>similar però respectant l'ordre any-mes-dia i 4-2-2 dígits).
>
>No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, 
>doncs no podria donar respostes a preguntes addicionals del 
>desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri.
>
>[1] 
>
>
>cf. 
>
>[2] https://xkcd.com/327/

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[Eloi]

El 20/12/20 a les 12:27, Joan Montané ha escrit:



Missatge de Josep Lladonosa > del dia dg., 20 de des. 2020 a les 11:56:


Hola,

Sembla que ja està encaminada la solució però volia aportar la
meva opinió:

Per a mi és un "bug" d'aquest script ja que no hauria de suposar
que les dates no tinguin espais si s'han d'usar en nom de fitxer
ja que un nom de fitxer pot contenir-ne, d'espais.

Potser es pot reportar un bug al creador del script i fins i tot
fer una proposta per resoldre'l, "escapant" el nom de fitxer.


Efectivament, en el cas particular que ens ocupa hi ha dues coses que 
coincideixen, i fan aparèixer el problema:


1. En algunes llengües, la variable que conté el nom del mes conté un 
espai. És el cas de català si s'usa el format %B per a tots els mesos 
menys abril, agost i octubre.
2. L'script no escapa els possibles espais de les variables i si hi ha 
espais, aleshores l'script no fa el que se suposa que ha de fer.


L'error és a 2 (no es pot assumir alegrement que una variable no té 
espais). El problema es podria rodejar usant "%OB" a l'script per a 
extraure els noms de mesos (totes les llengües que he mirat retornen 
els mesos sense espai), però això segueix sense garantir que les 
cadenes no tindran espais, i el problema descrit a 2 podria tornar a 
reproduir-se. La solució bona és escapar els espais de les variables, 
amb les cometes dobles.


Com diu el Josep, el millor és obrir un bug a automysqlbackup i, 
idealment, aportar-hi la solució.


Doncs bé, he fet l'exercici de consultar el codi font de l'script a [1] 
i l'he encertat de ple: com es pot veure a la funció shell, definida a 
partir de la línia 424, tant $1 com $2 no estan degudament protegits.


El fet que un espai en blanc trenqui la creació de còpies de seguretat, 
per si sol, entenc que mereix que el bug tingui una severitat major que 
normal. Ara bé, que $1 tampoc estigui protegit i el paràmetre 
correspongui a una dada facilitada per l'usuari, el nom de la base de 
dades, em fa témer que podria arribar a explotar-se com a vulnerabilitat 
per a la injecció de comandes. Per exemple: una configuració que fes 
còpia d'una base de dades "foo; dropdb foo" (en el cas de treballar amb 
Postgres, on tinc experiència) podria, segons els permisos, destruir la 
base de dades, el que ho faria un bug crític [2]. Ara bé, no he 
comprovat fins a quin punt és explotable, però és quelcom que fa saltar 
totes les meves alarmes.


També, com s'apunta correctament, si l'apòstrof no fos tipogràfic i es 
tractés d'una "cometa simple", causaria error i no completaria el backup.


L'altre tema és el d'anomenar els backups en funció del locale, que està 
bé per a humans però és terrible per a gestió automàtica per a màquines. 
Si jo fes anar l'script (i, pel que he vist fins ara, el deixaria de fer 
servir immediatament) obriria dos bug reports: el primer, més greu, amb 
el problema d'escapament dels paràmetres de la funció dbdump; i el 
segon, com a wishlist, per parametritzar si la còpia s'ha d'anomenar de 
forma humana (com fins ara) o mecànica (en un format -MM-DD o 
similar però respectant l'ordre any-mes-dia i 4-2-2 dígits).


No em sento còmode obrint-los jo per tractar-se d'una eina que no uso, 
doncs no podria donar respostes a preguntes addicionals del 
desenvolupador o de l'empaquetador, però puc ajudar a qui l'obri.


[1] 
 
cf. 


[2] https://xkcd.com/327/

Re: Debian 10 64bit

[mick crane]

On 2020-12-19 20:04, David Wright wrote:
<...>

saying because I noticed that if you add yourself to sudo group in 
/etc/group you have to logout and log back in for it to be noticed.


mick
--
Key ID4BFEBB31

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[Joan Montané]

Missatge de Josep Lladonosa  del dia dg., 20 de des.
2020 a les 11:56:

> Hola,
>
> Sembla que ja està encaminada la solució però volia aportar la meva opinió:
>
> Per a mi és un "bug" d'aquest script ja que no hauria de suposar que les
> dates no tinguin espais si s'han d'usar en nom de fitxer ja que un nom de
> fitxer pot contenir-ne, d'espais.
>
> Potser es pot reportar un bug al creador del script i fins i tot fer una
> proposta per resoldre'l, "escapant" el nom de fitxer.
>
>
Efectivament, en el cas particular que ens ocupa hi ha dues coses que
coincideixen, i fan aparèixer el problema:

1. En algunes llengües, la variable que conté el nom del mes conté un
espai. És el cas de català si s'usa el format %B per a tots els mesos menys
abril, agost i octubre.
2. L'script no escapa els possibles espais de les variables i si hi ha
espais, aleshores l'script no fa el que se suposa que ha de fer.

L'error és a 2 (no es pot assumir alegrement que una variable no té
espais). El problema es podria rodejar usant "%OB" a l'script per a
extraure els noms de mesos (totes les llengües que he mirat retornen els
mesos sense espai), però això segueix sense garantir que les cadenes no
tindran espais, i el problema descrit a 2 podria tornar a reproduir-se. La
solució bona és escapar els espais de les variables, amb les cometes dobles.

Com diu el Josep, el millor és obrir un bug a automysqlbackup i, idealment,
aportar-hi la solució.

Salut!
Joan Montané

PS: encara gràcies que amb %B "d'abril", "d'agost" i "d'octubre" usen
l'apòstrof tipogràfic, perquè sospito que si usessin l'apòstrof recte,
l'script també hauria tingut problemes en aquests mesos.

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[Josep Lladonosa]

Hola,

Sembla que ja està encaminada la solució però volia aportar la meva opinió:

Per a mi és un "bug" d'aquest script ja que no hauria de suposar que les
dates no tinguin espais si s'han d'usar en nom de fitxer ja que un nom de
fitxer pot contenir-ne, d'espais.

Potser es pot reportar un bug al creador del script i fins i tot fer una
proposta per resoldre'l, "escapant" el nom de fitxer.

Salutacions,
Josep

On Sun, 20 Dec 2020 at 11:07, Ernest Adrogué  wrote:

> 2020-12-20, 10:40 (+0100); Joan Montané escriu:
> > Anem a pams, que potser s'estan barrejant temes.
> >
> > Els canvis a la glibc es van per fer coincidir els formats de data amb el
> > CLDR. Objectivament, aquests canvis permeten escriure les dates
> > correctament. És a dir, la iniciativa original no va ser des de
> Softcatalà,
> > però sí a la glibc.
> > En castellà no apostrofen els mesos, per això en el format de data tenen
> > "hardcoded" la preposició "de".
> > En francès no usen la preposició "de" en les dates (sospito que en el seu
> > dia van triar fer-ho així per a evitar el problema de l'apostrofació)
> >
> > En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o
> > majúscula) en el format de date perquè usi el format sense proposició.
> > Hauria de funcionar en tots els locales. P.ex:  date -d "2018/04/01"
> +"%OB"
> > retorna "abril" (sense preposició).
> >
> > El tema dels mesos incorrectes a "ls -l" no està directament relacionat
> amb
> > això. És un altre problema que se suposa ja està corregit i tard o d'hora
> > arribarà tothom [1]
>
> Gràcies per l'aclariment.
>
>

-- 
--
Salutacions...Josep
--

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[Ernest Adrogué]

2020-12-20, 10:40 (+0100); Joan Montané escriu:
> Anem a pams, que potser s'estan barrejant temes.
> 
> Els canvis a la glibc es van per fer coincidir els formats de data amb el
> CLDR. Objectivament, aquests canvis permeten escriure les dates
> correctament. És a dir, la iniciativa original no va ser des de Softcatalà,
> però sí a la glibc.
> En castellà no apostrofen els mesos, per això en el format de data tenen
> "hardcoded" la preposició "de".
> En francès no usen la preposició "de" en les dates (sospito que en el seu
> dia van triar fer-ho així per a evitar el problema de l'apostrofació)
> 
> En bash, cal canviar de locale ni res. Només cal usar "%OB" (lletra o
> majúscula) en el format de date perquè usi el format sense proposició.
> Hauria de funcionar en tots els locales. P.ex:  date -d "2018/04/01" +"%OB"
> retorna "abril" (sense preposició).
> 
> El tema dels mesos incorrectes a "ls -l" no està directament relacionat amb
> això. És un altre problema que se suposa ja està corregit i tard o d'hora
> arribarà tothom [1]

Gràcies per l'aclariment.

Re: Tiling display support

[Steven Mainor]

On 2020-12-20 02:37, Mark Allums wrote:
Oh, thanks, I've reread specs. It says 'refresh rate up to 240Hz', but 
for full resolution it's 5120 x 1440 | 60 Hz. There is LG, which 
promises 3840 x 2160 144Hz. I'll be more careful.


Which LG model offers 144 Hz at 3480 x 2160?  Because I am shopping
for a high-refresh 4k device right now, and I haven't run across any
model like that from LG.

Mark

(Preferably 32-inch.)


The LG 27GN950-B is 4k, 144Hz but not 32 inch. It also supports FreeSync 
wich works well on linux with the open source AMD drivers. I highly 
recommend FreeSync(adaptive sync).


If you aren't too attached to LG there are other manufacturers that have 
larger screens with the specs you requested.


---
Steven Mainor

0x9477C19B.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Problemes amb automysqlbackup combinat amb un "locale" en català

[Ernest Adrogué]

2020-12-20, 03:51 (+0100); Toni Mas Soler escriu:
> Doncs jo ho entenc com un bug del propi locale. Voleu dir que som l'única
> llengua que es troba en aquesta situació?
> 
> Com a primer plantejament caldria considerar la correcció del locale per
> tal que un date +%B retorni el mes sense preposició.

Exacte, el problema és el local ca_ES.  Mireu aquest fil de fa 2 anys:

https://lists.debian.org/debian-user-catalan/2018/10/msg0.html

Pel que sembla, des de Softcatalà, van promoure un canvi al local ca_ES,
que és el que provoca que ara apareguin els mesos amb preposició en
llocs on no hi ha d'haver preposició.  Ni el francès [1], ni el castellà
[2], ni l'italià [3], que utilitzen els mesos igual que el català, han
fet cap canvi similar en els respectius locals

[1] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c

[2] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/es_ES;h=aa919a26267fd6311b71d7aeb81655e55787b4df;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c

[3] 
https://sourceware.org/git/?p=glibc.git;a=blob;f=localedata/locales/fr_FR;h=a18c514f1921fed0049d3b769c95c9e0f864fb2f;hb=a00bffe8b531693d3b26c1e87afe4b9eac84474c

Jo ja fa temps vaig canviar el local a "C" perquè no podia soportar més
els llistats de 'ls -l' amb els noms dels mesos equivocats.


Salutacions.