Re: [arch-general] User/group name restrictions

[Spencer Collyer]

On Thu, 23 May 2019 19:08:22 -0400, Eli Schwartz via arch-general wrote:
> On 5/23/19 3:15 PM, Andy Pieters wrote:
> > Hi
> > 
> > This is something I gotten used to live with for a very long time
> > now, patching the shadow package every time it is updated to allow
> > capitals in the user/group names.
> > 
> > I've often meant to write in to ask why and this is that glorious
> > day.
> > 
> > Why is it that uppercase letters are not allowed in user/group
> > names in Arch Linux please.
> > 
> > It's not that I'm anal about everything, but I was always brought
> > up with the rule that a person's name should be written with their
> > appropriate capital letters and not to do so is a deliberate mark
> > of disrespect at the owner's address.
> > 
> > So imagine my chagrin if I'd have to stare at my terminal all day
> > long with such deliberate cheekiness staring in my face 😜  
> 
> 
> Is this a trick question? Perhaps you wish your terminal prompt to
> contain the User name (GECOS field) of /etc/passwd, rather than the
> login name. I presume so, since you state that you are anal about
> proper names, and a login name will never, ever be a proper name
> until it also contains the space in between the first and last name
> -- and for many parts of the world, it also has to contain completely
> arbitrary bytes that aren't part of the latin alphabet. Therefore it
> logically follows that your computer's symbolic codename will
> continue to be unsuitable as a *display* name even if you were able
> to use capitals in it.
> 
> Not sure why you think it is Arch Linux's job to decide whether Unix
> login names should contain whichever type of character. However you
> may rest assured that this has been the case as upstream intended
> since 2001-11-07:
> https://github.com/shadow-maint/shadow/commit/9db6abfa42c946b4046f4b2fe67dc43ba862eb0e#diff-cea137edbef417591556cfd6306b22f2R25
> (This is a CVS import which was done in 2007, the other date can be
> seen in the changelog.)
> 
> If you're actually asking why Debian provides a downstream patch that
> permits nonstandard login names, I don't know or care.
> 
> ...
> 
> Given that your initial post does specifically state that you are
> patching the package in order to allow it, I will assume that nothing
> I just said about upstream's intentions is remotely surprising to you
> -- you would have to know that it's enforced in libmisc/chkname.c in
> order to patch it, s... may I ask why you posted to the list
> asking why it is not allowed "in Arch Linux", rather than "in the
> upstream, distribution-agnostic shadow-maint software"?
> 
> It seems almost disingenuous to put it that way, and you are the
> person who would know better than most arch-general readers that it's
> not actually something Arch Linux is doing. Why be misleading? It
> will only result in people having no idea what you are talking about,
> assuming your public statements about this being some form of Arch
> Linux configuration are accurate, and giving you uninformed answers
> as a result. This is hardly conducive to your desired goal to find
> out why.
> 

The following (taken from 
http://www.catb.org/~esr/faqs/things-every-hacker-once-knew/) may be relevant 
here:

"The very earliest VDTs, like the ASR-33 before them, could form only 
upper-case letters. An interesting hangover from these devices was that, even 
though most VDTs made after 1975 could form lower-case letters, Unix (and Linux 
as late as 2018) responded to a login beginning with an upper-case letter by 
switching to a mode which upcased all input. If you create an account with this 
sort of login name and a mixed-case password, hilarity ensues. If the password 
is upper-case the hilarity is less desperate but still confusing for the user."

I've not tried this on my current Arch install to see if it's still true in 
2019, but maybe disallowing uppercase in the user/group names is an attempt to 
stop that being a problem.

Re: [arch-general] License for libdrm packages

[Eli Schwartz via arch-general]

On 5/23/19 6:48 PM, ProgAndy wrote:
> Am 24.05.19 um 00:21 schrieb mar77i via arch-general:
> ...
>>
>> To answer my own question, of course I screwed it up already.
>> Okay, so license=('custom:MIT'), license=('MIT') or license=('custom')?
>>
>> manual says: put licenses from /usr/share/licenses/common into the license
>> array, otherwise use 'custom' / 'custom:LicenseName'.
>>
>> Depending on how many PKGBUILDs you've looked at in the past, you might 
>> think,
>> of course, you put license=('MIT') for MIT licensed projects in your 
>> PKGBUILD.
>> Which, as we now established, is incorrect, yet not actually enforced, and 
>> the
>> more important part of getting this right is to have the original license 
>> file
>> with the copyright notice in the package, as the document usually asks.
>>
>> I think we can bikeshed over the prefered 'custom' or 'custom:MIT' details 
>> from
>> here on, however, a quick glance at my pacman database shows that a lot of 
>> repo
>> packages actually don't do what the manpage say, of which there are asp,
>> wayland, sdl2... (the list goes on).
>>
> 
> Those packages follow the exception published in the wiki[1] which
> allows license=('MIT') if you also include the exact license text with
> copyright notice in /usr/share/licenses/pkgname. This text has been
> there since the creation of the wiki page in November 2009[2] and I
> believe before that it was on another wiki page that has since been
> deleted without preserving its history[3], so I don't know where it came
> from. Should this really be declared as wrong now?

Easy answer! The wiki is a more in-depth discussion of what the manpage
says, and therefore takes precedence.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] User/group name restrictions

[Eli Schwartz via arch-general]

On 5/23/19 3:15 PM, Andy Pieters wrote:
> Hi
> 
> This is something I gotten used to live with for a very long time now,
> patching the shadow package every time it is updated to allow capitals in
> the user/group names.
> 
> I've often meant to write in to ask why and this is that glorious day.
> 
> Why is it that uppercase letters are not allowed in user/group names in
> Arch Linux please.
> 
> It's not that I'm anal about everything, but I was always brought up with
> the rule that a person's name should be written with their appropriate
> capital letters and not to do so is a deliberate mark of disrespect at the
> owner's address.
> 
> So imagine my chagrin if I'd have to stare at my terminal all day long with
> such deliberate cheekiness staring in my face 😜


Is this a trick question? Perhaps you wish your terminal prompt to
contain the User name (GECOS field) of /etc/passwd, rather than the
login name. I presume so, since you state that you are anal about proper
names, and a login name will never, ever be a proper name until it also
contains the space in between the first and last name -- and for many
parts of the world, it also has to contain completely arbitrary bytes
that aren't part of the latin alphabet. Therefore it logically follows
that your computer's symbolic codename will continue to be unsuitable as
a *display* name even if you were able to use capitals in it.

Not sure why you think it is Arch Linux's job to decide whether Unix
login names should contain whichever type of character. However you may
rest assured that this has been the case as upstream intended since
2001-11-07:
https://github.com/shadow-maint/shadow/commit/9db6abfa42c946b4046f4b2fe67dc43ba862eb0e#diff-cea137edbef417591556cfd6306b22f2R25
(This is a CVS import which was done in 2007, the other date can be seen
in the changelog.)

If you're actually asking why Debian provides a downstream patch that
permits nonstandard login names, I don't know or care.

...

Given that your initial post does specifically state that you are
patching the package in order to allow it, I will assume that nothing I
just said about upstream's intentions is remotely surprising to you --
you would have to know that it's enforced in libmisc/chkname.c in order
to patch it, s... may I ask why you posted to the list asking why it
is not allowed "in Arch Linux", rather than "in the upstream,
distribution-agnostic shadow-maint software"?

It seems almost disingenuous to put it that way, and you are the person
who would know better than most arch-general readers that it's not
actually something Arch Linux is doing. Why be misleading? It will only
result in people having no idea what you are talking about, assuming
your public statements about this being some form of Arch Linux
configuration are accurate, and giving you uninformed answers as a
result. This is hardly conducive to your desired goal to find out why.

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] License for libdrm packages

[ProgAndy]

Am 24.05.19 um 00:21 schrieb mar77i via arch-general:
...
> 
> To answer my own question, of course I screwed it up already.
> Okay, so license=('custom:MIT'), license=('MIT') or license=('custom')?
> 
> manual says: put licenses from /usr/share/licenses/common into the license
> array, otherwise use 'custom' / 'custom:LicenseName'.
> 
> Depending on how many PKGBUILDs you've looked at in the past, you might think,
> of course, you put license=('MIT') for MIT licensed projects in your PKGBUILD.
> Which, as we now established, is incorrect, yet not actually enforced, and the
> more important part of getting this right is to have the original license file
> with the copyright notice in the package, as the document usually asks.
> 
> I think we can bikeshed over the prefered 'custom' or 'custom:MIT' details 
> from
> here on, however, a quick glance at my pacman database shows that a lot of 
> repo
> packages actually don't do what the manpage say, of which there are asp,
> wayland, sdl2... (the list goes on).
> 

Those packages follow the exception published in the wiki[1] which
allows license=('MIT') if you also include the exact license text with
copyright notice in /usr/share/licenses/pkgname. This text has been
there since the creation of the wiki page in November 2009[2] and I
believe before that it was on another wiki page that has since been
deleted without preserving its history[3], so I don't know where it came
from. Should this really be declared as wrong now?


Relevant paragraph of [1]:
> The BSD, ISC, MIT, zlib/png and Python licenses are special 
> cases and could not be included in the licenses package. 
> For the sake of the license array, it is treated as a 
> common license (license=('BSD'), license=('ISC'), 
> license=('MIT'), license=('ZLIB') and license=('Python')), 
> but technically each one is a custom license, because each 
> one has its own copyright line. Any packages licensed under 
> these four should have its own unique license stored in 
> /usr/share/licenses/pkgname.
> 

[1]: https://wiki.archlinux.org/index.php/PKGBUILD#license
[2]:
https://wiki.archlinux.org/index.php?title=PKGBUILD&diff=85178&oldid=85175
[3]:
https://wiki.archlinux.org/index.php?title=Building_Packages_in_Arch_Linux&action=history

Re: [arch-general] License for libdrm packages

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Friday, May 24, 2019 12:14 AM, Lone_Wolf  wrote:

> People,
>
> I forgot to tell ashark the primary reason why I felt a thread in arch
> general ML was needed.
>
> Almost every file in libdrm tree has it's own copyright notice, I've
> listed 4 examples at the bottom of the mail.
>
> The COPYING file we include with libdrm doesn't list any of those 4
> notices and I have no idea how many more we miss.
>
> Are there tools to extract multiple license texts from multiple files in
> multiple folders, should maintainers create something by hand or are
> there other/better options ?
>
> How can we be sure we're not missing one or two copyright notices ?
>
> This could potentially affect many archlinux packages with numerous
> license types.
>

Well for one thing, you could try to work with upstream to extract the licenses 
into separate files somehow. RMS once explained to me that you might be out of 
luck if you don't reference your license in a source file of your project that 
uses your specified license, because in some jurisdictions people have 
successfully snuck out files from licensed projects where the file didn't 
mention the applicable license pro-actively. Which can be annoying because that 
means upstream would extract the license and replace it with a placeholder. So 
I guess the question is if the situation can even be fixed at all, or how we'd 
go about improve it.

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] License for libdrm packages

[mar77i via arch-general]

> I have read that article in ArchWiki. I understand that point that MIT
> licences are all custom because of individual copyright line. But then I do
> not understand when should I use license=('MIT') instead of 
> license=('custom')?

> I have read that MIT is a set of licenses, but it is kinda unclear. I guess
> that if there is clear text that it is a MIT license, then I use MIT,
> otherwise for MIT-style licence I just use custom. Am I correct?

> It's possible I misunderstood what part of this process caused confusion with
> you, so please elaborate your position further, I'll gladly answer or research
> more questions.

To answer my own question, of course I screwed it up already.
Okay, so license=('custom:MIT'), license=('MIT') or license=('custom')?

manual says: put licenses from /usr/share/licenses/common into the license
array, otherwise use 'custom' / 'custom:LicenseName'.

Depending on how many PKGBUILDs you've looked at in the past, you might think,
of course, you put license=('MIT') for MIT licensed projects in your PKGBUILD.
Which, as we now established, is incorrect, yet not actually enforced, and the
more important part of getting this right is to have the original license file
with the copyright notice in the package, as the document usually asks.

I think we can bikeshed over the prefered 'custom' or 'custom:MIT' details from
here on, however, a quick glance at my pacman database shows that a lot of repo
packages actually don't do what the manpage say, of which there are asp,
wayland, sdl2... (the list goes on).

cheers!
mar77i

Sent with ProtonMail Secure Email.

Re: [arch-general] License for libdrm packages

[Lone_Wolf]

People,

I forgot to tell ashark the primary reason why I felt a thread in arch 
general ML was needed.


Almost every file in libdrm tree has it's own copyright notice, I've 
listed 4 examples at the bottom of the mail.


The COPYING file we include with libdrm doesn't list any of those 4 
notices and I have no idea how many more we miss.



Are there tools to extract multiple license texts from multiple files in 
multiple folders, should maintainers create something by hand or are 
there other/better options ?


How can we be sure we're not missing one or two copyright notices ?


This could potentially affect many archlinux packages with numerous 
license types.


(Wiki suggests named copyright notices are needed for BSD , ISC, MIT , 
zlib/png and Python licenses)



Lone_Wolf




Android.mk

#
# Copyright © 2011-2012 Intel Corporation
#


util_double_list.h

 * Copyright 2006 Tungsten Graphics, Inc., Bismarck, ND. USA.

etnaviv/etnaviv_device.c

/*
 * Copyright (C) 2014 Etnaviv Project
 *

etnanviv/meson.build

# Copyright © 2017-2018 Intel Corporation

Re: [arch-general] License for libdrm packages

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Thursday, May 23, 2019 11:15 PM, mpan  wrote:
>
> I talked about the topic on #archlinux and it seems that the accepted
> solution is to use 'MIT' in the `license` array, despite there is no
> corresponding text in the “licenses” package, and put the text into
> “/usr/share/licenses/pkgname”, despite it is not marked as 'custom' in
> the `license` array. ¯\(ツ)/¯

MIT, along with other BSD-like licenses contain authors' individual copyright 
notices for each project. Arch therefore can't provide a - in this sense - 
valid copy of the respective license to refer users to, because that would be 
illogical. So we put the recognizable name of the license in the license array 
and ship the individual license file along with the project.

It's possible I misunderstood what part of this process caused confusion with 
you, so please elaborate your position further, I'll gladly answer or research 
more questions.

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] License for libdrm packages

[Eli Schwartz via arch-general]

On 5/23/19 5:15 PM, mpan wrote:
>> I have read that article in ArchWiki. I understand that point that MIT 
>> licences are all custom because of individual copyright line. But then I do 
>> not understand when should I use license=('MIT') instead of 
>> license=('custom')?
>> I have read that MIT is a set of licenses, but it is kinda unclear. I guess 
>> that if there is clear text that it is a MIT license, then I use MIT, 
>> otherwise for MIT-style licence I just use custom. Am I correct?
>   I talked about the topic on #archlinux and it seems that the accepted
> solution is to use 'MIT' in the `license` array, despite there is no
> corresponding text in the “licenses” package, and put the text into
> “/usr/share/licenses/pkgname”, despite it is not marked as 'custom' in
> the `license` array. ¯\_(ツ)_/¯
> 
>   I still consider it illogical, but I have been outvoted. But I would
> not claim that “libdrm” maintainer is wrong on using 'custom' here.

That most likely has to do with the fact that your own wiki link
explicitly says that is what you're supposed to do.


-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] License for libdrm packages

[mpan]

> I have read that article in ArchWiki. I understand that point that MIT 
> licences are all custom because of individual copyright line. But then I do 
> not understand when should I use license=('MIT') instead of 
> license=('custom')?
> I have read that MIT is a set of licenses, but it is kinda unclear. I guess 
> that if there is clear text that it is a MIT license, then I use MIT, 
> otherwise for MIT-style licence I just use custom. Am I correct?
  I talked about the topic on #archlinux and it seems that the accepted
solution is to use 'MIT' in the `license` array, despite there is no
corresponding text in the “licenses” package, and put the text into
“/usr/share/licenses/pkgname”, despite it is not marked as 'custom' in
the `license` array. ¯\_(ツ)_/¯

  I still consider it illogical, but I have been outvoted. But I would
not claim that “libdrm” maintainer is wrong on using 'custom' here.



signature.asc
Description: OpenPGP digital signature

[arch-general] User/group name restrictions

[Andy Pieters]

Hi

This is something I gotten used to live with for a very long time now,
patching the shadow package every time it is updated to allow capitals in
the user/group names.

I've often meant to write in to ask why and this is that glorious day.

Why is it that uppercase letters are not allowed in user/group names in
Arch Linux please.

It's not that I'm anal about everything, but I was always brought up with
the rule that a person's name should be written with their appropriate
capital letters and not to do so is a deliberate mark of disrespect at the
owner's address.

So imagine my chagrin if I'd have to stare at my terminal all day long with
such deliberate cheekiness staring in my face 😜

Thanks

Andy

Re: [arch-general] License for libdrm packages

[ashark]

I have read that article in ArchWiki. I understand that point that MIT licences 
are all custom because of individual copyright line. But then I do not 
understand when should I use license=('MIT') instead of license=('custom')?
I have read that MIT is a set of licenses, but it is kinda unclear. I guess 
that if there is clear text that it is a MIT license, then I use MIT, otherwise 
for MIT-style licence I just use custom. Am I correct?

23.05.2019, 20:06, "mpan" :
>>  Hello. I was repacking amdgpu-pro deb files and when I started converting 
>> licences, I have noticed that libdrm* packages have a MIT Licence text in 
>> copyright file. I decided to check if AUR/libdrm-git and Extra/libdrm uses 
>> MIT licence, but they don't. I contacted Lone_Wolf (maintainer of 
>> libdrm-git) and he said that he used a licence from Extra/libdrm.
>>  Should not it be changed to MIT instead of custom?
>
>   “MIT-style license” is a class of licenses, not a specific one. Each
> software using MIT-style licensing is having its own, independent
> license text. While in practice they may be nearly identical (modulo
> copyright line), they’re in fact separate licenses. The topic is
> discussed on the wiki:
> .
>
> In particular the terms include:
>  --
>   The above copyright notice and this permission notice (including the
>   next paragraph) shall be included in all copies or substantial
>   portions of the Software.
>  --
> Which means that if multiple MIT-licensed pieces of software are
> combined, the complete notice of each of them has to be included in the
> final work. And this is exactly what happens in case of libdrm:
> .

Re: [arch-general] License for libdrm packages

[mpan]

> Hello. I was repacking amdgpu-pro deb files and when I started converting 
> licences, I have noticed that libdrm* packages have a MIT Licence text in 
> copyright file. I decided to check if AUR/libdrm-git and Extra/libdrm uses 
> MIT licence, but they don't. I contacted Lone_Wolf (maintainer of libdrm-git) 
> and he said that he used a licence from Extra/libdrm.
> Should not it be changed to MIT instead of custom?
  “MIT-style license” is a class of licenses, not a specific one. Each
software using MIT-style licensing is having its own, independent
license text. While in practice they may be nearly identical (modulo
copyright line), they’re in fact separate licenses. The topic is
discussed on the wiki:
.

In particular the terms include:
 --
  The above copyright notice and this permission notice (including the
  next paragraph) shall be included in all copies or substantial
  portions of the Software.
 --
Which means that if multiple MIT-licensed pieces of software are
combined, the complete notice of each of them has to be included in the
final work. And this is exactly what happens in case of libdrm:
.




signature.asc
Description: OpenPGP digital signature

[arch-general] License for libdrm packages

[ashark]

Hello. I was repacking amdgpu-pro deb files and when I started converting 
licences, I have noticed that libdrm* packages have a MIT Licence text in 
copyright file. I decided to check if AUR/libdrm-git and Extra/libdrm uses MIT 
licence, but they don't. I contacted Lone_Wolf (maintainer of libdrm-git) and 
he said that he used a licence from Extra/libdrm.
Should not it be changed to MIT instead of custom?

Re: [arch-general] Arch on NVMe ssd

[Ram Kumar via arch-general]

Oh!.. these features are also available??!!!.. great yeah..

On Thu, 23 May 2019, 2:18 pm Ralf Mardorf via arch-general, <
arch-general@archlinux.org> wrote:

> On Thu, 23 May 2019 09:01:49 +0100, Ralph Corderoy wrote:
> >The SSD drive also reports its own personal view of lifetime remaining
> >and other interesting statistics using
> >https://en.wikipedia.org/wiki/S.M.A.R.T%2E.
> >
> >173 Ave_Block-Erase_Count   -O--CK   095   095   000-77
> >202 Percent_Lifetime_Remain CK   095   095   001-5
> >
> >`smartctl -x /dev/sda', for example, can gather the data.
>
> Only if it's in the data base.
>
> [root@archlinux rocketmouse]# smartctl -x /dev/sda | grep 'Vendor
> Specific SMART Attributes' -A 11
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME  FLAGSVALUE WORST THRESH FAIL RAW_VALUE
>   9 Power_On_Hours  -O--C-   100   100   000-16224
>  12 Power_Cycle_Count   -O--C-   100   100   000-581
> 167 Unknown_Attribute   -O---K   100   100   000-0
> 168 Unknown_Attribute   -O--C-   100   100   000-0
> 169 Unknown_Attribute   PO   100   100   010-0
> 173 Unknown_Attribute   -O--C-   161   161   000-0
> 192 Power-Off_Retract_Count -O--C-   100   100   000-149
> 194 Temperature_Celsius PO---K   073   065   020-27 (Min/Max
> 10/35)
> 241 Total_LBAs_Written  -O--CK   100   100   000-287072
> ||_ K auto-keep
>
> For the SSDs on my machine I'm using "ocz-ssd-utility" to get erase
> count, lifetime percentage and other SMART information, let alone that
> I could update the firmware, while the SSDs are used.
>

Re: [arch-general] Arch on NVMe ssd

[Ralf Mardorf via arch-general]

On Thu, 23 May 2019 09:01:49 +0100, Ralph Corderoy wrote:
>The SSD drive also reports its own personal view of lifetime remaining
>and other interesting statistics using
>https://en.wikipedia.org/wiki/S.M.A.R.T%2E.
>
>173 Ave_Block-Erase_Count   -O--CK   095   095   000-77
>202 Percent_Lifetime_Remain CK   095   095   001-5
>
>`smartctl -x /dev/sda', for example, can gather the data.

Only if it's in the data base.

[root@archlinux rocketmouse]# smartctl -x /dev/sda | grep 'Vendor Specific 
SMART Attributes' -A 11
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAGSVALUE WORST THRESH FAIL RAW_VALUE
  9 Power_On_Hours  -O--C-   100   100   000-16224
 12 Power_Cycle_Count   -O--C-   100   100   000-581
167 Unknown_Attribute   -O---K   100   100   000-0
168 Unknown_Attribute   -O--C-   100   100   000-0
169 Unknown_Attribute   PO   100   100   010-0
173 Unknown_Attribute   -O--C-   161   161   000-0
192 Power-Off_Retract_Count -O--C-   100   100   000-149
194 Temperature_Celsius PO---K   073   065   020-27 (Min/Max 10/35)
241 Total_LBAs_Written  -O--CK   100   100   000-287072
||_ K auto-keep

For the SSDs on my machine I'm using "ocz-ssd-utility" to get erase
count, lifetime percentage and other SMART information, let alone that
I could update the firmware, while the SSDs are used.

Re: [arch-general] Arch on NVMe ssd

[Ralph Corderoy]

Hi David,

> In normal desktop/laptop use, you rarely write more than 1-2GB a day
> on average -- so that would translate into a 190-95 year wear-life for
> the drive under normal use. Even at 10GB a day, that would be a 19
> year life for the drive.

The SSD drive also reports its own personal view of lifetime remaining
and other interesting statistics using
https://en.wikipedia.org/wiki/S.M.A.R.T%2E.

173 Ave_Block-Erase_Count   -O--CK   095   095   000-77
202 Percent_Lifetime_Remain CK   095   095   001-5

`smartctl -x /dev/sda', for example, can gather the data.

-- 
Cheers, Ralph.