Re: [arch-general] old archlinux instance repositories progress

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Tuesday, August 11, 2020 8:21 PM, Jude DaShiell  wrote:

> pacman -Sy archlinux-keyring returns error cannot update core among
> other repositories and pacman -Ss archlinux-keyring shows the keyring to
> be installed with date of 20200622-1 on it.
>

...is this the same issue as on the other discussion thread?

pacman -Ss shows the package as it's available in the repository.
If you want to see the installed package, you have to type `pacman -Qs 
[packagename]`.

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] old archlinux cannot now update

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Tuesday, August 11, 2020 5:53 PM, Jude DaShiell  wrote:

> Is a link in the archwiki on the process to point archlinux at all of the
> new repositories and import all of the ssh keys? I hadn't been able to
> access my computers while this move happened so wasn't able to do the
> necessary steps to change where archlinux finds all of its updates.


Are you sure you mean ssh keys, and not gpg keys? If the latter, please check 
out the fabulous wiki.

https://wiki.archlinux.org/index.php/Pacman/Package_signing#Managing_the_keyring

This stuff has been in place for a while therefore I much doubt you're missing 
it. It seems yet the best, however still very marginal way to make sense of 
your message.

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] Getting 404 errors while trying to install arch on a fresh system. Any rreason why?

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Monday, January 20, 2020 3:52 PM, Matthew dyer via arch-general 
 wrote:

> Hi all,
>
> Using the tarch iso from www.tarch.info http://www.tarch.info , I am

I wasn't sure what you were talking about so I checked out the website: 
Cabinets, twin size beds and ... toaster ovens?
You must have meant https://talkingarch.info/

cheers!
mar77i

Re: [arch-general] can't 'pacman -Syu' to xorgproto 2019.2-2

[mar77i via arch-general]

Did you check the news yet? I think xf86miscproto was listed there.

https://www.archlinux.org/news/xorg-cleanup-requires-manual-intervention/

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] broken pipe

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Wednesday, December 18, 2019 4:41 PM, Andy Pieters 
 wrote:

> On Wed, 18 Dec 2019 at 15:32, Pascal via arch-general
> arch-general@archlinux.org wrote:
>
> > that's awesome, it works !
> > it was so simple with cat taking over and consuming the data until the end !
> > (I added a redirect to /dev/null to cat)
> > big thank you.
>
> I'm interested in the amount of effort you put into this. Isn't the
> overhead of the pipes etc going to negate any memory/speed
> improvements you may get from only opening the file once or is there
> another consideration at play here?

IMHO, reading from memory is generally preferable to reading again from disk, 
that is, assuming a "worse" solution that would rely on multiple reads. It 
makes sure the data is actually the same data is transmitted and no other 
process writes to the file meanwhile. It's also easier to do than fiddling with 
flock() and the like. Also I'd advise against reading binary data into 
environment variables, which I think is what the approach with tee is supposed 
to solve, therefore I really like it. Technically you should be able to tee 
yourself into a full set of http headers.

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] broken pipe

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Wednesday, December 18, 2019 3:20 PM, Pascal via arch-general 
 wrote:

> hello,
>
> it works perfectly because both tools used, md5sum and sha1sum, consume all
> the data.
>
> on the other hand, the function returns wrong fingerprints if I insert a
> tool like file :


...just do >(file --mime-type -b -e compress -e tar -e elf - >&3; cat) ?


Sent with ProtonMail Secure Email.

Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required

[mar77i via arch-general]

On Wednesday, October 9, 2019 12:03 PM, Mike Cloaked via arch-general 
 wrote:
>
> Possibly intel-ucode would be very useful for many installs as well?
>

Except for people who need amd-ucode...

For a long time I was under the impression we relied on derivative distros to 
dumb down things like system maintenance and installation for "regular" users. 
The proposed "base-extra" group might be a marginally useful idea, but the 
effort seems like a shot in the dark. What problem are we solving, really?

cheers!
mar77i


Sent with ProtonMail Secure Email.

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

[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] Package grub Encourages Warnings to be Ignored.

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On Saturday, December 8, 2018 9:55 AM, Ralph Corderoy  
wrote:
>
> Can a better solution to this be engineered?
>

For the kernel we run mkinitcpio. So there shouldn't be a real reason why we 
shouldn't run grub-mkconfig >/${main_grub_dir}/grub.cfg for grub. That being 
said, the path is /boot/grub.cfg for me, so I'm not sure how we'd get the 
installfile to figure out where to output its output.

One key difference is that the output of mkinitcpio are binary files, whereas 
grub.cfg is a text file, and maybe operators would like to modify that file 
after it's generated? So one could make a case that the install file should in 
fact keep its hands off grub.cfg entirely.

cheers!
mar77i

Sent with ProtonMail Secure Email.

Re: [arch-general] Hardware portal

[mar77i via arch-general]

Saturday, November 3, 2018 6:47 PM, Andrey Ponomarenko via arch-general 
 wrote:
> Hi,
>
> Good news for everyone interested in Linux-compatibility and reliability of 
> hardware!
>
> The Linux-Hardware.org database has been divided into a set of databases, one 
> per each Linux distro. You can now select your favorite distro on the front 
> page:

Do you consider people wishing to submit reviews or collect reports from the 
interwob about folks not happy with a particular device? I know your fully 
automated approach seems like an easy kill, but really, I could upload my 
laptop to the database, but then it would nowhere tell that the particular 
laptop I'm using is known to be a piece of garbage. Wine has an approach that 
would allow me to make the case clear, but this may be orthogonal to the kind 
of thing you're doing...

Or maybe I'm misunderstanding the purpose of your database: is it supposed to 
be the central point around which people should make decisions on what hardware 
they should buy or avoid?

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] Add MIT Licence to /usr/share/licences/common

[mar77i via arch-general]

Saturday, November 3, 2018 7:53 PM, John Ramsden via arch-general 
 dixit:
> It states MIT/BSD are special cases, just out of curiousity, what makes them 
> special that they cannot be added?

Look at them: https://opensource.org/licenses/BSD-2-Clause 
https://opensource.org/licenses/MIT

For one, they're copyright notices. And they're individual for each project. 
The license states that the above copyright notice must be included in the 
license which is distributed with the project. So they can't be generalized.

cheers!
mar77i


Sent with ProtonMail Secure Email.

Re: [arch-general] xdm killed after 90 seconds

[mar77i via arch-general]

‐‐‐ Original Message ‐‐‐
On June 13, 2018 9:50 PM, Fons Adriaensen  wrote:
> Hello all,
> 
> I've got a strange problem on a newly installed system.
> About 90 seconds after it is started, xdm (or xdm-archlinux)
> and any login session is killed. Apparently by systemd,
> because of a timeout. What's happening here ?
> 

https://bugs.archlinux.org/task/58830

Fixed locally with the first two hunks skipped, which appear reversed or solved 
differently by upstream.

cheers!
mar77i


​Sent with ProtonMail Secure Email.​

Re: [arch-general] [Classroom] Python for Beginners - Part 1

[mar77i via arch-general]

On June 13, 2018 6:18 PM, Luyin via arch-general arch-general@archlinux.org 
wrote:
> On 13/06/18 16:05, Tomáš M. via arch-general wrote:
> > The plan is to start on 27th of June, Wednesday 7:00 UTC.
>
> I might be missing something here, but is that 7 AM or PM UTC?
> Best regards,
> 

As a rule of thumb, time of day would be given in 24 hour time if nothing else 
is specified.

cheers!
mar77i


​Sent with ProtonMail Secure Email.​

Re: [arch-general] Aur git - missing .SRCINFO hook declined to update refs/heads/master - help?

[mar77i via arch-general]

On June 4, 2018 12:58 PM, Bennett Piater  wrote:
> 
> Do you have an unpushed commit that may not pass muster, even if it is
> not the last?
> 
> If so, you could try squashing all unpushed commits together to one
> using git rebase.

On June 4, 2018 1:04 PM, Eli Schwartz via arch-general 
 wrote:
> That's saying that in commit 93a539f81d7d0f001dd5522781ebeabf7cf73f9d
> 
> you had committed a .SRCINFO file which listed a LICENSE file, but you
> did not commit the LICENSE file itself.
> You've got corrupted history, adding a new commit with the LICENSE file
> does not fix the old commit. Use --amend if you need to fix up old commits.

If I read this thread correctly, your git history isn't corrupt in the sense 
that it would break git, but your git history is not conforming with AUR rules. 
To obey those, reading up about git rebase [0] is the way to go. 
Keep in mind that you have to give git rebase a commit behind the one you 
intend to edit, eg. git rebase -i 93a539f~1 so you can edit (using git add and 
git commit --amend) the commit in question so it becomes acceptable. One way to 
go would be to remove LICENSE from the .SRCINFO for 93a539f so it becomes 
consistent. You can read about the details in the footnote.

cheers!
mar77i

[0] https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History



​Sent with ProtonMail Secure Email.​

Re: [arch-general] Broke Arch trying to change graphics driver

[mar77i via arch-general]

Oh wow, please apologize the original message there making my mail look like a 
top post. I intended to be smarter than my email client, only to forget about 
it.

cheers!
mar77i


​Sent with ProtonMail Secure Email.​

Re: [arch-general] Broke Arch trying to change graphics driver

[mar77i via arch-general]

> When I tried "sudo modprobe nvidia" I got an "exec format error"
> message and the nvidia module refused to load.

You need to build your driver for each kernel separately. That's why you can 
get [0] as a package.

cheers!
mar77i

[0] https://www.archlinux.org/packages/testing/x86_64/nvidia-dkms/


​Sent with ProtonMail Secure Email.​

‐‐‐ Original Message ‐‐‐

On May 5, 2018 7:01 AM, Junayeed Ahnaf via arch-general 
 wrote:

> I did a rollback too , seems like there's no easy way to go back from nonfree 
> to free drivers.
> 
> On May 5 2018, at 12:00 am, Eric Blau eb...@eblau.com wrote:
> 
> On Fri, May 4, 2018 at 1:34 PM Junayeed Ahnaf via arch-general <
> 
> arch-general@archlinux.org> wrote:
> 
> So here's what happened, I was facing issue with proprietary nVidia driver
> 
> (screen tearing) so I thought I want to switch to the free one, so I
> 
> uninstalled nvidia with "pacman -Rs nvidia" , then I thought might as well
> 
> try a different kernel and installed zen. Now when I boot into either
> 
> kernel I am seeing "Starting display manager" then a black screen. I can
> 
> login to tty2 , but no display comes up.
> 
> I want to switch back to free driver, with preferably zen kernel. What
> 
> should I do? Thanks in advance.
> 
> I just hit a similar issue when trying to switch from nvidia to nouveau. I
> 
> was trying to switch from i3/Xorg to sway/Wayland. The proprietary nvidia
> 
> driver is unsupported with sway. I uninstalled the nvidia modules like you
> 
> did, disabled the lightdm display manager, and booted into nouveau. It
> 
> worked but was much too slow to be usable with my 4K display. I was getting
> 
> major lag. It was like getting 1 HZ refresh rate moving my mouse pointer
> 
> around.
> 
> I switched back to i3/Xorg with the nvidia modules but when rebooting to
> 
> 
> The nvidia module installed to the extramodules directory so I expected it
> 
> to work with the 4.16.4 kernel I'm running even though it was built on
> 
> 4.16.1, but apparently that is not the case. Uninstalling and reinstalling
> 
> nvidia and nvidia-utils did not fix things.
> 
> Eventually I gave up and did a "zfs rollback" to restore the previous
> 
> system state and everything was fine after that. Sorry I don't have good
> 
> solution for you, but I wanted to chime in that I also encountered the same
> 
> problem and it was related to the nvidia modules not being loadable.
> 
> Regards,
> 
> Eric

Re: [arch-general] gcc broken - Arch specific, applying optimization incorrectly - may explain unexplained problems

[mar77i via arch-general]

On 03/13/2018 02:17 AM, PkmX via arch-general wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84607

Pass -std=... to compiling the programi n question. If it's in clear deviation 
of what the respective standard dictates, it's a bug.


​Sent with ProtonMail Secure Email.​

Re: [arch-general] Disable vboxadd.service & vboxadd-service.service after guest additions included in 4.15?

[mar77i via arch-general]

 Original Message 
 On February 18, 2018 9:57 AM, David C. Rankin  
wrote:
> ... I'd add this to the wiki, but it would just be removed...


You must be fun at parties.

cheers!
mar77i

​
Sent with ProtonMail Secure Email.

Re: [arch-general] Proposal: add "--disable-modern-top" to procps-ng configure flags

[Mar77i via arch-general]

> Subject: Re: [arch-general] Proposal: add "--disable-modern-top" to procps-ng 
> configure flags
> Quoth Saul Reynolds-Haertle 
>

This is an absolutely horrible response and let me tell you: telling others what
to do is not how you should live, think, use computers or (FOSS) software.
So first of all, I hope you use computers because they make getting your job
done easy enough _to you_. Anything beyond can in fact be viewed as you acting
irresponsibly.

> Apologies if this is misformatted, and I hope it works; I didn't
> expect to be responding and am working in the system optimized for
> readability over composition.

What does your first paragraph even mean? You hope we see your reply in a way
that pleases us, which might be on braille readers or piped to espeak to be
played on commute. You carry a hint of how others are supposed to receive your
content, and you state this first, maybe because you think that's more important
than what you're actually saying. Then you say something about how you have to
be "working in the system", which I'll just interpret as you running your mail
program as root. *shrug*. That system is then optimized for readability over
composition. Both terms so overused since the invention of the personal computer
that I don't even remember what they mean any more.

> I subscribed to this list just last night in hopes of gaining better
> visibility into the tools that I use. I have, and I think that I

The twist in "gaining better visibility into the tools that I use" is nothing
short of brilliant. I hardly understand the sentence, right between "you'd like
to gain better visibility", as in you want to be seen and
"visibility into the tools", which might mean that you imagine you're swimming
in more bright blue waters somewhere closer to where the software you're using
comes from.

Thing is that this isn't some zelda role-playing game. You're talking to actual
people with actual responsibilities and actually share their time with their
work, their families and whomever else they decide to spend their lives with.

> should report my findings. This thread has convinced me to, first,
> unsubscribe from this list immediately, because the information isn't
> worth exposure to this kind of toxicity, and second, start moving away
> from Arch, because I can't trust it to ship good code.

So one thing that hasn't existed 10 years ago is framing fiction as facts like
you are doing it here. You're basically imagining that you have to stay away
from discussions where somebody tells you you're wrong, and completely
caricature any act of verbal violence against you by completely ignoring whether
they might have had a point. Either you're caught in a case of backfire effect
or you were told how terribly things were going around here only looking for
some confirmation - See also: confirmation bias.

> The immediate response and a good bit of the followup was acutely
> hostile to both the reporting user and to the ability of this
> community to build good software. It argues to me that I cannot trust

Community? Build? Good? Software? Dude, most of us got the package in question
on their hard drive from a pacman -S under some sort of brain-outage or
automatically by whatever installation script they had at the time they
installed it. That said, yes, some hostility might occur.
I'll get to what you should do with it in a minute.

> Arch to comprehend a world outside its little bubble, think about its
> users, acknowledge possible bugs that aren't instantly obvious to the
> Arch staff, cause issues to be upstreamed, or maintain a climate of
> discussion that is conducive to discussing problems and fixing
> them. Evaporative cooling of group beliefs ensures that
> honesty-brutality culture inevitably spirals into a festering
> close-minded pit that cannot accept outside contributions or think of
> the bigger picture. Maintaining the free flow of information is
> important, but it must be done in the context of the larger community
> a tiny walled-off group can communicate as freely as it wants inside
> itself, but if nothing goes over the wall there might as well be no
> free flow at all.

You know you're slandering. What you're saying is because you did not get your
say, nobody gets their say even if they might be right, and the people who
create the content (PKGBUILDs for our packages) have all the time they need to
grant every unimportant user's wish. Last time I checked, nope, that's not the
case. Double-checking, because you seem desperate, nope, still not the case.

> Even if the original report was not flawless, even if it was a repeat,
> even if it was sent to the right people, hostile repression was not
> the correct response. If nothing else, the fact that it's a repeat
> should be demonstrated and more deeply evaluated. This time it ended
> up working out, but if this is representative of the Arch community I
> can't trust it to handle other bugs. How many more