- Arch-general - lists.archlinux.org

[arch-general] Please update the dotnet packages
by Marc Ranolfi 26 Oct '19

26 Oct '19

The 'dotnet-sdk' and 'dotnet-runtime' packages have been marked as out-of-date on 2019-08-02. I would like to encourage the maintainer to update them as soon as possible. https://www.archlinux.org/packages/community/x86_64/dotnet-sdk/ Thanks. Marc

1 0

[arch-general] 'base' package install with non-updated linux-kernel
by riveravaldez 26 Oct '19

26 Oct '19

Hi, because of this problem [1] (apparently a kernel/driver/hardware issue?) I'm forced to stay on linux-5.2.14-arch2-1 right now. My question is: should/can I anyway install the 'base' package anyway as explained in [2]? Thanks a lot [1] https://bbs.archlinux.org/viewtopic.php?id=249330 [2] https://www.archlinux.org/news/base-group-replaced-by-mandatory-base-packag…

5 5

Re: [arch-general] talkingarch
by William Bevans 26 Oct '19

26 Oct '19

I think it's trying to communicate with us. On Sat, Oct 26, 2019, 7:09 AM adérito <aderito.carvalho(a)sapo.pt> wrote: > Hello, you have the tharch then the INTAL Monthly Newsletter June on > another server? that in www.tarch.org is INTAL Monthly Newsletter INTAL > Monthly Newsletter October but October is not working very well did not > detect the Internet connection on virtualbox you can report the developer > who do not have the email dezenvolvedor the tharch. because the INTAL > Monthly Newsletter June connect to internet. and the script F123 light was > included in INTAL Monthly Newsletter of October tharch. but the script does > not detect the wired network virtualbox. > > Enviado do Correio para Windows 10 > >

1 0

[arch-general] talkingarch
by adérito 26 Oct '19

26 Oct '19

Hello, you have the tharch then the INTAL Monthly Newsletter June on another server? that in www.tarch.org is INTAL Monthly Newsletter INTAL Monthly Newsletter October but October is not working very well did not detect the Internet connection on virtualbox you can report the developer who do not have the email dezenvolvedor the tharch. because the INTAL Monthly Newsletter June connect to internet. and the script F123 light was included in INTAL Monthly Newsletter of October tharch. but the script does not detect the wired network virtualbox. Enviado do Correio para Windows 10

1 0

Re: [arch-general] �� ?
by Jonathan Horacio Villatoro Córdoba 25 Oct '19

25 Oct '19

Upon checking the message headers, I found the following: ... >Reply-To: prodawez(a)teleworm.us, ... On Thu, Oct 24, 2019 at 11:39:12PM +0100, arch-announce(a)archlinux.org wrote: > Вас интересуют базы данных? > _______________________________________________ > arch-announce mailing list > arch-announce(a)archlinux.org > https://lists.archlinux.org/listinfo/arch-announce I believe it's safe to say this is a spam message. AFAIK, teleworm.us is a service that provides anonymous temporary email addresses. HTH. Best, Jonathan

2 1

[arch-general] Issue with 'eject -T'
by Ralf Mardorf 19 Oct '19

19 Oct '19

Hi, 'eject -T' doesn't work anymore on my machine, resp. opening the DVD drive doesn't work anymore, when using the traytoggle option. Opening still works without an option and closing with the traytoggle option also still works. $ eject -V eject from util-linux 2.34 $ eject -T eject: CD-ROM eject command failed: Device or resource busy $ grep util-linux /var/log/pacman.log | tail -6 [2019-06-21 08:19] [ALPM] upgraded libutil-linux (2.33.2-1 -> 2.34-2) [2019-06-21 08:19] [ALPM] upgraded util-linux (2.33.2-1 -> 2.34-2) [2019-06-21 08:19] [ALPM] upgraded lib32-util-linux (2.33.2-1 -> 2.34-1) [2019-06-29 11:40] [ALPM] upgraded libutil-linux (2.34-2 -> 2.34-3) [2019-06-29 11:40] [ALPM] upgraded util-linux (2.34-2 -> 2.34-3) [2019-10-06 12:37] [ALPM] reinstalled util-linux (2.34-3) I don't know when the issue started, but I'm quite sure it still worked last month. I'm usually using 'eject -T' to open or close the DVD drive by a keyboard shortcut. I accidentally reinstalled util-linux a few days back, IOW that it was reinstalled is meaningless, it might be that it even still worked this time. Could somebody with an up to date Arch Linux install please run 'eject -T' from command line? I want to know if it's an issue on my side or if it's a regression of a dependency or something else unrelated to my machine. TIA, Ralf -- $ uname -r 5.2.21-rt13-0-pussytoes

2 2

Re: [arch-general] Feature Request: Adding Alternate Base Package
by Mohamad Mounir Safadieh 17 Oct '19

17 Oct '19

The idea of a "base-extras" package containing the old base packages has already been discussed on arch-dev-public. https://lists.archlinux.org/pipermail/arch-dev-public/2019-October/029693.h… This implies that it's very likely to happen. :-) On Oct 17, 2019, 8:02 AM -0400, arch-general-request(a)archlinux.org, wrote: > Send arch-general mailing list submissions to > arch-general(a)archlinux.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.archlinux.org/listinfo/arch-general > or, via email, send a message with subject or body 'help' to > arch-general-request(a)archlinux.org > > You can reach the person managing the list at > arch-general-owner(a)archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of arch-general digest..." > > > Today's Topics: > > 1. Feature Request: Adding Alternate Base Package Groups to > Installation Media (Ben Pont) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 16 Oct 2019 16:40:22 -0500 > From: Ben Pont <benpont(a)gmail.com> > To: arch-general(a)archlinux.org > Subject: [arch-general] Feature Request: Adding Alternate Base Package > Groups to Installation Media > Message-ID: > <CALJ1B=s3APKAFDtUTHSGtehUhSqAAY2EsrcYZ=1oVtDJFWOONA(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > With the recent transition from the base package group to the base meta > package, I was wondering whether or not it would be useful to include a > 'base-typical' or 'base-standard' package group to the installation media. > The menu choices during an installation could possible be even more > expansive in its package group options, similar to how RHEL does it via > their 'environment' package groups (e.g. Minimal Install, Compute Node, > Infrastructure Server, GNOME Desktop, etc.). > > For example, each alternative package group could *include* the base meta > package, then add in the additional packages necessary for a particular use > case, (not least of which would be a kernel). The advantage would be that, > after installing the system, users would have the option to cherry pick > *out* unnecessary/unwanted packages from their chosen installation package > group, instead of having to cherry pick packages *into* their system as > would likely be necessary using only the base meta package. It seems like > many new and inexperienced users might become confused when they install a > new system using only the current base meta package and then realizing they > don't have the necessary tools they would normally assume comprises a base > installation (i.e. a kernel, editor, etc.). > > Additionally, 'pkgstats' could (at least temporarily) be included as a > dependency for both the base meta package and any optional base package > groups to get stats on how many users are solely installing the base meta > package versus the optional base package group alternatives. I'm guessing > only a minority of users would choose the base meta package as their sole > installation option, but it would probably be useful to know either way. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > arch-general mailing list > arch-general(a)archlinux.org > https://lists.archlinux.org/listinfo/arch-general > > > ------------------------------ > > End of arch-general Digest, Vol 180, Issue 12 > ********************************************* >

1 0

[arch-general] Feature Request: Adding Alternate Base Package Groups to Installation Media
by Ben Pont 16 Oct '19

16 Oct '19

With the recent transition from the base package group to the base meta package, I was wondering whether or not it would be useful to include a 'base-typical' or 'base-standard' package group to the installation media. The menu choices during an installation could possible be even more expansive in its package group options, similar to how RHEL does it via their 'environment' package groups (e.g. Minimal Install, Compute Node, Infrastructure Server, GNOME Desktop, etc.). For example, each alternative package group could *include* the base meta package, then add in the additional packages necessary for a particular use case, (not least of which would be a kernel). The advantage would be that, after installing the system, users would have the option to cherry pick *out* unnecessary/unwanted packages from their chosen installation package group, instead of having to cherry pick packages *into* their system as would likely be necessary using only the base meta package. It seems like many new and inexperienced users might become confused when they install a new system using only the current base meta package and then realizing they don't have the necessary tools they would normally assume comprises a base installation (i.e. a kernel, editor, etc.). Additionally, 'pkgstats' could (at least temporarily) be included as a dependency for both the base meta package and any optional base package groups to get stats on how many users are solely installing the base meta package versus the optional base package group alternatives. I'm guessing only a minority of users would choose the base meta package as their sole installation option, but it would probably be useful to know either way.

1 0

[arch-general] Package guidelines 📦
by Alberto Salvia Novella 15 Oct '19

15 Oct '19

I want to suggest including all or some of these in the package guidelines <https://wiki.archlinux.org/index.php/Arch_package_guidelines>, or the appropriate documentation: *New items:* - Write your PKGBUILD in a way that will work by itself as long as possible, for example by automatically generating the list of archives instead of hard coding them. - As far as practicable don't work around bugs on the package, but fix them as upstream as possible. - In package() "mv" locally built files, and "cp" or "install" the rest. - In pkgdesc don't describe what the package is, but rather what it does. Using a natural wording that any person will understand. For example don't say "GTK UVC video viewer", but "Captures image from a webcam". - If the license is a Creative Commons one, write it like "CCPL:by-sa". *Modifications:* - Start new variables and functions names with a capital letter, to avoid clashes with those in makepkg itself. - In pkgver(), any printf() line shall finish with the new line char (\n). *Useful functions:* In package(), you can set permissions recursively with: find "${pkgdir}" -type d -exec chmod u=rwx,g=rx,o=rx {} \; find "${pkgdir}" -type f -exec chmod u=rw,g=r,o=r {} \; chmod +x "${pkgdir}/usr/bin/${Name}" In pkgver(), you can get the version from a web-site with something like this: curl --silent "${url}" | grep "${string}" | cut --delimiter='"' --fields=1 (Reply to this email including me on the recipients list, or I won't receive it)

11 17

[arch-general] Kernel 5.3.5 and Kernel 5.3.6 perl warnings
by Jude DaShiell 15 Oct '19

15 Oct '19

If you start getting warnings that perl failed to set locale that didn't happen on earlier versions of the kernel I know how to fix that. First you have to have everything correct in /etc/locale.conf. If that's the case, add to your ~/.bash_profile file source /etc/locale.conf then save the edit and do source ~/.bash_profile then run your perl application like maybe cpanplus or irssi and if everything works on your system like it does on my system you won't get those warnings again. --

2 2