Re: [arch-general] "npm" package issues
On 11/4/20 1:03 PM, Greg Minshall via arch-general wrote: > this is just a status update, mostly for anyone in the future who might > find this useful for their problem. but, if anyone in the near-present > has any comment, i'm happy. (and, i appreciate all the help up to now!) > > presumably this is all fallout from some historic "npm update -g". > > way too many details follow. > > i removed all files from /usr/lib/node_modules/npm/node_modules *not* > owned by the npm package. > > then, [pacman -Syu] (without '--overwrite', as the offending files have > been removed)succeeded. > > but, in the output, immediately after > > (192/192) checking available disk space > > (and some trailing ###...) > > there were a number of lines like > > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/meant/.npmignore > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/meant/.travis.yml > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/ > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/ > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/.travis.yml > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/LICENSE > warning: could not get file information for > usr/lib/node_modules/npm/node_modules/rc/node_modules/minimist/example/ > > [pacman -Qo] says they are all owned by no package. if that is so, what > is causing the upgrade process to look for them? This pacman warning indicates that while deleting the files from the old copy of the package, it could not find some files to delete, before installing the new copy of the package. The files should definitely be owned, though... I suspect your issue is due to upgrading the pacman version, resulting in some files that could not be deleted due to not existing, but were not part of the new package and therefore did not exist afterward either. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Makepkg: Incremental builds
On 11/2/20 1:39 PM, LuKaRo wrote: > Hi everyone, > > I'm currently building ungoogled-chromium from AUR, which is running for > 6 hrs now on my 6-core i7-9750H laptop and almost done. However, I'm > thinking about what happens when the next version will be released. From > my understanding, when running git pull to fetch the latest version from > AUR and afterwards makepkg -sri, the old binaries will be deleted prior > to starting the build, which will probably require to build everything > from scratch. Am I right? > > However, I'm sure that only parts of the source change between versions. > Therefore, only parts of the binary files would need to be built again, > which would dramatically decrease build time. Correct? How can I make > use of incremental builds using makepkg? I'm aware of the -e switch, but > that would skip the prepare function, which might be required as e.g. > new patch files from AUR would need to be applied. makepkg --noextract will continue a build you have interrupted using CTRL+C, it does not perform "incremental" builds for the next version of the software. > Furthermore, the timestamps of the source files all seem to be set to > the archival date. This would probably also require a full build, even > if only parts of the source changed. Correct? If yes, is there a way to > fix that? The source extraction naturally overwrites every single file in the current source archive, and updates timestamps in the process. Otherwise, how would you get the new source code? ;) Using bsdtar to unpack a tarball doesn't exactly know which files should be skipped due to not changing... > Having to spend 6-7 hrs of build time on each new release would make > frequent updating impractical. You have two options: - use ccache to cache compiler results, for unchanged source files and unchanged recursive includes you often won't need to recompile and ccache's gcc wrapper will instead output the file from the cache for significant speedup - use git+https:// based sources, since git *can* (and does) figure out which files need to be modified on disk in order to be updated to the desired revision. makepkg -sri for git-based source code does indeed play quite nicely with incremental builds -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] sysstat man-page wrong
On 10/30/20 5:12 AM, Yi Zheng via arch-general wrote: > /usr/share/man/man1/pidstat.1.xz.gz is compressed twice. > > man: warning: /usr/share/man/man1/pidstat.1.xz.gz: ignoring bogus filename > No manual entry for pidstat > > Could you please fixup that defect? https://bugs.archlinux.org/task/67703?project=5=sysstat -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] usbguard package neglected
On 10/26/20 10:36 AM, arch user via arch-general wrote: > Sorry for the late answer but I had a second thought about it recently > and have found several reasons why to update USBGuard anyway: > > 1) It is open source. If there are trust issues one can look at the > source code and check what has changed between versions. Doing a security audit is expensive and time consuming. Not doing a security audit means "look at the source code and see what changed" accomplishes nothing whatsoever -- we know there are changes or there would not be a new version, but can you prove there are no hidden back doors? > 2) Developers of other packages don't ever sign their commits so they > don't have a chain of trust at all. While a broken chain of trust might > be a step backwards, it is still equivalent to having none. Absolutely not at all. Projects that never signed their software are like people who live in a neighborhood where no one locks their front door, because it's too much work to fiddle with a door key. Projects with a a broken chain of trust are like that one person who *does* lock his front door, but one day the lock got ripped off the door and replaced by a gaping hole. It is hugely suspicious and everyone walking down the street has good reason to notice and suspect a robbery occurred. Now, it's *possible* the owner lost his key and destroyed his own front door in order to get back into his own house. But is it likely? You could ask him, but he's a recluse slash internet person, so you're not really sure what he looks like. The guy wandering around inside the house might be the owner, but he might also be a thief... what do you do? > 3) Other Linux distributions have updated the package as well. This > might seem like a weak reason but if I think about it, I find that it > resembles some kind of peer review. ... apparently you say "oh, I guess you're the owner then, sorry to bother you. BTW you should probably fix your door because it looks weird now. No pressure." That's indeed weak. What kind of peer review are you claiming this is, exactly? ... The point of a signing key is to say "this key certifies the correct software and I commit to using it. Anything else is automatically suspect as malware". You don't immediately respond by saying "well it came from the same website and some unverified source told me the key totally got lost but it's fine. So let's blindly click accept". It doesn't matter if other distros are okay with that. Arch Linux is not. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Missing sys_siglist declaration
On 10/1/20 3:28 PM, Hauke Fath wrote: > On Thu, 1 Oct 2020 13:57:09 -0400, Eli Schwartz via arch-general wrote: >> From the glibc 2.32 release notes: >> >> Deprecated and removed features, and other changes affecting compatibility: >> [...] >> * The deprecated arrays sys_siglist, _sys_siglist, and sys_sigabbrev >> are no longer available to newly linked binaries, and their declarations >> have been removed from . They are exported solely as >> compatibility symbols to support old binaries. All programs should use >> strsignal instead. >> >> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b1ccfc061feee9ce616444ded8e1cd5acf9fa97f > > Thanks! I'll look into that. As I said, the strsignal(3) man page still > refers to sys_siglist, so that would need updating. Indeed it does, you can report a documentation bug here: https://www.kernel.org/doc/man-pages/reporting_bugs.html Thanks! -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Missing sys_siglist declaration
On 10/1/20 11:45 AM, Hauke Fath wrote: > Hi, > > on an arch machine updated yesterday, my XEmacs does not build because > the 'sys_siglist' declaration is gone from , where the > strsignal(3) man page says it should be. > > Searching the usual suspects didn't bring up anything. What did I miss? From the glibc 2.32 release notes: Deprecated and removed features, and other changes affecting compatibility: [...] * The deprecated arrays sys_siglist, _sys_siglist, and sys_sigabbrev are no longer available to newly linked binaries, and their declarations have been removed from . They are exported solely as compatibility symbols to support old binaries. All programs should use strsignal instead. https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=b1ccfc061feee9ce616444ded8e1cd5acf9fa97f -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Abuse of arch wiki?
On 9/24/20 6:09 PM, David C. Rankin wrote: > On 9/24/20 1:55 PM, Eli Schwartz via arch-general wrote: >> Mirroring a really old copy of the wiki is kind of unethical because >> they're spreading ancient out of date knowledge pretending to be modern, >> but I don't see how it's a problem for attribution. >> >> Moreover, they're not the only ones doing similar, see for example >> https://aur.tuna.tsinghua.edu.cn/ > > Seems a diplomatic cease-and-desist letter is in order giving them the > opportunity to bring the mirror current if they choose that course and that is > acceptable to arch. Which website are you referring to? And what, specifically, do you think they're doing wrong? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Abuse of arch wiki?
On 9/24/20 1:05 PM, LuKaRo wrote: > Hi, > > I was searching for information on firejail, when the fourth hit on my > search engine was: > https://www.linuxsecrets.com/archlinux-wiki/wiki.archlinux.org/index.php/Firejail.html. > This looks like an exact copy of our archlinux wiki (including the > header bar) but hosted on Google's servers with no administrative > contact given. They also seem to run additional obfuscated JavaScript on > "their" copy of arch wiki. > > Their main page's "about us" page gives just a 404 error, and there is > no further imprint given. However, on their main page it says "Copyright > Linuxsecrets.com. All Rights Reserved". It looks like they at least > tried to copy ArchLinux Forums, Ubuntu Forums and Linux Mint Forums as > well. > > I know that GNU FDL allows redistribution of content, but I do think > that copying the entire wiki with no attribution or information at all > violates at least ethical principles. They also copy the wiki login > page, which is also interesting from a security point of view. An > unknowing user is misleaded by this content, and considering that this > site was the fourth hit on a common search term in my search engine I'm > worried by the impact. At least I wanted to make you aware of that our > arch wiki contents are copied without any notice. https://bbs.archlinux.org/viewtopic.php?id=247141 https://www.reddit.com/r/archlinux/comments/i1d8ab/what_is_up_with_this_website_is_it_just_a_mirror/ As far as I can tell, this is just a mirror? The attribution is pretty clear, it claims to actually be wiki.archlinux.org and refers to it being graciously hosted by www.archlinux.org on https://www.linuxsecrets.com/archlinux-wiki/wiki.archlinux.org/index.php/ArchWiki:About.html (Mind you, they have various broken links due to statically rewriting all urls as "foo.html" instead of the original "/index.php/foo" and this then causes browsers to mishandle any pages that contain a ":" in it, e.g. "Special:Random" or "Help:Style" or "ArchWiki:About".) Mirroring a really old copy of the wiki is kind of unethical because they're spreading ancient out of date knowledge pretending to be modern, but I don't see how it's a problem for attribution. Moreover, they're not the only ones doing similar, see for example https://aur.tuna.tsinghua.edu.cn/ -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [off-topic] Alternative to Thunderbird, with GPG support, caldav + cardav support, and ics remote webcal support and syncing
On 9/11/20 5:51 PM, Javier via arch-general wrote: >> Note that Thunderbird still does support the GPG keyring for your >> private key material via a config option. >> > > According to these: > > https://blog.thunderbird.net/2020/09/openpgp-in-thunderbird-78 > https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq > > Only for private key operations, so not the GPG keyring for public > keys. [...] Yes, that is why my message literally said "for your private key material". My point was that this might be good enough for you; it is good enough for some people. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [off-topic] Alternative to Thunderbird, with GPG support, caldav + cardav support, and ics remote webcal support and syncing
On 9/11/20 5:18 PM, Javier via arch-general wrote: > Until Thunderbird v68, it was the option through the enigmail, > lightning and the cardbook extensions, but I really don't want to > keep using Thunderbird v78 and beyond any more. I don't like several > design decisions made by the Thunderbird team, regarding how they'll > handle PGP, like not using the GPG keyring, not using the GPG agent, > not integrating with GPG in general, and neither supporting autocrypt > initially (which should be a must to release, or so I think, even K9 > for android supports it). Note that Thunderbird still does support the GPG keyring for your private key material via a config option. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] conflict on /usr/bin generated by tigervnc?
On 9/9/20 8:55 PM, karx via arch-general wrote: > Shouldn't we put something up on the main page about this? You're right. Let me go put up a news post for this. How does this sound? Title --- Don't do stupid things without asking Body --- In the event you ever get told a package cannot be installed due to file conflicts with another package, don't try to force it anyway, using non-default options which self-describe as "bypass [safety] checks", that you need to go out of your way to use, especially if you haven't been told to do so. If you actually needed to do manual intervention, we would have published a news post. Just sit tight and wait for a non-broken package to be available for properly installing. Before you pointlessly wreck your system, at least ask on the forum or mailing list first. This message brought to you by the department of the obvious. /s ... The default expectation is you don't use --overwrite unless explicitly told to do so. We won't put up news posts for everything you shouldn't have done. If you somehow do it anyway and post asking for help repairing your system, we will try to help you, but we'll also make sure to lecture you on why it's a bad idea to do it and how you should think twice next time. Do NOT use an emergency repair tool for routine upgrades, only do so when you fully understand why you're doing it, OR the developers of Arch have told you it's the correct approach. If in doubt, ask. And I would like to reiterate: really, really, REALLY, do not use --overwrite unless you know what you're doing or have done as the OP did and asked (and been told to do so). The entire *point* of the option is to declare that your Arch installation is broken and you need to tell pacman that pacman is wrong about your files. By stepping off the beaten path, you incur the possibility of being wrong and making things a lot worse. Do NOT use --overwrite unless you know what you're doing. DO what the original poster did, and ask the experts before proceeding. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] conflict on /usr/bin generated by tigervnc?
On 9/9/20 7:41 PM, Javier via arch-general wrote: > error: failed to commit transaction (conflicting files) > tigervnc: /usr/sbin exists in filesystem (owned by filesystem) > Errors occurred, no packages were upgraded. > > Usually that get fixed by using "--overwrite /usr/sbin". But I find > it wrong for tigervnc to own "/usr/sbin", so I think in this case > tigervnc is not right. Would this be the case, or it's OK for > tigervnc to be the owner and then to overwrite? It is very wrong; the package doesn't even install during the post-build lint checks and should therefore never have been released by the maintainer. In upstream commit https://github.com/TigerVNC/tigervnc/commit/1af1cfdf8709dd1a5574efa19fb4f0e68a98021e#diff-5257b0445ad1f985acf062f6589461df a new file got added, and installed to CMAKE_INSTALL_SBINDIR, which defaults to "sbin" and on Arch must be "bin". This failed to happen; it's a bug in the package. Under no circumstances should the filesystem layout be deleted and replaced by this package as it would break everything... https://bugs.archlinux.org/task/67861 is the correct solution. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] drop dependencies on legacy inetutils for `hostname`
On 8/27/20 3:37 PM, Geert Hendrickx wrote: > On Thu, Aug 27, 2020 at 15:27:19 -0400, Eli Schwartz via arch-general wrote: >> On 8/27/20 3:17 PM, Geert Hendrickx wrote: >>> On Thu, Aug 27, 2020 at 14:34:41 -0400, Eli Schwartz via arch-general wrote: >>>> Why is it bad if you have it installed but not running? >>> >>> >>> FS#41834 as an example. Or FS#28819. There is just no good reason >>> to keep dragging purely historic crap like inetutils on so many Arch >>> systems just because a few common tools want `hostname`. >> >> That's just a bug in packaging. :p It's the same bug if you genuinely >> want to have telnet installed due to being a fan of telnet, and install >> it manually. > > > > Ok, FS#61041 then ;-) (still open) > > > Anyway, the next sentence still stands; it's just deprecated. > > We made efforts deprecating ifconfig years ago[*], then why > not rsh and friends? Well, ifconfig is deprecated by the fact that upstream software dropped it in favor of iproute2. I've already pointed out I agree with the upstream patches to drop hostname in favor of uname -n. That doesn't mean it's bad if ifconfig is installed, and in fact, net-tools, which provides ifconfig, is still in [core], and still has packages which depend on it, and probably has users who prefer it instead of `ip`. Likewise, it shouldn't be bad to have inetutils installed, merely... deprecated. I encourage upstream projects to get with the times and use uname -n. ;) Thank you for doing your part to make the world a little bit less of an inetutils-using place! That doesn't mean Arch needs to change how hostname is packaged, though. Inert software that merely sits on your disk should not be problematic, no matter how old-fashioned or even buggy it is, unless: - you actually try running it - or services run it automatically by default, but they should not be enabled by default - or unless it is setuid (rcp/rlogin/rsh are indeed, and if they are in fact dangerous this needs to be fixed directly as rexec was, rather than endangering the telnet lovers). -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] drop dependencies on legacy inetutils for `hostname`
On 8/27/20 3:17 PM, Geert Hendrickx wrote: > On Thu, Aug 27, 2020 at 14:34:41 -0400, Eli Schwartz via arch-general wrote: >> Why is it bad if you have it installed but not running? > > > FS#41834 as an example. Or FS#28819. There is just no good reason to keep > dragging purely historic crap like inetutils on so many Arch systems just > because a few common tools want `hostname`. That's just a bug in packaging. :p It's the same bug if you genuinely want to have telnet installed due to being a fan of telnet, and install it manually. >> Or 4) submit upstream patches to make such programs first try to read >> /proc/sys/kernel/hostname instead of shelling out, or invoke `uname -n` >> rather than `hostname`. > > > Yes, that's what I just added. ;-) However `cat /proc/sys/kernel/hostname` > is even less portable than `hostname`. `uname -n` is defined by POSIX and > thus preferred. A few upstreams already agreed on that. I do entirely agree, but xorg-xinit was special-casing Linux *anyway*, and /proc/sys/kernel/hostname should work on any system with a Linux kernel regardless of installed tools. >> The gettext thing seems like deep, dark magic, [...] I don't think we >> should be relying on this level of indirection. It could be dropped at >> any time. > > > Yes, I realized that once looking deeper into the gettext implementation, > it should not be relied on. If we really want a /usr/bin/hostname in base, > better just make it a wrapper around `uname -n`. > > >> Eventually we will have >> https://wiki.archlinux.org/index.php/User:Allan/Alternatives and then >> you could install your own preferred hostname implementation without >> conflicts. It would not be unreasonable at that time to make packages >> depend on a virtual provides for "hostname". > > > Seems overkill for trivial utilities like hostname. It's not like > switching between different JDK implementations or such. > > > Geert > > > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] drop dependencies on legacy inetutils for `hostname`
On 8/23/20 10:50 AM, Geert Hendrickx via arch-general wrote: > Hi > > A number of packages depend on inetutils merely for the `hostname` command. > Common packages include xorg-xinit and mariadb, which makes that inetutils > is still installed on a large number of Arch systems, although its other > components like rcp, rsh, talk, telnet ... and their server counterparts, > are really old, deprecated, and totally insecure. Plus the implementation > seems to be largely abandoned by upstream (see FS#61041). Needless to say, > I don't want any of these installed on my systems. Why is it bad if you have it installed but not running? Anyway, xorg-xinit could probably not depend on inetutils at all, since it only uses it to check `xauth list "$(hostname -f)"` which will always fail because you actually do not want the --fqdn there. (For some odd reason it only does this if you're using Linux *and* a GNU implementation like the inetutils or gettext ones, but for busybox it omits the -f, even though busybox supports -f.) It makes no practical difference whether the routine fails because of a programming error or because of a missing dependency. You could use https://www.archlinux.org/packages/community/any/sx/ which doesn't depend on inetutils. For xorg-xinit, Geert's proposed patch gets rid of the incorrect -fqdn as a side effect of switching to the portable uname -n. > Since `hostname` is still somewhat common though, there are probably more > implicit dependencies on it, for example FS#66603. > > So I would like to eliminate dependencies on inetutils just for hostname, > in one of the following ways: > > 1/ Split the inetutils package and provide hostname as a sub-package (but >then still need to maintain inetutils) > > 2/ Package the Debian implementation, also used by Fedora and others (but >this includes other legacy shit like `nisdomainname` and `ypdomainname`) >See https://packages.qa.debian.org/h/hostname.html > > 3/ Use the implementation provided by gettext (/usr/lib/gettext/hostname), >which is already part of base, and thus eliminates the need for explicit >dependencies. Although this implementation can only *get* the hostname, >not *set* it, that's all the dependent packages need, and setting the >hostname is nowadays handled by systemd's `hostnamectl` anyway. Or 4) submit upstream patches to make such programs first try to read /proc/sys/kernel/hostname instead of shelling out, or invoke `uname -n` rather than `hostname`. The gettext thing seems like deep, dark magic, and the fact that a hostname program even exists in there is due to deep dark magic inside /usr/bin/msginit which invokes the shell script /usr/lib/gettext/user-email in order to grep various programs (mutt, openoffice, Thunderbird, netscape, emacs) with complicated fallbacks before prompting you to select an option or input your own email address when authoring a PO translation file. I don't think we should be relying on this level of indirection. It could be dropped at any time. > My preference would be 3/, for simplicity. I already run my systems with > /usr/bin/hostname symlinked to /usr/lib/gettext/hostname (after forcibly > removing inetutils), and noticed no issues. > > This can be done in two steps: > i. make the gettext package install (or symlink) /usr/bin/hostname, > drop it from inetutils, and introduce mutual conflicts on older > versions of each. > ii. drop the dependency on inetutils from other packages (or replace it > with a dependency on hostname if options 1/ or 2/ are preferred). > > Fans of `telnet` can continue to install inetutils manually, of course. ;-) Eventually we will have https://wiki.archlinux.org/index.php/User:Allan/Alternatives and then you could install your own preferred hostname implementation without conflicts. It would not be unreasonable at that time to make packages depend on a virtual provides for "hostname". -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] netcl leaves network down until reenable performed - do we need note?
On 8/17/20 5:56 PM, Eli Schwartz wrote:
>> Couldn't there also be a post install that does a reenable for each netctl
>> profile found in /etc/systemd/system as another option to avoid this SNAFU?
>
> That might have been an interesting precautionary measure for netctl
> 1.18, at least for printing a message advising people to reenable the
> service.
Oh, for the record -- it looks like netctl already did this:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/netctl.install?h=packages/netctl
post_upgrade() {
if [[ $(vercmp 1.18 "$2") -gt 0 ]]; then
grep -ls '^.include ' /etc/systemd/system/netctl@*.service | \
while read -r unit; do
profile=$(systemd-escape --unescape "${unit:27:-8}")
echo ":: The unit for profile '$profile' uses deprecated
features."
echo " Consider running: netctl reenable $(printf '%q'
"$profile")"
done
fi
}
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] netcl leaves network down until reenable performed - do we need note?
On 8/17/20 5:25 PM, David C. Rankin wrote: > Archdevs, > > I have two computers using netctl, one for a static and one for a dhcp > address. After the last update on May, 3, > > netctl (1.22-1 -> 1.23-1) > > all remained fine and old profiles generated as subservices in > /etc/systemd/system, such as: > > netctl\@rlf_network\\x2dstatic.service > > continued to bring the network up. However within the past week there was a > change, likely to systemd 246, that no longer respects the subservices > originally created by netctl. Now attempting at reboot causes the network to > fail completely. Not good for remotely adminned boxes. > > What is required is a "reenable" of the netctl profile. Doing so will remove > the old subservice and symlinks and replace then with a directory in > /etc/systemd/system of same name as the old subservice, but with a ".d" > appended that now contains a "profile.conf", e.g. By "subservice" I think you mean ".include" stanzas? Your analysis is correct, this got removed from systemd here: https://github.com/systemd/systemd/commit/7ade8982ca1969e251a29589ae918c3b5c595afb and systemd 246 is the first release with its removal. However, netctl migrated over to *.d dropins here: https://git.archlinux.org/netctl.git/commit/?id=04d39b2573bd34d4159837afdb4793a0990bd44a So I think you should be fine if you've re-enabled the netctl profile with 1.18 or higher (released on 2018-08-07). That's 2 years. Granted, if it's been working for years, why would anyone care about manually re-enabling their netctl profile... but... There should also probably have been a warning logged in journalctl for this, if your service was still using the old method. > netctl@rlf_network\x2dstatic.service.d/ > └── profile.conf > > However, there is no note or warning during update that any manual > intervention will be needed. That will leave anyone adminning a remote arch > install with netctl with a box that is unreachable and has no network. > > Shouldn't there be a warning about this change generated on update? Arch is > always pretty good about warning when manual interaction is required -- and > this is a biggie. I'm not sure it merits a news post for something that old which is only now becoming fatal. Hopefully anyone with remotely adminned boxes caught this while monitoring journalctl logs. But, thanks for posting this to the list -- at the very least, people in the same situation will be able to figure out what happened by reading here. And hopefully they will see this *before* upgrading. > Couldn't there also be a post install that does a reenable for each netctl > profile found in /etc/systemd/system as another option to avoid this SNAFU? That might have been an interesting precautionary measure for netctl 1.18, at least for printing a message advising people to reenable the service. I'm not sure it makes sense to do that automatically, since disabling a profile removes customizations and the netctl manpage explicitly warns you to be careful about doing so. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Telinit?
On 8/16/20 9:30 PM, David Rosenstrauch wrote: > There's no need to be rude. I didn't ignore your email, and I snipped > it from my response for brevity's sake to spare the list from > unnecessary sprawl. There is no ambiguity here. You suggested that this change causes Arch to deviate from upstream. The part you snipped explained how it does not, in fact, deviate from upstream. A couple of lines isn't huge sprawl. But I wouldn't care if you quoted it or not, as long as your response made it likely you read and internalized it... But, you went from me saying this (snipped) "the upstream install layout no longer includes these" [telinit cmd/man] to you responding with "Shouldn't it [arch] still? (And wouldn't it be deviating from upstream if it didn't [provide telinit]?)" > But near as I can tell, what you wrote isn't entirely accurate. It's > not that upstream no longer includes them; it's that it no longer > includes them *by default*. So rather than the package always building > the telinit and runlevel binaries, it looks like it now *optionally* > builds them depending on whether the HAVE_SYSV_COMPAT flag is set (to > indicate whether you want to include sysv compatibility or not). > > But since the package in question is called "systemd-sysvcompat" and is > intended to provide "sysvinit compat for systemd", it's puzzling to me > why Arch would choose to explicitly *not* set that flag when building > that package. The telinit and runlevel commands were part of the Linux > sysv init system for ages, so I'm not clear what would be the point of > suddenly removing them from a package whose whole intent is to provide > sysvinit compatibility. I mean, if someone doesn't need or want > sysvinit compatibility, then they just wouldn't install that package > altogether. And if they did install it, then presumably they'd expect > those two utilities (whose build is explicitly triggered by a flag > indicating whether systemv compatibility is desired) to be included. The preprocessor macro HAVE_SYSV_COMPAT does a *lot* more than provide some symlinks. The sysvcompat symlinks still installed are: - halt - reboot - poweroff - shutdown - init These programs are generically useful on fully systemd systems, and systemd documents them as such: "These commands are implemented in a way that preserves basic compatibility with the original SysV commands. systemctl(1) verbs halt, poweroff, reboot provide the same functionality with some additional features." When it comes to telinit, the description is, rather: "This is a legacy command available for compatibility only. It should not be used anymore, as the concept of runlevels is obsolete." It seems clear to me why it's no longer installed except when systemd is configured with the necessary code to interpret and convert old /etc/init.d and /etc/rc.d infrastructure into stubbed systemd units. As for whether systemd should provide a split sysvcompat package that provides symlinks for generally useful programs styled after sysvinit, or, alternatively, provide the full-blown HAVE_SYSV_COMPAT initscript parser etc? Personally, I don't believe the split is useful anymore, as I believe it was originally meant for the sysvinit -> systemd migration period to allow having both installed at the same time and easily switching between the two. I'd rather remove it entirely, and fold it into "systemd". It's required by "base" anyway, lol. I don't believe the intention is to provide runtime generation of systemd units, and I think the pkgdesc is misleadingly simple in that regard. ... Anyway, if you want to have dialogue about whether it's useful to have a telinit program, regardless of upstream's defaults, by all means, feel free to have that discussion. But can it please not include rationalizations like "why are we deviating from upstream by not including it"? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Telinit?
On 8/16/20 3:24 PM, David Rosenstrauch wrote: > On 2020-08-16 3:20 pm, Eli Schwartz via arch-general wrote: >> Reread the Arch commit. It wasn't removed. >> >> Arch used to move the symlink from the "systemd" package to the >> "systemd-sysvcompat" package, and no longer does so. > > Not sure I understand. Shouldn't it still? (And wouldn't it be > deviating from upstream if it didn't?) Once again, reread the Arch commit. The telinit binary is no longer deleted from the "systemd" package. The telinit binary is ALSO no longer added to the "systemd-sysvcompat" package. There are only two possible conclusions: - the telinit binary is currently provided by Arch's "systemd" package and is thus available on your computer *right now*. - upstream removed it, not Arch How to determine which one is correct? Well, if you didn't snip out and completely ignore half my email, you might have seen this: > Whether the move is done via mv && mv, or via rm && install, is immaterial. > > The point of the rm && install is to emulate upstream's install layout, > but have parts of it in one package and parts in another package. Most importantly, though, was this: > As Andreas Bosch pointed out, the upstream install layout no longer > includes these, and thus, arch doesn't move them into another package. However, if you didn't read my email then, I'm not sure why you'd bother reading my second email now. So perhaps I'm just wasting my time. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Telinit?
On 8/16/20 2:59 PM, David Rosenstrauch wrote: > On 2020-08-15 2:53 pm, David Rosenstrauch wrote: >> Anyone know what happened to the "telinit" shortcut? It used to be >> included in systemd-sysvcompat >> (https://wiki.archlinux.org/index.php/Systemd#systemd-sysvcompat) but >> seems like it recently got removed. Was it removed upstream? (And if >> so, anyone know why?) > > I looked into this a bit more, and it looks like this was not an > upstream change. Rather, it was removed in Arch in this commit: > https://github.com/archlinux/svntogit-packages/commit/9ca7c019fe8f59505cf1f6dc4163e146f3e777a7#diff-8d0411b338c83cd8cd8ad9d9db127101 > > > @eworm: Any explanation as to why this was removed? Reread the Arch commit. It wasn't removed. Arch used to move the symlink from the "systemd" package to the "systemd-sysvcompat" package, and no longer does so. Whether the move is done via mv && mv, or via rm && install, is immaterial. The point of the rm && install is to emulate upstream's install layout, but have parts of it in one package and parts in another package. As Andreas Bosch pointed out, the upstream install layout no longer includes these, and thus, arch doesn't move them into another package. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/10/20 11:25 PM, David C. Rankin wrote: > On 8/10/20 10:10 PM, Eli Schwartz via arch-general wrote: >> After that many errors, why did you try rebooting without fixing things >> first? The obvious first step is to try rerunning all of those hooks >> using a modern pacman. >> >> (Do not do a year's worth of updates in one go like that, it's not >> tested and might break. It is preferred instead to do incremental >> updates via https://wiki.archlinux.org/index.php/Arch_Linux_Archive in >> e.g. monthly increments, but if you insist on doing the whole thing in >> one shot then at least use the latest version of pacman via my >> pacman-static binaries, or the install media + pacman --sysroot /mnt -Syu) > > Thank you Eli, > > Well, to be honest, I knew pacman had been updated and I thought rebooting > would fix it :) -- Oh well, maybe not > > pacman is fully updated now, right? So if I take that list and go back and > try re-running the hooks -- that may be one way to fix it? Worse come to > worse, I'll just wipe /root and reinstall... Depends on the hook. Some of them use NeedsTargets, so the Exec command needs to receive the list of triggering files on stdin. Reinstalling all currently installed packages would have the same effect, no need to wipe anything. If you have the list of packages which were updated at that time, you could just update them alone. Otherwise it might take a bit of fiddling to ensure every hook runs correctly. > So for my edification -- what happened was after update, the new pacman was > installed along with the new hooks, but since the pacman I ran the update from > was too old, it croaked trying to run the new hooks from the updated pacman? > > Will we give it a go. Correct. Again, using https://aur.archlinux.org/packages/pacman-static#pinned-666894 renders this concern irrelevant since you'd end up running the most recent pacman in order to perform the update and run hooks. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
> The journal shows /boot and /home mounted fine and systemd started and > targets Multi-User and Graphical reached and sddm start and Startup finishes: > > Aug 10 17:11:28 seidr systemd[1]: Reached target Multi-User System. > Aug 10 17:11:28 seidr dbus-daemon[481]: [system] Activating via systemd: > service > ... > Aug 10 17:11:28 seidr systemd[1]: Reached target Graphical Interface. > ... > Aug 10 17:11:29 seidr sddm[486]: Initializing... > Aug 10 17:11:29 seidr sddm[486]: Starting... > Aug 10 17:11:29 seidr sddm[486]: Logind interface found > ... > Aug 10 17:11:29 seidr systemd[1]: Startup finished in 6.449s (kernel) + > 13.784s (userspace) = 20.233s. > > There seem to be problems with kde .desktop files, but the system tries to > proceed: > > Aug 10 17:13:20 seidr systemd[500]: /etc/xdg/autostart/org.kde.kgpg.desktop:8: > Unknown key name 'MimeType' in section 'Desktop Entry', ignoring. > Aug 10 17:13:20 seidr systemd[500]: > /etc/xdg/autostart/kmix_autostart.desktop:6: Unknown key name 'MimeType' in > section 'Desktop Entry', ignoring. > Aug 10 17:13:20 seidr systemd[500]: Configuration file > /etc/xdg/autostart/klipper.desktop is marked executable. Please remove > executable permission bits. Proceeding anyway. > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart > app-at\x2dspi\x2ddbus\x2dbus-autostart.service, startup phases are not > supported. > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart > app-kaccess-autostart.service, only Type=Application is supported. > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart > app-pulseaudio-autostart.service, startup phases are not supported. > Aug 10 17:13:20 seidr systemd[500]: Not generating service for XDG autostart > app-powerdevil-autostart.service, only Type=Application is supported. > Aug 10 17:13:20 seidr systemd[500]: kde-systemd-start-condition not found: No > such file or directory > Aug 10 17:13:20 seidr systemd[495]: Queued start job for default target Main > User Target. > Aug 10 17:13:20 seidr systemd[495]: Reached target Paths. > Aug 10 17:13:20 seidr systemd[495]: Reached target Timers. > > But tty1 is still hung -- no display manager is loaded and I'm stuck on > tty2. I'm not sure what is stuck or what to kill to try and fix it. Before the > update sddm was fine and I loaded fluxbox to do the update rather than doing > it from within KDE. What do I check to try and bring the system back to a > working state? What to check? > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Pros/Cons of Python zipapp packaging
On 8/10/20 4:49 PM, Daan De Meyer via arch-general wrote: > Hi, > > We've been discussing the distribution mechanism for mkosi ( > https://github.com/systemd/mkosi) and one of the ideas is using Python > zipapp (https://docs.python.org/3/library/zipapp.html) to allow us to split > mkosi up into multiple files for easier development without complicating > the packaging process. zipapp takes all source files in a directory and > bundles them up into a single executable python zip archive so after > building the zip you can simply call ./mkosi to run mkosi and can put it > anywhere in the PATH to simply run mkosi wherever you want. Are there any > issues with this approach from a distro packaging perspective? Zipapp > doesn't bundle a specific python version (uses system python and system > python stdlib) and we don't intend on bundling any dependencies in the > zipapp. I don't think I've ever seen a python application packaged this way > which is why I'm asking. This is more or less the same as adding a zip file to the PYTHONPATH, and importing from it -- it works, from a python perspective, no different from unzipping the files into site-packages. The difference is it is only available when you run the file (plus special considerations for __main__). As you say, this isn't trying to bundle dependencies. It's not really functionally different from just having all code in one script file. On the other hand, this introduces size overhead for packaging due to multiple layers of compression (and zip is not very good at this anyway), probably doesn't play nice with bytecode generation, and reduces the effectiveness of a nice side effect of scripted languages, which is that users can trivially read the script, edit it, etc. Minor niggles, really. I wouldn't consider it a real blocker, personally. That being said, I'd guess the only specific advantage this has over installing as a PEP 376-style Installed Python Distribution is the fact that a single file can reliably locate itself when invoked with sudo, rather than losing track of a 'pip install --user' installed version with a builtin user-specific sys.path that isn't preserved by sudo. Do they necessarily need to be incompatible? You could have a pip-installable mkosi/ which can be used with 'python3 -m mkosi' due to possessing a __main__.py, but which can *also* be zipapp'ed for portability. It might behave very weirdly in the pip install --user case, but on the other hand Arch users will always use the bleeding-edge package, while Debian customizes their distro python package with an elaborate hack to make "sudo pip install" be officially supported and not touch dpkg-managed files. I'm not positive what guidance to give you beyond "I don't think this violates the packaging guidelines in the slightest, so have no fear on that count". -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Question about packaging a library (AUR)
On 7/21/20 12:16 PM, Aneesh Raghavan via arch-general wrote: > On Tue, Jul 21, 2020 at 8:25 AM Dominik Schrempf via arch-general > wrote: >> I tried to provide the videosection library in /usr/lib, but that doesn't >> work. >> I don't feel comfortable providing the library in /usr/bin. Do you know an >> appropriate way to deal with such cases? Is it preferable to install the >> executable in a separate folder alongside the library? For example, >> /opt/transcribe? > > Hello, > Although I don't know much about this package and it's libraries, I > believe an ideal way to put the libraries together is to have > transcribe in a seperate folder with all of the libraries, while there > are symlinks in /usr/bin and /usr/lib to the libraries.I hope this > helps That might *work*, but I would not describe it as *ideal*. Dominik, If this library is indeed a plugin specific to the "transcribe" program, it's traditional for programs to have a special plugins directory e.g. /usr/lib/transcribe/ and attempt to load *.so plugins from there. If it's generally usable by other programs, then it would be appropriate to have it in the general-purpose /usr/lib directory. If it's generally usable by gstreamer, then it would be appropriate to put it in the directory /usr/lib/gstreamer-1.0, as specified by: $ pkg-config gstreamer-1.0 --variable=pluginsdir It's not an option to provide the library in /usr/bin, but a usable workaround would be to symlink the binary in /usr/bin but install it in /opt/transcribe/. Check to see if it correctly picks up the right location, though. ;) You might need to create a wrapper script instead, which invokes it without a symlink. You may wish to clarify with upstream if it can use the more customary location. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why bind-tools was merged into bind package?
On 7/20/20 4:51 PM, Sam Mulvey wrote: > > On 7/20/20 1:34 AM, brent s. wrote: >> Because the binaries formerly known as "bind-tools" are a part of BIND9 >> proper[0]. Upstream, by including "bind-tools" binaries in the source >> for the BIND9 daemon, ipso facto*intends* them to be built (and thusly >> packaged) together. To do so otherwise is - one can make the argument - >> *not* The Arch Way[1]. > > I don't think that's a strong argument for software that is seen (among > other things) as a reference implementation, which ISC software often > is. If that's the main reason for wrapping the two packages together I > would rethink it. This seems like shifting complexity rather than > adding to simplicity, so bringing up The Arch Way isn't entirely > appropriate. > > That said, I don't really have a problem with bind-tools being wrapped > into bind. Heck, I'm for getting rid of the *-headers packages for > kernels, but I doubt that'll be implemented anytime soon. The Arch Way discusses the topic of package splitting: > Packages are only split when compelling advantages exist, such as to > save disk space in particularly bad cases of waste. This is an extremely accurate description of the kernel *-headers, weighing in at 119.67 MiB compared to the actual kernel's more modest 75.81 MiB. The general rule is if there is one source archive that builds two things in one "./configure && make && make install", it per default makes sense to ship them together. Saving the vast majority of users 100+ MiB of things they don't need is sufficient grounds to split them out. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why bind-tools was merged into bind package?
On 7/20/20 3:15 AM, Óscar García Amor wrote: > The problem is. Where is the limit? The whole distribution in one > package? The argument is the same, if you don't need it simply don't > use it. Don't be facetious. > In this case we are talking about binaries widely used that will be > installed with a service rarely used. I think that packages that have > enough entity to be splitted should do it. There is already a distribution which caters to this thing that you think. Its name is Debian. You are free to use it, if you like, however, you are wasting your time trying to convince anyone on this list to tear down one of the core values of the Arch Way. Please read or reread https://wiki.archlinux.org/index.php/Arch_Linux#Principles > From my point of view is > safer don't have a service installed than installed an disabled. You have a right to that opinion. However, if you intend to convince anyone *else* that this is indeed the case, you will need to do more than merely state your point of view. Specifically, you will need to prove it. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why bind-tools was merged into bind package?
On 7/19/20 3:15 PM, Óscar García Amor via arch-general wrote: > I can understand that packagers want to make things easy, but not in > this case. I cannot have a full service installed with a new user > created, only host, dig and nslookup commands. The splitted package > bind and bind-tools had this option, but now I must install a service > that I do not need which is annoying. > > There is any way to reconsider this? Why do you care if a service is installed, if you aren't using that service? Don't enable the service. You have lots of disabled services installed already. Why is it a problem if a system user is created that you don't need? You have lots of system users you don't use, already. If it bothers you that much, create a sysusers.d dropin override to prevent that user's creation. I see no rationale to re-split the package. The arguments you're using aren't arguments which arch typically values. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Package signature error after updated GPG key
On 7/8/20 3:08 PM, NicoHood wrote: > Hey guys, > i have recently received the attached email from a user. He cannot > install a package from me due to a GPG error. I have recently updated my > key and it should have been added to the new keyring. I don't know a > better solution, who can help us? > > Cheers, > Nico There is nothing wrong with this key and it successfully verifies using pacman with the current archlinux-keyring package. debug: sig data: iQIzBAABCAAdFiEElzEtXrnXrn0L1DBzUdrpt8GukWEFAlyfmyUACgkQUdrpt8GukWH4EA//SIhP7Cr8pnDxd8e3jPoGmP6zU/YvXcqvRfwPWB+p6zRxq8+GGdrLzDGfRQHu2NWNK9ZTAagmArEWh/vQhxMCE2bfTcmQo5dA25mMqiaZcF1K9e/PKKvKbZ5PaIuxmX65fd3C74CFDHo5OLWOhx8PrXGINYnS6TCD5KxOQ5L10tSQPcRmNjid8KbcuflvrFkcEu/GpNL1HaFdr+VuvGKpmWj36Lbj4Q6uKOisnf9jmMraVD+C67+WStWgxkkPyILb4XvTcEBLctdzKEDY04C/oSafQMrK4CVd+JsVX5udpledIZL03Md+YhcHsW51aDtkry2M9i75WCrE9C7QHnfoxnBCzGi4xnjW/spGZVCQjNZ6M/6OMzlFwCdggi2y9yewrk5apA2o2Fw65UMGgKowIFQEHhoEV/RnumyR5TWi2Oz9ljXCmPRbe6x2SvjneQ4C5jqL2bVzmtLrdLQBrGeUIJLlYVQjLyRZH+WjgWrp3QOe7qX7DwxukRrIoLHt22ucSC9Nvc2QtVvQ7B9gXne87k4b4u4PYc1wQhKm7JwArT4EnVWKm6MdSfbvRuR7Sw6JeVZgRFyVAHihwOEVLPDTOmof9EHZDh4VKF1YTr7P/QS2zSemaQs2vOyjuFRkLVQ8RuyF+SUAk2xx9eIuW4w1+pH/lP38+KBXj7laV+nump0= debug: checking signature for /var/cache/pacman/pkg/snap-pac-2.3.1-1-aany.pkg.tar.xz debug: 1 signatures returned debug: fingerprint: 97312D5EB9D7AE7D0BD4307351DAE9B7C1AE9161 debug: summary: valid debug: summary: green debug: status: Success debug: timestamp: 1553963813 debug: exp_timestamp: 0 debug: validity: full; reason: Success debug: key: 97312D5EB9D7AE7D0BD4307351DAE9B7C1AE9161, NicoHood , owner_trust unknown, disabled 0 debug: signature is valid debug: signature is fully trusted -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Locale packages
On 6/23/20 3:02 PM, Daan De Meyer via arch-general wrote: >> This is not about locale-gen. locale-gen (and /etc/locale.gen) are >> Arch-specific custom scripts which IIRC were copied from Debian once >> upon a time, which just run localedef. I actually use a much simpler >> locale-gen program which uses flag files e.g. /etc/locales/en_US (file >> contents can contain a charset but are otherwise assumed to be UTF-8). >> It's not hard to hack your own. > > Running localedef directly doesn't really solve any of the issues I > mentioned either though. It would: - avoid the *additional* issue "what to do if locale-gen doesn't exist", - solve the issue "locale-gen does not have a --root option" It wouldn't: - solve the issue "host/guest glibc version mismatches" > What if we make do with a single locale package? I just found out there's > some progress on the C.UTF-8 locale upstream support in glibc ( > https://sourceware.org/pipermail/libc-alpha/2020-June/115224.html). It > doesn't look like it will be built-in though unless they manage to get the > size down significantly. If it isn't built-in, maybe we could add a single > package just for the C.UTF-8 locale? That should be sufficient for 95% of > the "I'm building an Arch container/vm image for development/server/any > other development stuff" use cases which generally will be using an english > locale and avoids all the problems I mentioned earlier without requiring > the addition of 300+ packages. It'll have to wait until we have C.UTF-8 in > glibc though. I guess we could add a package for en_US.UTF-8 as a stopgap > but that doesn't seem worth the effort assuming C.UTF-8 gets merged in a > reasonable timeframe. The ultimate goal is to ensure C.UTF-8 always exists no matter what. If it gets merged upstream in glibc as a non-builtin localedef generated locale, then the probable best solution is to make locale-gen always include C.UTF-8 regardless of which other locales are requested by the user's system. Or include its compiled form in the glibc package directly, if it isn't too bloated. > As an example of why one would need a UTF-8 locale specifically in a > container/vm image, meson (actually python) does not like running under a > non UTF-8 locale at all. You're preaching to the choir, here. ;) I thoroughly agree there must be a UTF-8 locale. The question is at what stage should this be selected and generated. > (I don't use mailing lists very often, I hope I didn't mess up the reply > etiquette) Generally people tend to delete the sections they are not replying to, but reply inline, rather than including everytyhing the bottom as a second copy of the sections you quoted and replied to inline. Still, replying inline is the main thing, and you did that. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Locale packages
On 6/22/20 3:11 PM, Daan De Meyer via arch-general wrote: > Hi, > > While working on locale-gen support for systemd-firstboot ( > https://github.com/systemd/systemd/pull/15994), I started wondering if it > wouldn't be simpler to delegate the installation of locales to pacman > instead. I haven't been following the mailing lists for very long so I > don't know if this has ever been discussed. I'd imagine Arch could provide > a package for each locale supported by glibc and users would install the > ones they need. Very firm -1 to any approach that involves creating hundreds of new packages which each provide a tiny file. > The PKGBUILD would use localedef to generate separate folders of compiled > locale files for each locale that would be stored in /usr/lib/locale. This > approach is already implemented by distros such as Fedora (and co) and > Ubuntu. > > The main advantage of this approach is that there's no need to set up an > entire chroot to run locale-gen when pacstrapping a new Arch system image. > This might seem easy but becomes trickier when the image uses a different > architecture than the host system since emulation of that architecture has > to be set up first. Even if locale-gen had a --root option so using the > host's locale-gen would be an option, I'm not sure if there's any guarantee > that compiled locale definitions generated by the host system's locale-gen > would work with the glibc version used by the image (less of a problem with > Arch but the glibc on the host could still potentially be out-of-date > compared to the one installed in the image). Being able to install locales > with pacman would solve all these problems. > > Any interest in something like this from the Arch developers? I'd be > willing to try my hand at a PKGBUILD for this but I'm not a TU so I'd need > some support to get this implemented (if there is any interest at all). > > (This also doesn't imply that locale-gen wouldn't work anymore, locale-gen > stores everything in /usr/lib/locale/locale-archive which would be > independent from the files installed by the locale packages, so both > approaches should work side-by-side) This is not about locale-gen. locale-gen (and /etc/locale.gen) are Arch-specific custom scripts which IIRC were copied from Debian once upon a time, which just run localedef. I actually use a much simpler locale-gen program which uses flag files e.g. /etc/locales/en_US (file contents can contain a charset but are otherwise assumed to be UTF-8). It's not hard to hack your own. IIRC Fedora follows the "hundreds of packages which each provide a small file" approach, that being the localedef --no-archive intersection of a locale and a charmap. The combination of all possibilities will result in significant size bloat, so it is not feasible to provide them all in the glibc package itself. (e.g. try uncommenting all 487 locales in /etc/locale.gen and it is a 500MB locale-archive, "only" 100MB if you stick to UTF-8 locales) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 6/18/20 7:15 PM, Chris Billington via arch-general wrote: > I haven't seen this mentioned yet which makes me wonder if I've > misunderstood, but isn't it already the case that bash runs in a > posix-compatible mode if executed as /bin/sh? > > I remember a bug a while back [1] that broke graphical login because > flatpak used a bashism in an X startup script. Does this not imply that any > bashisms executed with /bin/sh would already be causing breakage today on > Arch Linux? > > [1] https://bugs.archlinux.org/task/61420#comment176360 Yep -- as I said earlier in the thread: > Meanwhile, scripts which use bashisms but a /bin/sh shebang are broken > even if /bin/sh is a symlink to bash. Bash disables some, but not all, > features of bash if it is invoked in POSIX mode, such as via a symlink > named /bin/sh -- so, you do not even get the benefits of bash, and never > have, if you used /bin/sh as your shebang. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 6/18/20 6:06 PM, Bardur Arantsson wrote: > On 18/06/2020 18.22, Eli Schwartz via arch-general wrote: >>> And nearly everybody who has to write this quickly will do it wrong. >> >> And yet, some do not. Some write elegant, simple POSIX sh scripts which >> do it right. For example, people often forget that pipelines and >> functions are an option, and sometimes a much faster and better option >> than global state variables. >> >> And most people who are writing /bin/bash scripts are *also* doing it >> wrong because they don't really know what they are doing. Just saying. :p >> > > This is an argument from the Perfect/Robot programmer and is utterly false. > > We should just collectively face the truth that shell is not a good way > to program anything non-trivial. :D I... don't see what you're arguing against? Someone made an argument that security would be aided by using a larger shell which has more features that can avoid some of the gross hacks people sometimes do in POSIX sh. I argued in response that most people suck at writing bash *anyway*, and it's possible for people who know what they're doing to write perfectly safe POSIX sh. It's immaterial to the discussion either way, but I just figured I would point out that anyone who I'd actually trust to write shell scripts, I'd usually trust to write POSIX shell scripts too. So there's no need to make some arbitrary divide where bash is "safer" than POSIX sh and the latter should never be used. Your response is... I'm wrong because only the Perfect/Robot programmer can write good shell of any kind, and people shouldn't program in shell? Where did I say people should program in shell? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 6/18/20 6:00 PM, Bardur Arantsson wrote: > On 18/06/2020 06.33, Eli Schwartz via arch-general wrote: >> You pulled this assertion out of thin air, do you have any proof that it >> "breaks more than a decade of setups"? > > OP is the one making an assertion, so the burden of proof is on them. > > That said... I suspect most the system-wide breakage that would have > been expected would be due to init scripts and systemd ameliorates that > to a large degree. The OP is sharing an assertion made by many people, that /bin/sh as dash is safe. As I've mentioned previously in the thread, there is a lot of prior art. Anything that is expected to work on multiple distros, generally should work. SysV init scripts might not work, if they were Arch-specific. Yes. That is of course no longer a concern, and the primary concern is instead system scripts, applications, frameworks, etc. which run after boot, not as part of boot. >> Note that as has already been pointed out, any setup which it breaks is >> inherently flawed, and in addition was broken on Debian, the most >> popular linux distribution by sheer numbers, as well as most non-Linux >> forms of Unix. >> > > Inherent flaws in a setup doesn't mean that shit doesn't break. Ideally, > yes, there would be no flaws, but this is the real world. > > Doubtless, we all try to strive towards perfection, but there is no such > thing in practice. That is completely beside the point. If it doesn't work on Debian, chances are someone is going to notice and fix it. :p The world is no longer a place where everyone assumes /bin/sh works like bash. Following in the footsteps of Debian in this regard is not some super dangerous endeavor. >> It's actually in practice very unlikely that this will break anyone's setup. >> >> Also if you really think Arch Linux is afraid to break people's setups, >> I suggest you reread https://www.archlinux.org/news/python-is-now-python-3/ >> > > In practice, I agree that it probably won't break much, but your > arguments largely don't hold water. I've provided rationale why I don't believe it will break much, you *agree* with me, and yet you say my arguments don't hold water? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as default shell?
On 6/18/20 12:08 PM, li...@2ion.de wrote: > On Wed, Jun 17, 2020 at 11:17:08PM +0100, Piscium via arch-general wrote: >> But switching to dash would also be about security, as less code means >> less bugs [5]. > > Usage of a more concise, powerful and clean shell language is much more > suitable as a point when bringing forth an argument of there being less > bugs. > > I'd say that the amount of bugs in the underlying implementation of a > shell almost does matter nothing when compared to the horrors of > hacked-together shell scripts that try to be as "basic" as possible, > trying to be as "compatible" as possible with anything, exchanging > cleanliness and expressiveness for horrible Debian init script-style > code. > > Saving a pseudo-array into a string just to manually reconstruct the > pseudo-list when the occasion arises to access a specific element is > just one example of what awaits people who ignore the benefits of Bash > arrays when they could have had them just by using a different shebang. Why does this have anything to do with switching /bin/sh? Scripts which do not "ignore the benefits of bash arrays when they could have had them just by using a different shebang", would not be affected by such a change as they do not, in fact, use a different shebang. Meanwhile, scripts which use bashisms but a /bin/sh shebang are broken even if /bin/sh is a symlink to bash. Bash disables some, but not all, features of bash if it is invoked in POSIX mode, such as via a symlink named /bin/sh -- so, you do not even get the benefits of bash, and never have, if you used /bin/sh as your shebang. > And nearly everybody who has to write this quickly will do it wrong. And yet, some do not. Some write elegant, simple POSIX sh scripts which do it right. For example, people often forget that pipelines and functions are an option, and sometimes a much faster and better option than global state variables. And most people who are writing /bin/bash scripts are *also* doing it wrong because they don't really know what they are doing. Just saying. :p -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman --assume-installed in a config file?
On 6/18/20 9:56 AM, Damjan Georgievski via arch-general wrote: >>> noto-fonts is pulled as a dependency of plasma-integration, but I >>> don't want it installed since it takes over the default fonts (ships >>> an aggressive fontconfig configuration) for many websites, and looks >>> quite bad *for me* (on a 14" FHD display). >>> It's also a 90MB package I don't need. >> >> Hmm, I wonder why it is a hard dependency instead of being used via >> ttf-font? > > I guess it's because plasma-integration ships a > /usr/share/kconf_update/fonts_global.pl script that does some font > replacements. > > https://github.com/KDE/plasma-integration/blob/master/src/platformtheme/fonts_global.pl That seems a bit confusing :/ since it appears to only be used when migrating away from a previously configured Oxygen selection. Does anything else actually hardcode this? This dependency IMO should have been a post_upgrade message or a noto-fonts replaces=() or something. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman --assume-installed in a config file?
On 6/18/20 9:30 AM, Damjan Georgievski via arch-general wrote: > I often find myself using the `assume-installed`[1] option of pacman > when doing upgrades, since I want to avoid some (for me) nonsensical > dependencies to be installed. > > Is it possible to configure this in some config file, so I don't have > to remember to type it all the time? You could create a dummy package for it, I guess. > noto-fonts is pulled as a dependency of plasma-integration, but I > don't want it installed since it takes over the default fonts (ships > an aggressive fontconfig configuration) for many websites, and looks > quite bad *for me* (on a 14" FHD display). > It's also a 90MB package I don't need. Hmm, I wonder why it is a hard dependency instead of being used via ttf-font? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] What do you do with pacman.log? Periodically archive? Delete?
On 6/18/20 2:09 AM, David C. Rankin wrote: > This is more of what is the recommended practice ... for handling pacman.log? > > Strange question, yes, but pacman.log is one of those that never gets > rotated, etc.. The information in it isn't useful after a few upgrade cycles. > So what is the general practice for dealing with it? > > o Periodically delete it? > o Split it by year with awk and compress it for?? Historical reasons? > o Keep the last year? > > It not one of those things I've ever thought about before, but grepping > (after cleaning up the wide-character right-arrow from 2017/18 timeframe), I > checked and I have 5M of log dating back to 2013. It's not hurting anything, > but that got me thinking? What do others do with it, and is there any > recommended manner for dealing with it? > > I don't see any reason for keeping much of it beyond what you may be asked > to post as part of a bug-report, etc.. which usually wouldn't be more than the > last couple of months for most packages.. > > man 8 pacman doesn't provide any options for dealing with how much to keep > or to truncate. Among other things, it serves as a handy way to tell when you first installed the system. :) I have so many better places to save 5mb of disk space, this doesn't even register in the top 400. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as default shell?
On 6/18/20 12:11 AM, David C. Rankin wrote: > On 06/17/2020 01:18 PM, Piscium via arch-general wrote: >> Today I set dash as my default shell [1] on two PCs. We will see if I >> get into trouble. >> >> This question was asked years ago but maybe good to ask again. Could >> dash be made the default shell in Arch? > > Please NO. Bash has been the default, and while there is nothing wrong with a > Bourne-again (or Debian Almquist) type shell, it would break more than a > decade of setups... > > If you want Dash, make the change after install. You pulled this assertion out of thin air, do you have any proof that it "breaks more than a decade of setups"? Note that as has already been pointed out, any setup which it breaks is inherently flawed, and in addition was broken on Debian, the most popular linux distribution by sheer numbers, as well as most non-Linux forms of Unix. It's actually in practice very unlikely that this will break anyone's setup. Also if you really think Arch Linux is afraid to break people's setups, I suggest you reread https://www.archlinux.org/news/python-is-now-python-3/ -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 6/17/20 3:54 PM, Kusoneko wrote: > It has the cost that everyone who uses scripts that use bashisms will > inevitably have issues, furthermore, considering Arch only supports > x86_64, I've yet to see systems under that architecture have low > amounts of memory and 6MB of disk storage is incredibly small. The > real question here is "Is it worth forcing people to remove bashisms > or specify that the script is meant for bash in their scripts > (whichever ones don't do so already) for a speed improvement on a > shell scripts that work with dash?" Note that some upstreams will > likely not care, and maintainers will have to patch the scripts > manually in that case. Debian/Ubuntu has extensive prior art in this matter. It was very important and resulted in very noticeable speed improvements on x86_64 systems with lots of memory and disk storage, because pid 1 used to be shellscripts and doing it in bash is slow and gets even slower the more you fork new scripts. :) Also Linux isn't everything :) and there are plenty of systems where bash is not installed by default. e.g. the *BSDs. Also also, bash is not installed on systems such as alpine linux. So any script assuming /bin/sh is bash, is broken on lots of systems. ... This is not actually a problem, I've used dash as my /bin/sh for years and haven't once encountered a broken script. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 6/17/20 3:18 PM, Kusoneko wrote: > On June 17, 2020 7:06:01 PM UTC, "Jack L. Frost" > wrote: >> On Wed, Jun 17, 2020 at 07:18:33PM +0100, Piscium via arch-general >> wrote: >>> What do you think? >> >> I'm not sure how much utility is in doing this > > Pretty much this, to be honest. I don't really see the point of > changing everyone's /bin/sh for one person's personal preference when > there isn't really any point in doing so to begin with. Completely free, no cost speed improvements have no utility? Reread the original post. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 6/17/20 3:05 PM, NTS wrote: > On 17 Jun 2020 8:36 p.m., "David Rosenstrauch" wrote: > > > > On 6/17/20 2:18 PM, Piscium via arch-general wrote: > >> Today I set dash as my default shell [1] on two PCs. We will see if I >> get into trouble. >> >> This question was asked years ago but maybe good to ask again. Could >> dash be made the default shell in Arch? >> > > > Couldn't you just set it as the default for your user using chsh? > > > Yes, that would probably more safe. Also, you could have a user "doot" or > whatever name with user ID 0 and shell /bin/dash to log in as a sys admin > with dash. > > Alternatively when you "su" interactively you could instead do "sudo dash". > > Used to do the same (new user with ID 0 I mean) under Solaris and it worked > flawlessly. It would be extremely safe because it wouldn't do anything, not even what the original poster wanted. It's completely unrelated to anything whatsoever. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] dash as system /bin/sh? (Was: dash as default shell?)
On 6/17/20 2:36 PM, David Rosenstrauch wrote: > > > On 6/17/20 2:18 PM, Piscium via arch-general wrote: >> Today I set dash as my default shell [1] on two PCs. We will see if I >> get into trouble. >> >> This question was asked years ago but maybe good to ask again. Could >> dash be made the default shell in Arch? > > > Couldn't you just set it as the default for your user using chsh? This isn't about using it as a login shell. Describing this as "my default shell" is a very bad description. This is actually about setting dash as the system /bin/sh implementation. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Wesnoth probably has wrong dependency
On 6/3/20 5:47 AM, Peter Nabbefeld wrote: > > Hello, > > as Python2 has been sunset since the beginning of this year > (https://www.python.org/doc/sunset-python-2/) I'm looking forward to > removing it. One of the packages still depending on python2 is wesnoth, > though due to https://wiki.wesnoth.org/Maintenance_tools it should work > with Python3 already. Of course, this should work, since Python3 is > installed already besides Python2, but it seems to be an unnecessary > dependency. Instead, the dependency should be updated to python. https://github.com/wesnoth/wesnoth/issues/1508 Try grepping the package for python2 or python3 shebangs: [eschwartz@dragon ~/wesnoth-extracted]$ ag --files-with-match python2 usr/share/wesnoth/data/tools/expand-terrain-macros.py usr/share/wesnoth/data/tools/journeylifter usr/share/wesnoth/data/tools/rmtrans/rmtrans.py usr/share/wesnoth/data/tools/scoutDefault.py usr/share/wesnoth/data/tools/trackplacer usr/share/wesnoth/data/tools/wesnoth/wmlgrammar.py usr/share/wesnoth/data/tools/wesnoth/wmldata.py usr/share/wesnoth/data/tools/wesnoth/wmliterator.py usr/share/wesnoth/data/tools/wesnoth/wmlparser2.py usr/share/wesnoth/data/tools/wesnoth/wmlparser.py usr/share/wesnoth/data/tools/wesnoth/wmltools.py usr/share/wesnoth/data/tools/wmlvalidator usr/share/wesnoth/data/tools/wmlflip [eschwartz@dragon ~/wesnoth-extracted]$ ag --files-with-match python3 usr/share/wesnoth/data/tools/addon_manager/__init__.py usr/share/wesnoth/data/tools/GUI.pyw usr/share/wesnoth/data/tools/about_cfg_to_wiki usr/share/wesnoth/data/tools/addon_manager/html.py usr/share/wesnoth/data/tools/campaign2wiki.py usr/share/wesnoth/data/tools/extractbindings usr/share/wesnoth/data/tools/hexometer.py usr/share/wesnoth/data/tools/imgcheck usr/share/wesnoth/data/tools/terrain2wiki.py usr/share/wesnoth/data/tools/unit_tree/__init__.py usr/share/wesnoth/data/tools/unit_tree/TeamColorizer usr/share/wesnoth/data/tools/steam-changelog usr/share/wesnoth/data/tools/unit_tree/update-wmlunits usr/share/wesnoth/data/tools/unit_tree/wiki_output.py usr/share/wesnoth/data/tools/unit_tree/animations.py usr/share/wesnoth/data/tools/unit_tree/helpers.py usr/share/wesnoth/data/tools/wesnoth/campaignserver_client.py usr/share/wesnoth/data/tools/wesnoth/libgithub.py usr/share/wesnoth/data/tools/wesnoth/wmliterator3.py usr/share/wesnoth/data/tools/unit_tree/overview.py usr/share/wesnoth/data/tools/unit_tree/html_output.py usr/share/wesnoth/data/tools/wesnoth_addon_manager usr/share/wesnoth/data/tools/wesnoth/wescamp.py usr/share/wesnoth/data/tools/wmlindent usr/share/wesnoth/data/tools/wesnoth/wmlparser3.py usr/share/wesnoth/data/tools/wesnoth/wmltools3.py usr/share/wesnoth/data/tools/wmlunits usr/share/wesnoth/data/tools/wmllint-1.4 usr/share/wesnoth/data/tools/wmlscope usr/share/wesnoth/data/tools/wmlxgettext usr/share/wesnoth/data/tools/wmllint -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] oops, 'sudo: pacman: command not found'
On 6/7/20 9:09 PM, Greg Minshall wrote: > hi. a month ago i ran out of room on my root file system, so relocated > /var/cache/pacman to /home, and left behind a symlink. > > today, after a while, i did a 'pacman -Syu', which downloaded lots, and > ran through a lot new keys, upgrading, etc., then failed (see below), > and (the symbolic link at) /var/cache/pacman seems to have disappeared. > > any suggestions on how i might recover? (and, should i, possibly, > rather than using a symlink, have modified, e.g., /etc/pacman.conf?) Your post-disaster analysis is correct. You should have modified pacman.conf. You're the most recent person to discover https://bugs.archlinux.org/task/50298 https://bugs.archlinux.org/task/58804 (To be clear, pacman "should" learn to fatally abort with "error: you're not allowed to replace a packaged directory with a symlink", and refuse to let you pacman -Syu until you put things back where they belong. Instead, it gets mid transaction, then as part of uninstalling the old version of pacman it tries to delete /var/cache/pacman/pkg and *doesn't* skip it since it is not a directory. Boom. Your symlink is uninstalled, along with the old version of /usr/bin/pacman and everything else, and then it cannot find the new package anymore to get the replacements.) > i have all the files still in /home/pacman/pkg, etc. (and have put back > the symlink). In that case, reinstalling pacman is an adequate recovery method, though as the disaster manifested by wiping pacman from your system, you'll need to extract the *.pkg.tar.zst using bsdtar, or use the static recovery binaries listed here: https://www.archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/ (Or use the installation media.) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Network manager package naming
On 6/3/20 9:25 PM, LuKaRo wrote: > Hi, > > there are several packages for network manager and related software in > the official repositories. Unfortunately, they follow different naming > schemes. Most packages have "networkmanager" written as one word: > > * networkmanager > * networkmanager-openconnect > * networkmanager-pptp > * networkmanager-vpnc > * networkmanager-strongswan > * networkmanager-openvpn > * ... > > However, some packages have "network-manager" written with a hyphen: > > * network-manager-applet > * network-manager-sstp > > And then there is > > * nm-connection-editor > * nm-cloud-setup > > which follows it's own naming scheme of having "networkmanager" redacted > to "nm". > > Unfortunately, that makes it hard to remember how each package is > called. Therefore there's always some guessing or searching involved > when installing a network manager related feature. Of course, this is > not the biggest issue of all time, but I think it's more complicated > than it should be. Can we simplify the naming conventions of those > packages to use one common scheme that's easy to remember instead of > having multiple coexisting ones? These are the upstream names of the relevant projects. So the "why" of things is not hard to understand. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Arch should be apolitical
On 6/1/20 7:42 PM, Kusoneko wrote:
> I agree with Amir on this. This is an operating system, supposedly
> free from "corporate actions", where for PR reasons a company would
> "support" pride months and other political events. The developers,
> maintainers, moderators and trusted users can support whatever
> politics they want, as publicly as they want, but the OS itself and
> all official channels for the OS should remain free from political
> statements, agendas and actions.
Reddit is not an official channel for the OS, please discuss this with
the unaffiliated entities in charge of said unaffiliated community.
(Also reddit sucks and always has, but that's because it's a meme-ridden
pit of people doing strange things, engaging in offtopic
stream-of-consciousness randomness, and unmoderated help vampires. Also
it implements the dreaded "like"/"upvoting" methodology of community
interaction. Need I say more?)
Problem solved. Let's dance to celebrate.
^('-')^ ^('-')^ v('-')v v('-')v <('-'<) (>'-')> <('-'<) (>'-')> B A
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] How will Arch handle systemd 245 and homed?
On 5/7/20 10:54 PM, David C. Rankin wrote: > All, > > I just read the article about the major change coming to systemd 245 at: > > https://www.techrepublic.com/article/linux-home-directory-management-is-about-to-undergo-major-change/?ftag=TRE475558a=12825460=12819432=712355268 This article is full of inaccuracies, and manages to be embarrassingly wrong about the release date, too. It was published April 29, but refers to systemd as "still being RC2 status" while linking to the RC2 from March 3, while the final release was 3 days later on March 6. 2 months later the article is published. Perhaps the author wrote the article months ago and didn't publish it on time, nor update it to match the real world? > What is terrifying is the SSH Problem. 9/10 hosts I interact with I do via > ssh. And do we really need LUKS encrypted volumes for every user's $HOME > directory? Sure for enterprise setups, etc.. but will there be a way to simply > keep a normal unencrypted /home. How would scripts be able to backup certain > work locations from user directories if the user is logged out? You don't need it, systemd-homed is a solution to a problem that doesn't exist (I like many things about systemd, this isn't one of them). Fortunately, it doesn't matter because it is fully optional. It's no different from providing home directories and user accounts via NFS and LDAP/Active Directory. And those didn't cause the standard type of user accounts to stop working, now did they? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with packaging pyxdg and xdg from PyPI
On 4/4/20 7:32 PM, Ricardo Band wrote: > Ahoi, > > I maintain a tool called virtualfish [1] on the AUR. It is writte in > python and one dependency of it is called xdg [2]. It is not packaged > in archlinux so I would just do that on the AUR. Problem is there > already is a package in archlinux extra which is called python-xdg [3]. > That package includes a python library called pyxdg [4] which does > nearly the same as xdg but is still a different library. > > In my opinion the arch packages python-xdg and python2-xdg have an > incorrect name. They should be called python-pyxdg so the xdg module > could be packaged under python-xdg. > > The naming schema with the python-py prefix looks odd but isn't new. It > is already used in the pyserial [5] package. > > How do we solve this problem? Also keep in mind that since both provide 'import xdg', renaming the package wouldn't let you install both of them. Also when renaming a repository package, we must add provides/conflicts/replaces which means a new python-xdg package would never be found from the AUR, and if manually installed, would prompt to replace it with the repo package on every singe pacman -Syu. Fragmentation is fun. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] nvidia-dkms pkgrel increase after every linux upgrade
On 3/31/20 1:31 PM, Giancarlo Razzolini wrote:
> Em março 31, 2020 14:03 Eli Schwartz via arch-general escreveu:
>>
>> See the broadcom-wl PKGBUILD for how to avoid this. Also note the
>> wireguard-{arch,lts} packages have adopted this method.
>>
>> It's up to Sven-Hendrik Haase if he wants to do this, though.
>>
>
> Well, the best way to avoid this is a complete separate package. But
> also increases
> the burden on the maintainer. So, it's up to Sven to do this, but I
> don't think it's
> strictly necessary.
I would argue it *reduces* the maintenance burden, since you can use the
dkms package as a single source of truth, and makedepends on it to
build. You already know the dkms version should build.
I've even templated it so it is trivial to do
pkgname="${pkgname}-customkernel" and have it do everything correctly to
build for a different kernel.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] nvidia-dkms pkgrel increase after every linux upgrade
On 3/31/20 12:54 PM, Chris Billington via arch-general wrote:
> On Tue, Mar 31, 2020 at 12:48 PM Amin Vakil wrote:
>
>>
>> So why should nvidia-dkms upgrades?
>>
>
> it's because nvidia-dkms is part of a split package that builds both nvidia
> and nvidia-dkms. The bump in pkgrel is to rebuild nvidia for the new
> kernel, and as a consequence the pkgrel for nvidia-dkms is bumped too, even
> though it is unnecessary.
See the broadcom-wl PKGBUILD for how to avoid this. Also note the
wireguard-{arch,lts} packages have adopted this method.
It's up to Sven-Hendrik Haase if he wants to do this, though.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] latest kernel update surprise
On 3/22/20 10:48 AM, Piscium via arch-general wrote: > Another example, Conky. There was an upstream bug when displaying used > RAM, which was fixed in upstream git but months passed and upstream > would not release a new version. So after months of wait I got pissed > off with this RAM display issue and installed the AUR version of > conky. In Fedora in a similar situation typically the Fedora packager > would create a new version of the package with the patch. I don't know > if that happened in the specific case of conky, I have not checked, I > am just talking about what typically happened. Arch has the policy of > not patching upstream code unless needed to fit the Arch way of doing > things. That is one of the reasons why I said that Fedora is more > stable than Arch. That said, Fedora 13 for me was an horror story, I > had lots of kernel crashes! Note that backporting an upstream fix is not considered "patching upstream code". In that case, it will just depend on how problematic the issue is and whether it justifies the effort of a backport. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Python2-gimp - what functionality was lost?
On 3/19/20 11:23 PM, David C. Rankin wrote: > All, > > I updated gimp tonight and received: > > ( 6/19) upgrading gimp [##] 100% > > The python2 plugin support is disabled, you will need to install this > > separately if you need it, e.g. the python2-gimp package in the AUR. > > Looking at several bugs about python2 and gimp and it seem that gimp is not > removing python2 during gimp 2.10: > > https://bugzilla.redhat.com/show_bug.cgi?id=1737933 > > Do we know what functionality was lost when we removed python2 support for it? > I don't use it that often, but do use it fairly thoroughly when I do. From > that standpoint, is there a list of what now isn't part of gimp without > python2? That would help in knowing whether the AUR package is needed. https://bbs.archlinux.org/viewtopic.php?id=253710 This is purely related to the pygtk-based plugin support. (Plugins that use C, scheme, etc. are not affected.) > Seems strange the AUR package was posted and orphaned on 2020-03-18? The person who uploaded it was interested in providing a solution for the forum user whose python/pygtk based plugin no longer worked -- and in demonstrating how that solution could be achieved in the general case. The person who uploaded it was not interested in providing long-term maintenance of that AUR package, therefore, it was immediately orphaned. Seems pretty clear-cut to me. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Teo En Ming's Linux From Scratch (LFS) 20200302-systemd Bootable Live CD/DVD Kernel Panic
On 3/17/20 12:16 PM, Turritopsis Dohrnii Teo En Ming via arch-general wrote: > Subject: Teo En Ming's Linux From Scratch (LFS) 20200302-systemd > Bootable Live CD/DVD Kernel Panic > > Good day from Singapore to all Linux users, > > Recently, on 12 March 2020, I have successfully created my own custom > Linux distribution which I affectionately call it Teo En Ming Linux. > My custom Linux distribution is based on the most basic Linux From > Scratch (LFS) 20200302-systemd book and Linux kernel 5.5.7. I am able to > boot it successfully on > my Toshiba 1 TB 3.5 inch SATA internal harddisk /dev/sdb2. > > After the initial success, I wanted to make a bootable Live CD/DVD of my > Linux From Scratch system. I followed Jimmy Anderson's guide (which was > written more > than 7 years ago on 20 Jan 2013) and modified his guide in trying to > make it work with LFS 20200302-systemd book. > > You may refer to the following guides on how I created a bootable Live > CD/DVD of my Linux From Scratch system. If you are building your own distro based on the LFS handbook, then this doesn't have anything to do with the independent archlinux.org distribution. We have our own distribution building process and don't know how the LFS mechanism works. This is not the correct place to seek help, in other words. The LFS community has their own mailing list for this, and I see that you have already posted there: http://lists.linuxfromscratch.org/pipermail/lfs-support/2020-March/053535.html Please have patience and wait for an answer from the LFS community, rather than asking LFS questions to the Arch Linux community. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with reflector
On 3/8/20 12:29 AM, Yaro Kasear wrote: > > On 3/7/20 11:21 PM, Eli Schwartz via arch-general wrote: >> On 3/7/20 11:53 PM, Yaro Kasear wrote: >>>> Thanks for your reply. If I put this in a bash script, will it reset once >>>> the script is done running? >>>> >>> I suspect it will if you drop the 'export' directive and just set PATH >>> without it. >>> >>> I'd strongly recommend testing it until it works for you. >> But the "PATH" environment variable already has the export attribute on >> it, so it is exported either way. >> >> Furthermore, I'm bewildered w.r.t. what is the question/goal here? If >> you set some variable in a script, it will never modify the environment >> of the *parent process*, only the script itself, and child processes >> started by the script. >> >> Have I completely misunderstood the question? >> > If they are having trouble invoking Reflector, a simple two-line script > to change PATH just for the script and an instance of Reflector is all > they would need. I won't comment as to the unconventional setup they > have for their system, though. I personally wouldn't change my PATH like > that, but this isn't about what *I* am doing. Then if it is just about the wrapper script, as I said -- "export" builtin or no "export" builtin, it won't change anything if the env var has been previously marked as exported in the past. And it needs to be marked as exported regardless, or running the "reflector" command won't see the modified env var. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with reflector
On 3/7/20 11:53 PM, Yaro Kasear wrote: >> Thanks for your reply. If I put this in a bash script, will it reset once >> the script is done running? >> > I suspect it will if you drop the 'export' directive and just set PATH > without it. > > I'd strongly recommend testing it until it works for you. But the "PATH" environment variable already has the export attribute on it, so it is exported either way. Furthermore, I'm bewildered w.r.t. what is the question/goal here? If you set some variable in a script, it will never modify the environment of the *parent process*, only the script itself, and child processes started by the script. Have I completely misunderstood the question? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with reflector
On 3/7/20 11:49 PM, karx via arch-general wrote: > I don't think you're understanding, it's not a venv. It is simply an > alternative python installation (similar to Anaconda Python) that lets me > manage my python versions. I don't know or care what asdf-vm is, but the difference between an alternative python interpreter and a venv running on the system python interpreter is entirely academic. At the end of the day, you're running an interpreter which is siloed away from the system python environment, and then you're enabling it by default, which... breaks the default python. Although, if you're just interested in running additional python versions other than the /usr/bin/python3.8 binary currently provided by Arch, then... you really should not be overriding the "python" binary at all. Just install a python3.7 program or whatever, and invoke it as `python3.7`. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Problem with reflector
On 3/7/20 10:53 PM, karx via arch-general wrote: > On Sat, Mar 7, 2020, 9:50 PM Neven Sajko wrote: > >> I have not fully understood your situation, but can you not just >> change the PATH environment variable? >> > > No. I need python for other projects, and would much rather use a version > management system rather than risk messing up the system python. Basically, > what I am asking is, can I get reflector to work with pyenv? This has nothing to do with reflector, you will as a general rule of thumb break *all* python software by using a venv as the default python. You should only be using venvs when manually activated for a given project, limited to the shell in which you are using the project. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] How did spyder/python-spyder-kernels downgrade version?
On 3/7/20 7:06 PM, Oon-Ee Ng via arch-general wrote: > I've got spyder-4.0.1-2 and python-spyder-kernels-1.8.1-1 installed. > They're not self-compiled, they just came in as regular repo updates (on > 22nd February 2020). > > However the current repo version of both is 3.3.6-2 and 0.5.2-4. Looks like > a rollback of spyder related packages took place? Shouldn't epoch be > updated in that case? > > I have [testing] enabled but I don't know how to check if the current > installed version is from community-testing. pacman -Ss spyder Looks like the new version was added to community-testing, then withdrawn. Any future updates to it *should* increment the pkgrel once again, so no downgrades ever happen. As for why they were withdrawn to begin with, this has some context: https://bugs.archlinux.org/task/65683 -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Package Jami is out of date
On 2/26/20 9:08 PM, Simon Brand wrote: > On Wed, 26 Feb 2020 20:57:30 -0500 > Eli Schwartz via arch-general wrote: > >> This, however, is not. Why do you think that Bruno is "not active >> anymore"? Why do you think that asking someone else to take over his >> package due to him being Missing In Action is the correct solution? > > Thank you for the reply. > I thought, he is not active anymore, because he is not listed as an > arch linux developer. [0] > I wanted to write him an email, but since I have not found his mail on > the developers site, I thought he is not active anymore. > > Now that I looked it up again I saw the notice, that only core and > extra maintainers are listed there. My bad. > > thank you for the explanation, now that I know the cause I will be > patient. > > Best, > Simon > > [0] https://www.archlinux.org/people/developers/ Aha. :) Here's a tip to make this easier. Look at the field: Last Packager: Bruno Pagani The name is a clickable field, it links to https://www.archlinux.org/packages/?packager=Archange which is a search for all packages that were last packaged by that maintainer. If you click on the heading for "Last Updated" you can also sort those by how recently they were updated. This lets you very quickly see how recently that package maintainer has been actively updating packages. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Package Jami is out of date
On 2/26/20 6:11 PM, Simon Brand wrote: > Hello, > > the package Jami is out of date: > https://www.archlinux.org/packages/community/x86_64/jami-gnome/ This is a true fact. > The last packager seams to be not active anymore. > Can anybody please take over the package? This, however, is not. Why do you think that Bruno is "not active anymore"? Why do you think that asking someone else to take over his package due to him being Missing In Action is the correct solution? Have you tried asking him what the delay is? ... As a matter of fact, this was extensively discussed on the 16th through the 18th in our private IRC channel. The new version of jami-daemon does not build against the currently packaged version of libupnp, and other applications don't build against the newer versions of libupnp due to lots of API changes. This is not trivial to solve and multiple people are working on a solution. In no way is Bruno Pagani (@Archange) "not active anymore". Please have patience. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] Potential removal of Chromium in ~2 months
On 2/23/20 8:23 AM, Geo Kozey via arch-general wrote: > Hi, > > First of all let me thank you for high quality maintainership of > chromium package in Arch. > > This post was really surprising for me and sad but also quite > confusing because I don't understand how lack of some minor feature > can involve nuclear option of removing dominant and most > tech-advanced browser on the market from Arch repos. Nobody ever suggested removing Firefox. > I bet most users won't even notice lack of it and some may even > welcome removal of so called "spyware". > > Those who treat geolocation as critical feature may choose different > browser but forcing everyone out of they beloved one for this > particular reason seems like overreaction to me. > > Yours sincerely > > G. K. > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] post-install dependencies check
On 2/21/20 4:27 PM, Ralf Mardorf via arch-general wrote: > On Fri, 21 Feb 2020 22:22:14 +0100, Ralf Mardorf wrote: >> I suspect that paccheck's recursive option is unneeded. > > Doing a few tests, the quite option seems to have no impact either. > > paccheck --opt-depends > > or > > paccheck --opt-depends PACKAGE_NAME > > seems to provide the same output as > > paccheck --opt-depends --quiet --recursive Check again. $ paccheck --opt-depends bash bash: all optional dependencies satisfied $ $ paccheck --opt-depends --quiet bash $ -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] post-install dependencies check
On 2/21/20 4:22 PM, Ralf Mardorf via arch-general wrote: > I suspect that paccheck's recursive option is unneeded. I don't understand how you could possibly think so? The recursive option plainly makes it *recursive*, i.e. it lists the uninstalled optdepends for all your dependencies. This is quite important, for example, if you are using a program named "epiphany" which does HTML rendering via webkit2gtk and you wish to know why it doesn't play media. The --recursive flag will go through all the dependencies and show that *epiphany* is not playing media because *webkit2gtk* is missing its optional dependencies on gst-plugins-good gst-plugins-bad. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] post-install dependencies check
On 2/21/20 2:11 PM, Jude DaShiell wrote: > Can pacman be used to find which packages are missing which optional > dependencies after an install? pacman -Qi for a given package will show you optional dependencies and list which ones are satisfied. You can walk a dependency tree automatically and check for things which have uninstalled optdepends, by installing community/pacutils and running the command: paccheck --opt-depends --quiet --recursive with, optionally, the list of packages to do checks for. By default, like pacman -Qi, it will interpret no explicitly specified packages as "all installed packages". -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [pacman-dev] Privilege separation in the pacman downloader (Was: Pacman Database Signatures)
On 2/4/20 11:08 PM, Eli Schwartz wrote: > Since I'm unfamiliar with apt and other tools, what exactly do they do? > Given pacman/apt/your-choice-of-package-manager must somehow write to a > cachedir, e.g. /var/cache/pacman/pkg, it would need a dedicated download > user, which would then exclusively hold ownership of the cachedir. > > pacman is one big binary at the moment, it doesn't fork+exec to run > collections of binaries implementing different parts of the package > manager (which is actually a plus when it comes to speed), so this might > entail major re-architecturing of that part of pacman. Doing it for > external XferCommand programs could be a start. > > Is this a topic you're interested in exploring? I've opened a feature request for this: https://bugs.archlinux.org/task/65401 -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why are Archlinux packages stripped of (debugging) symbols?
On 1/24/20 2:29 PM, Giancarlo Razzolini wrote:
> I wouldn't be opposed to have something like tecken [0] or some other
> software
> for this (not sure if there is one) where we would upload all the symbol
> artifacts
> for Arch built packages and that users could use when needed.
>
> This wouldn't require changing neither dbscripts nor devtools, but it
> would be helpful
> if devtools had some function to facilitate this. This solution wouldn't
> bloat neither
> our packages nor our mirrors and would be useful to all Arch users. Of
> course, we could
> keep only the last X number of versions on this service, I don't see the
> point in having
> something like the Arch Linux Archive where we try to preserve everything.
>
> Regards,
> Giancarlo Razzolini
>
> [0] https://github.com/mozilla-services/tecken
Oooh, that's actually a really interesting idea. I bet we could make
this just consume a foo-debug package, then we could just modify
devtools to add OPTIONS+=('debug') in makepkg.conf, and have commitpkg
upload the debug package separately to the symbol server.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Why are Archlinux packages stripped of (debugging) symbols?
On 1/21/20 6:00 PM, Neven Sajko wrote: > Regarding the firefox example, are the split debugging symbols files > publicly available? Mozilla's symbol server is described here: https://developer.mozilla.org/en-US/docs/Mozilla/Using_the_Mozilla_symbol_server#Downloading_symbols_on_Linux_Mac_OS_X -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why are Archlinux packages stripped of (debugging) symbols?
ace to Mozilla.org; this >> backtrace is then merged with the debug info which is on Mozilla's >> servers, to produce meaningful output. Users don't have to suffer huge >> downloads. >> >> (Mozilla's symbol server can also be used with a trivial gdb script to >> let gdb download the debug info on-demand, if you're debugging firefox.) >> >> The Arch maintainer for firefox actually does exactly this -- our >> firefox package is stripped, but the symbols are uploaded to Mozilla >> right after makepkg completes. > > Well this is certainly *complicated*. But it is warranted because of > the great size difference, most packages don't need this and could > include debugging symbols, I think. > > To reiterate, I certainly think that split debugging symbols in split > packages in official repos would be an improvement; but I would like > to know why are more packages built with included debugging symbols. > Do you think that, eg., all packages in "core" being built with > debugging symbols would be OK? Maybe it would be OK if just function > names were included, without source file line info? > > Sidenote: Do you know why are split debug packages not yet available? I'm personally not a fan of bloating packages even by 10% or whatever for debug symbols that many users don't need. As I said above, split debug packages need "dbscripts" support to make sure they are correctly handled by our repository-building scripts. If dbscripts supported it, we could enable the debug option in devtools' makepkg.conf and start building all packages with debug info. (Patches welcome!) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Why are Archlinux packages stripped of (debugging) symbols?
, whereby heavily stripped programs are distributed to end users, and if the program crashes it can send the backtrace to Mozilla.org; this backtrace is then merged with the debug info which is on Mozilla's servers, to produce meaningful output. Users don't have to suffer huge downloads. (Mozilla's symbol server can also be used with a trivial gdb script to let gdb download the debug info on-demand, if you're debugging firefox.) The Arch maintainer for firefox actually does exactly this -- our firefox package is stripped, but the symbols are uploaded to Mozilla right after makepkg completes. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Finding virtual dependencies
On 1/6/20 10:01 AM, Lone_Wolf wrote: > Hi, > > > Often when packages are removed from repos they become virtual provides. > > While those are great for a transition period , they are not meant to be > used forever. > > > Unfortunately they do stay around for a very long time. > > > example : > > Around mesa 10.3.0-1 from august 2014[1] ati-dri, intel-dri, > nouveau-dri and svga-dri were replaced by mesa-dri . > > In mesa 10.4.0-1 from december 2014 mesa-dri was integrated in mesa. > > we're now 5 years further and mesa still provides & conflicts ati-dri, > intel-dri, nouveau-dri, svga-dri and mesa-dri. > > > I have wanted to file a bug to get them removed for some time, but don't > know if there are packages that still use them that would break if they > are removed. > >> $ pacman -Ss ati-dri >> extra/mesa 19.3.1-1 >> An open-source implementation of the OpenGL specification >> multilib/lib32-mesa 19.3.1-1 >> An open-source implementation of the OpenGL specification (32-bit) >> $ > > Is that output proof enough that ati-dri is not used by anything else > then mesa & lib32-mesa or is there a better way to determine which > packages depend on a specific virtual package ? > > Lone_Wolf > > > [1] > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mesa=f5ea4245b126d684bc71712bce482cbe575db3eb > > > [2] > https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mesa=90c5431e1e466ee583de100d0388f72649e75ee1 On https://www.archlinux.org/packages/extra/x86_64/mesa/ under "Required By (191)", none of these provides are in use, compare to the third package: "bumblebee (requires mesa-libgl)" or further down, see "abuse (requires mesa-libgl) (make)" So it seems nothing depends on *-dri, not even for make/check depends. There's even only one AUR package which uses one of them: https://aur.archlinux.org/packages/xf86-video-opentegra-git/ -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Adding a "posix" metapackage
On 1/4/20 9:56 AM, Ralf Mardorf via arch-general wrote: > On Sat, 04 Jan 2020 12:41:26 +, Ralph Corderoy wrote: >> Arch users may be producing code for non-Arch, non-Linux, systems. > > Happy New Year! > > Pff! Bash is the most used login shell for Linux for good reasons. > Sometimes I like it faster, hence I like to use dash, sometimes I like > portability to at least FreeBSD, if so I care about this, too. > > Linux isn't POSIX, period! Sure, bash adds lots of interesting things on top of POSIX, but the reason it is so popular is in large part because it implements the POSIX baseline. Also, it is the most-used login shell, not the most-used script shell. It is very popular as a script shell too, but /bin/sh is also a very popular script shell, explicitly for portability across operating systems. > Let alone that Unix System V-style initialization has nothing in common > with systemd based Linux distros, something that is as important > regarding portability, as POSIX is. Who said anything about System V init? Why would System V init be needed for portability? > Btw. I didn't receive the complete thread, while I received all other > threads from other and this list completely, or maybe I received the > complete thread, if so, somebody likely has broken the thread and the > subject, too. When and where did this thread start? > > I only can see the three mails I received and no additional mail here: > > https://lists.archlinux.org/pipermail/arch-general/2020-January/date.html > > I can _not_ find a subject "Adding a "posix" metapackage" in the > December, November, October or September archive, too. > > Actually I wasn't interested to reply at all, I'm just curious about > information related to POSIX vs Linux, IOW I'm interested in learning > by reading, but it's a broken thread. > > Could you please provide a pointer to the start of this thread? The thread started on arch-dev-public; replies on arch-general occurred when members of the community wished to discuss the matter as well. Hope that helps. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Adding a "posix" metapackage
On 1/3/20 10:49 AM, Ralph Corderoy wrote: > Hi Santiago, > >> I'm curious, though, are there any specifics about the providers on >> these POSIX tools/libraries/whatnot (i.e., would it be wortwhile >> discussing the alternatives?). > > Is sh being provided by bash(1)? A more POSIX-compliant shell may be > better, one that doesn't let lots of bashisms pass without complaint. > dash(1)? And dash doesn't have time as a built-in, so we get to pull in > an executable for that too. Currently, sh is provided exclusively by bash, though ksh, zsh, mksh and busybox also provide a "time" builtin. I guess it would be reasonable to uncomment it. > As for SCCS, it's a handy file format. Better in design that RCS's. > And used by other tools over the years, e.g. Bitkeeper, so they do > linger on. Plus it's a historical file format, just as ncompress was > sought to be more POSIX compliant. But ncompress is simple to package and generally useful -- it can even be used by makepkg for extremely fast compression (albeit not as compressible as gzip or other recent formats). SCCS would require me to actually package it! So I need to decide if I'm interested in the effort that would take, for an XSI option. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Firefox-71.0-1 breaks WhatsApp Web
On 12/9/19 11:01 AM, David Rosenstrauch wrote: > > > On 12/9/19 6:48 AM, Giancarlo Razzolini via arch-general wrote: >> You should not upgrade the firefox package while it's open. That's a >> lesson I've >> learned when I've also lost a profile. Everytime you see firefox in >> the upgrade >> packages list, I suggest you close it and then upgrade. > > IMHO, you really shouldn't upgrade any package while it's running. I > always use "pacman -Syuw" to download all needed updates, then drop into > single user mode to actually install everything with "pacman -Su". Seems > like that would be a best practice to me. You can use `checkupdates -d` to download packages using a temporary database, thus avoiding: https://wiki.archlinux.org/index.php/System_maintenance#Avoid_certain_pacman_commands Which may lead to accidental cases of: https://wiki.archlinux.org/index.php/System_maintenance#Partial_upgrades_are_unsupported -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman has nothing to do last 5 days
On 12/7/19 7:06 PM, mick howe via arch-general wrote: > For the last five days or so it reports nothing to do:- > > [mick@cave ~]$ pacman -Syyuu > :: Synchronizing package databases... > core 135.1 KiB 938 KiB/s 00:00 [##] > 100% > extra1647.8 KiB 2.68 MiB/s 00:01 [##] > 100% > community 4.7 MiB 2.66 MiB/s 00:02 [##] > 100% > multilib 164.2 KiB 2.97 MiB/s 00:00 [##] > 100% > :: Starting full system upgrade... > there is nothing to do > [mick@cave ~]$ > > This is the first time in around 10 years of running Arch this has > happened, has some thing changed in pacman that I missed? This seems weird, what mirror are you using? Maybe the mirror is broken and you need to update your mirrorlist. P.S. STOP using -Syyuu, since the double y tells pacman to force download databases even when the server says there is no update, and the double u tells pacman to downgrade any packages the server claims are old. If you used a plain old -Syu, then you would almost certainly see five days worth of "[repository] is already up to date", which would be a definite red flag that something is wrong. Now that you used -Syyuu, we have no idea whether your pacman installation refreshed the databases because the server said they needed to be refreshed or because you told pacman to ignore the freshness. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Note: Latest bind-9 update removes root.hints - fails to start with old configs
On 12/7/19 12:52 AM, David C. Rankin wrote:
> All,
>
> Just a note to anyone running bind-9 for name resolution, the old configs
> containing root.hints now results in named failing to start with:
>
> Dec 06 14:53:02 phoinix named[455]: could not configure root hints from
> 'root.hint': file not found
> Dec 06 14:53:02 phoinix named[455]: loading configuration: file not found
> Dec 06 14:53:02 phoinix named[455]: exiting (due to fatal error)
FWIW:
https://bugs.archlinux.org/task/61732
https://kb.isc.org/docs/aa-01309#do-i-need-to-configure-a-root-hints-zone-myself
The removal of this from the pa
> The solution is just to comment out the old dummy zone relying on root.hints
> (I'm sure I recall a note about this some time about, but now it is official).
>
> Quickfix:
>
> // zone "." IN {
> // type hint;
> // file "root.hint";
> // };
The bind 9.14.8-3 update removed the root.hint file and correspondingly
removed the dummy zone you have commented out in the packaged backup
file /etc/named.conf -- you should have noticed a warning from pacman
about a pacnew file.
In this case, it would seem that resolving the pacnew file is required
in order to start the updated bind package. :)
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Failed to compile python 2.7.9 with pyenv on arch.
On 12/2/19 1:00 AM, Hongyi Zhao via arch-general wrote: > Hi, > > I try to compile python 2.7.9 with pyenv on arch linx with the > following command: > > === > $ pyenv install 2.7.9 > Installing Python-2.7.9... > patching file ./Lib/site.py > patching file ./Lib/ssl.py > ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib? > > Please consult to the Wiki page to fix the problem. > https://github.com/pyenv/pyenv/wiki/Common-build-problems Well, the error message is pretty clear that the problem is "the OpenSSL lib", so if you look on that wiki page for information about the OpenSSL lib, you'll hit the following subcomponent of that page: https://github.com/pyenv/pyenv/wiki/Common-build-problems#error-the-python-ssl-extension-was-not-compiled-missing-the-openssl-lib It specifically calls out archlinux with an indication that this ancient version of python requires an openssl version less than 1.1 (and mentioning the name of the CFLAGS and LDFLAGS you'll need to successfully compile ancient python in such cases). This matches the official python2 documentation: https://docs.python.org/2.7/library/ssl.html "Changed in version 2.7.13: Updated to support linking with OpenSSL 1.1.0" > BUILD FAILED (Arch Linux using python-build 1.2.15-2-g22c0202) > > Inspect or clean up the working tree at /tmp/python-build.20191202134159.88051 > Results logged to /tmp/python-build.20191202134159.88051.log > > Last 10 log lines: > rm -f /home/werner/.pyenv/versions/2.7.9/share/man/man1/python.1 > (cd /home/werner/.pyenv/versions/2.7.9/share/man/man1; ln -s python2.1 > python.1) > if test "xno" != "xno" ; then \ > case no in \ > upgrade) ensurepip="--upgrade" ;; \ > install|*) ensurepip="" ;; \ > esac; \ > ./python -E -m ensurepip \ > $ensurepip --root=/ ; \ > fi > == These log lines are useless, your problem has nothing to do with running ensurepip. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] python-cmake?
On November 28, 2019 9:31:19 AM EST, "Iyán Méndez Veiga" wrote: > Hi, > > First of all, sorry if this is a really stupid question, but I've been > trying > to search for a while and I couldn't find an answer. It's a confusing question, because it is a confusing module. :) I'll try to clarify your confusion below. > Is the python module 'cmake' provided in some package in Arch? I mean, > I know > that there is the cmake package in [extra] but there is no > python-cmake, and > when I try 'import cmake' of course the module is not found. > > This works if I install cmake with pip: > > $ python -m env test > $ source test/bin/activate > $ (test) pip install cmake > $ (test) python > $>>> import cmake > > Thanks, > Iyán What you installed is a bundled, prebuilt copy of cmake stuffed into $venv/lib/python3.8/site-packages/cmake/data/ This data directory contains the same hierarchy of bin/ lib/ and share/ that pacman -S cmake would install to /usr instead. There is also a $venv/lib/python3.8/site-packages/cmake/__init__.py which contains a single set of functions, cmake() cpack() and ctest(), which search for the hidden binaries in $venv/lib/python3.8/site-packages/cmake/data/bin/ and execute them using subprocess.call() You're not supposed to use these functions at all. They only exist so that pip can install a setuptools entry point, which allows you to source $venv/bin/activate and then be able to run `cmake` in a command prompt, which will run $venv/bin/cmake, which imports python, uses it to find the hidden data directory, and finally executes the cmake binary. You cannot even additionally use the module as a shortcut to subprocess.call within your own python-based project, since it hardcodes sys.argv[1:] as the arguments to pass to cmake. The PyPI package "cmake" is *not* meant to be used in python scripts, and its only purpose is to very inefficiently abuse PyPI as a distribution mechanism that is easier to use than flatpak or snapd, because people are more likely to have pip installed than either of those, and because their Linux distro is probably named "Ubuntu" so they cannot otherwise easily get a modern version of cmake. Similar modules exist in the NodeJS ecosystem that abuse npmjs.org to install nom modules that contain no JavaScript, but do contain a bash script. Because downloading bash scripts into $HOME/bin/ is hard, but npm install mycoolscript is "easy". tl;dr Wherever you saw the advice to pip install cmake was probably misinformed. This does not provide python bindings to cmake. -- Eli Schwartz Bug Wrangler and Trusted User
Re: [arch-general] about ecryptfs-utils, openssl supporting should be added ?
On 11/27/19 11:52 AM, Karol Babioch wrote: > Hi, > > Am 27.11.19 um 05:42 schrieb Yi Zheng via arch-general: >> why not add '--enable-openssl' into the configure options? >> >> Does it support OpenSSL now? > > This mailing list might not be the right place (TM) to ask those kind of > questions. You should rather ask questions like this directly to the > package maintainer(s), which for this package [1] happen to be: > >> # Maintainer: Timothy Redaelli >> # Contributor: Richard Murri >> # Contributor: Michal Krenek The maintainer listed in the file retired from Arch, and the package has not been updated since then except for two mass rebuilds, one for openssl 1.1.0 and one for PIE/BUILDINFO. Wait, what was that about openssl support? > Alternatively you can file a bug [2], so it gets attention by the right > people. Always try to verify if the bug actually exists before reporting it. Whether the --enable-openssl flag is passed or not is irrelevant, most projects will tend to make support for basic things like openssl, the default. $ pkg-list-linked-libraries ecryptfs-utils ==> checking linked libraries for ecryptfs-utils-111-3-x86_64.pkg.tar.xz ... [..] /usr/lib/ecryptfs/libecryptfs_key_mod_openssl.so NEEDED libcrypto.so.1.1 NEEDED libdl.so.2 NEEDED libc.so.6 [...] And indeed, the configure.ac for the project contains: AC_ARG_ENABLE( [openssl], [AS_HELP_STRING([--disable-openssl],[Disable build of OpenSSL key module])], , [enable_openssl="detect"] ) If not explicitly disabled, it will try to check for libcrypto using pkg-config, then fall back on checking for openssl using pkg-config, then fall back on using AC_CHECK_LIB to try to find -lcrypto with a usable RSA_version public function. The "detect" criteria is always met because openssl is a core functionality for Arch Linux, for example curl/libcurl depends on libssl, and pacman uses libcurl as well as directly using libcrypto. coreutils also depends on openssl. In the unlikely event that openssl was removed from the set of packages installed in a base installation (which would be an event of note for linux distributions in general), the ecryptfs-utils PKGBUILD would only need to explicitly depend on openssl. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-general] calibre is now available in python3
After about 15 months of gradual work by me and a few other people, https://calibre-ebook.com/ is running pretty stably on python3, so I've uploaded a split package to [community]: calibre (the default python2 build), calibre-python3 (a python3 build, naturally), and calibre-common with some common files. Hopefully this will get rid of one of our major python2 consumers soon. Upstream doesn't officially support this yet, so treat it like the pre-beta it is. You'll also be unable to use thirdparty plugins, since none of those are ported yet, so you may want to have both 'calibre-python3' and 'calibre' installed -- since pacman still doesn't have support for an "alternatives" feature, I've written a dumb shell script to do the work of switching between the two, see `calibre-alternatives help` for details (it is in the calibre-common package). General information about the port and its status can be found here: https://github.com/kovidgoyal/calibre/pull/870 At some point soon upstream will finish making cross-platform betas and plugins will start to be ported by their developers, so watch this space (and the mobileread.com forums) for more info... Bug reports for python3 regressions will be greatly appreciated, as there are probably a lot of fun edge cases and I'd like to see this finished sooner rather than later. ;) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] New kernel packages and mkinitcpio hooks
On 11/11/19 12:00 PM, Damjan Georgievski via arch-general wrote:
>> This has been discussed a bit on the dracut thread, as well on some other
>> threads over time.
>> I *personally* don't like the complexity of kernel-install that much.
>
> I've now read this twice on Arch mail lists, so I have to ask, without
> any presumptions on my side, what are the arguments against
> kernel-install?
>
> I must say, I don't see much complexity in it. It's only a 184 line
> bash script[1].
A one line bash command in the PKGBUILD is 184x less complex, then.
That's a pretty major difference.
(One line of bash in the PKGBUILD, plus running mkinitcpio -p linux, vs.
kernel-install plus still running mkinitcpio -k "${uname_r}" -g
/boot/$MACHINE_ID/${uname_r}/initrd -- mkinitcpio is a static constant
here, unless you switch to dracut.)
But if you want my $0.02 why I personally think it is too complex, the
answer is I've read the script and internalized what it does, and
irrespective of the "line count" I consider the actions which it
undertakes to do, to be too many complex moving parts to make me
comfortable relying on it on my own laptop.
> And as added feature, it decouples the kernel install from the kernel
> package install (and pacman),
> also defines couple of easy-to-use config locations like /etc/kernel/cmdline
>
> But I guess I might be missing something.
For a really simple setup, it is totally unnecessary and I would prefer
my kernel to be tracked by pacman. It needs no modifications in order
for me to use it in my bootloader (I use grub, which is capable of
booting with a 3-line grub.cfg, 4 lines if your kernel is stored on a
luks-encrypted partition), so why not simply use it from pacman's own
installation location?
Why is it explicitly a feature to "decouple the kernel from the package"?
Why is it a feature to store the kernel cmdline in a location divorced
from your bootloader?
That being said, there is literally nothing whatsoever stopping people
from using kernel-install if they want to.
Aside: kernel-install surely does not care whether it uses the 'cp'
command to copy files from /boot, or whether it uses the 'cp' command to
copy them from /lib/modules. So it was fully usable 5 years ago, as far
as I can tell. It was even fully usable during the short transition
period when /lib/modules/${uname_r}/vmlinuz was a symbolic link pointing
to /boot/vmlinuz-linux, because the POSIX definition of 'cp' mandates
that it copy over the file contents of the regular file which the
symbolic link points to (unless the script overrides this by using the
-P, --no-dereference option). It works and worked with dracut too, since
dracut's uefi executable generation also reads file contents after doing
symlink traversal, via objcopy.
The entire history of Arch Linux has been completely one hundred percent
supportive of people's desire to use kernel-install. If no one is doing
it, I can only presume no one actually wanted to do it.
...
Now, if the discussion is about making the kernel-install workflow a
hard requirement of using mkinitcpio, I do not understand the logic
here. mkinitcpio is one of the programs executed by kernel-install, as
implemented via /usr/lib/kernel/install.d/50-mkinitcpio.install
As such, it would make zero sense for mkinitcpio's own alpm-hook to
execute kernel-install before running mkinitcpio, only for
kernel-install to then run mkinitcpio again, in addition to a bunch of
other kernel-install specific stuff that isn't mkinitcpio's
responsibility. kernel-install is NOT a program to copy over the kernel
to the bootloader's final destination! It is a one-stop-shop that wants
to do everything from beginning to end, including take charge of
mkinitcpio itself. If you want to use kernel-install, then delete and
mask the alpm-hooks
/usr/share/libalpm/hooks/60-mkinitcpio-remove.hook
/usr/share/libalpm/hooks/90-mkinitcpio-install.hook
and write your own, which trigger on the same package updates but
instead run kernel-install according to the documented kernel-install API.
Also, please write wiki documentation for it. As far as I can tell, no
Arch Linux user has ever gone to the effort of writing up guidance on
using the officially supported kernel-install program which Arch Linux
has always installed and has provided mkinitcpio plugins for since
September 2013.
It would be wonderful if Arch Linux would, in the spirit of user choice
to which we aspire, provide guidance on opting into the use of a
technology that a significant percentage of our active community says
they would like to use.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] How to install archlinux using a specific parition of usb instead of the whole usb?
On 11/5/19 8:35 PM, Hongyi Zhao via arch-general wrote: > Hi, > > I try to use a specific partition of usb to install archlinux, the > following is the step: > > Suppose the /dev/sdc is my usb: > > $ sudo ddrescue -f archlinux-2019.11.01-x86_64.iso /dev/sdc2 The ISO contains multiple partitions, so probably not. Why are you trying to do this, precisely? Maybe you want to install archlinux following the install guide, but installing to the USB partition instead of an HDD. For example, https://wiki.archlinux.org/index.php/Installing_Arch_Linux_on_a_USB_key Alternatively, you can use grub to boot an ISO *file* as a loopback device. Some people do this to create multiboot USBs. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 3:46 PM, Giancarlo Razzolini wrote: > Hi Eli, > > This is totally uncalled for. Even though I agree that kernel-install is > *not* > that great, there's no need to be aggressive. > > The question, even if phrased not in the best way, is a legitimate one. Didn't seem like much of a question to me. As far as I'm aware, there is no actual blocker to it, we even package it as one of the collection of tools made available by systemd so you literally cannot avoid having it available as it's a mandatory part of base. (The kernel is not mandatory, and mkinitcpio is not mandatory, but kernel-install is mandatory.) To aid such people, both mkinitcpio and dracut install relevant files to /usr/lib/kernel/install.d/ ... If people think kernel-install is an interesting technology which they would like to try out, that is fine. If people think kernel-install is literally the best ever and they must use it, that's fine too. I personally don't feel that way, and would rather have the option to skip the use of kernel-install, and that is fine too. I'm a bit skeptical, though, of posts which feature, essentially, "I notice Arch Linux does not bless kernel-install as the official kernel method of Arch Linux and request that you justify your decision to not use documented standards[0] and instead use your exclusivist Arch Linux hooks which merit multiple exclamation marks worth of surprise, because gosh is this surprisingly surprising". So I *inverted the question*. (I acknowledge I may have gotten a bit exaggerated in the process... I apologize. OTOH, I didn't quite intend my statements about kernel-install 100% seriously.) -- Eli Schwartz Bug Wrangler and Trusted User [0] Putting something in a manpage doesn't necessarily make it a standard, even if you find it really useful and enjoyable to use. signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 6:19 PM, Geo Kozey via arch-general wrote: > Thx, my concern was more about maintenance burden for Arch devs vs relying on > dracut + kernel-install combo and call it a day. > If devs prefer to work on exclusive service for Arch users then let it be. Dracut does not work out of the box (we currently patch it to not use a nonexistent tool, and the same patch is now in upstream master but with no release in sight), and has issues like the tests failing on non-Redhat systems. Our dracut packager tried to get in touch with the dracut developer, after a lack of success for quite some time it seems that the individual in question was on... parental leave, IIRC? I'm not sure what the current status is. So the jury is still out on whether dracut or mkinitcpio is more work. ;) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] new packaging of the kernel/mkinitcpio/kmod
On 10/31/19 2:11 PM, Geo Kozey via arch-general wrote: > What was the reason for not using kernel-install[1] standard instead of all > of those Arch's exclusive hooks again?? > > https://www.freedesktop.org/software/systemd/man/kernel-install.html What was the reason for suggesting to use kernel-install non-standard Fedora tool that does gross things in a gross way instead of "all those tools" (all one of them) which do the exact same thing in a more KISS manner that respects user choice, makes it clear what you're using and when you're using it, and helps track files properly in pacman? I don't understand your loaded question, but this game of "let's assume things and then yell at people for doing things the same way they worked for many many years" sure is fun! P.S. Put down your question mark key. There's no need to act quite *that* shocked that no one drank the Fedora kool-aid. *steps off soapbox* -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] 'base' package install with non-updated linux-kernel
On 10/19/19 9:53 PM, riveravaldez via arch-general wrote: > 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-package-manual-intervention-required/ If your kernel issue was making you not do any updates at all, this seems... suboptimal as you then get no updates at all. The kernel is the one package it is completely okay to not upgrade with the rest of your system, since it doesn't exactly link to any libraries (or have anything link to it), and furthermore, it is totally fine to not have a kernel installed (for example, chroots and containers use the host kernel) or install any other kernel like the linux-lts kernel, currently at version 4.19.80-1. So my advice is to either add the "linux" package to IgnorePkg until your issue is resolved, or switch to the linux-lts kernel for now. The next LTS kernel will skip from 4.19 to 5.4, and hopefully by that time this bug will be fixed... Then simply keep up to date as normal, while keeping an eye on the referenced bugzilla.freedesktop.org ticket. Of course, once you are keeping your system up to date while handling the kernel separately and specially, you should have no problem installing or updating any other package, in this case 'base'. Also note that 'base' does not depend on 'linux'. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base`, package - manual intervention required
On 10/11/19 6:10 PM, Daniel Moch via arch-general wrote: > I see in the archive[1] that these were deleted for not following the > submission guidelines[2]. I'm not sure how that's the case, unless the > logic is that since they merely bundle packages in Community that they > violate rule #1? > > If that's the logic, does that mean any meta packages in the AUR violate > the submission guidelines? > > Can someone clarify? I'm genuinely a little confused here ... > > [1] - > https://lists.archlinux.org/pipermail/aur-requests/2019-October/034288.html > [2] - https://wiki.archlinux.org/index.php/AUR_submission_guidelines Metapackages are a tough question, but in this case a metapackage to ease installation which requires one to use the AUR to get the metapackage seems to be quite pointless. Besides which, uploading a package as a reactive measure due to the lack of clarity with the former base group feels odd when people are working behind the scenes to try to figure out what a proper solution in the right place should look like. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/10/19 9:00 PM, Nero Claudius Drusus via arch-general wrote: > I've been following this discussion and can't see what the actual problem > is. I've installed a new system since the change and the installation doc's > have been updated appropriately. It still works. If you want extra packages > then add them, this, in my opinion, is what Arch is designed to do. I'm not > seeing why extra packages need to be installed based upon personal > preference. There's a community interest in something that helps you install high-profile packages such as: man-db man-pages less diffutils texinfo vi (required by the POSIX User Portability option, commonly assumed to be "the text editor you have even when you don't have anything else") It is also easy, once you have something for that, to also have it prompt you to install: linux (most people's default kernel) linux-firmware These are some pretty reasonable basic assumptions to make, so it's not crazy to think maybe users should be able to have some group of these packages to make sure they don't forget anything. It's especially not obvious that suddenly you need to install the `man` program as well as the core set of linux manpages (containing the 1p section and most of the good stuff in sections 2 & 3). But also texinfo, if you want to be able to read most documentation from GNU projects which don't ship proper manpages. At what point does updated wiki documentation become a giant list of "here's the things 99.% of people need but you'll have to install separately after reading some caveat and if you don't, then you will not even be able to type in 'man' to figure out your mistakes while offline"? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/10/19 7:01 AM, pete via arch-general wrote: > Never mind Ed Vi Assemblers yes all very fancyfull > hows about you just include joe far easier wordstar commands no mess just > worksthe very first thing i ever do install joe best editor of the lot . I have never heard of "joe". I have heard of many other text editors though. Off the top of my head: vi vim neovim vis ed emacs acme gedit pluma xed geany leafpad kate nano (gross) vscode atom sublime text notepad++ Windows Notepad Maybe if I even know Windows and macOS and *plan9* text editors before I know of this "joe", it needs to do better advertising. What are its features? Why would I want to use it? What merit does it have that we should recommend people use it? I have run pacman -Si joe, and it seems to be an editor. It's self-described as "Joe's own editor". So let me revise my question: who is joe, why do I care who he is, and what does his personal editor do for me? For that matter, if it carefully described as his own editor, am I allowed to use it? Alternatively, is it designed to be used by other people than its original intendee? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/10/19 7:14 AM, Jonathan Steel via arch-general wrote: > I think we should have created a "minimal" group rather than repurposing > the base one. Then as a separate issue to tackle, add "kernel" and "editor" > etc to the base group which would prompt the user to choose, or if > non-interactive install the first listed. Groups don't "depend" on things like virtual provides=(), you tag an actual .pkg.tar.xz with a group and then search for every pkgname that has that group. So I'm not sure what you are suggesting here. But regardless, we very explicitly wanted to *not* use the name "base" for recommendations, because it does not make clear that it is in fact recommendations. So the choices were either get rid of the base group and make a base package, or also get rid of the base group, but make a package named something entirely differently. There is no option on the table for there to continue to be a confusing group named "base". If you're really in love with groups and don't want to see a metapackage then once again we would still need to delete the base group in order to create a "minimal" group, and any group of recommendations would need to be named something like, oh, "base-extras". So, once again, you would not be able to `pacstrap /mnt base`. Some changes were always inevitable. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/7/19 12:02 AM, Marc Ranolfi via arch-general wrote: >> The `base` group has been replaced by a metapackage of the same name, we > advise users to install this package (`pacman -Syu base`), as it is > effectively mandatory from now on. > > Please, was this discussed somewhere? I want to know the details, and > gather what is needed to update the 'Installation guide' article in the > wiki. In particular, I want to understand why essential packages for new > installations, such as the kernel and a text editor, are not included > (actually I see the kernel is an optional dependency). Really, I wish we would do as I'd wanted and transfer the "essential packages" which aren't actually essential and were thus not included in base.. to a new *group* called "base-extras", which would reflect its status as being mere recommendations, while providing a convenient way to choose to interactively install them, and allowing the Installation Guide to transition from: pacstrap /mnt base to pacstrap /mnt base base-extras instead of becoming "and also decide whether you want the kernel, and also probably linux-firmware (but check whether your hardware needs firmware first), and oh, if you want a text editor, go install one of those too I guess, and in case you feel super surprised later when info and man don't work, you might want to install texinfo and man-db (and man-pages if you also want manpages) and a dozen other things that most people want even if they don't realize it". And now we need to cherry-pick tons of packages for the archiso, and we need to cherry-pick tons of packages into the installation guide, and there is nothing straightforward to tell anyone what to do today. So we've taken a step forward and a step back, and mostly weren't ready for it either way. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] `base` group replaced by mandatory `base` package - manual intervention required
On 10/8/19 2:20 PM, David C. Rankin wrote:
> On 10/06/2019 11:22 PM, Giancarlo Razzolini via arch-general wrote:
>> Yes, this was discussed over the years in several threads. The most recent
>> being [0].
>>
>> Lacking a kernel is mainly for container based environments. And some
>> superfluous
>> packages were also removed from the group, like an editor.
>>
>> The necessary changes to the installation guide were already made [1].
>
> All of this seems like a lot of unnecessary shuffling to what has been a
> reliable base install for the past decade. Why on earth no simply create a
> 'base-container' group to provide the install for those desiring an install to
> support containers and leave the traditional base group alone. The lack
> cryptsetup, device-mapper, dhcpcd, mdadm, netctl, s-nail, vi and which in base
> seems to leave a 'base' install very unusable.
Because this is not about containers. There are tons of things in the
old base group which I don't want installed on my heavyweight X11
desktop which is used for media consumption.
I don't need netct (because networkmanager is love), s-nail (unuseful in
practice) or vi (symlink to vim) as a baseline fact.
I don't need cryptsetup or device-mapper if I'm not opting into an
encrypted filesystem, but this does not matter as I cannot get rid of
either one due to systemd performing shared library links to
libcryptsetup.so and therefore also having a depends+=('cryptsetup')
I do not need mdadm or lvm2, because I don't use RAID or lvm, so why do
you think my system is unusable without it? Note: in practice, both are
required by libblockdev, which means if you use udisks2 you have both
installed anyway.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-general] Recent logwatch update may need a news item?
On 9/19/19 8:29 PM, Amish via arch-general wrote: > Thanks but why would one parse logs to log it back to logs? I'm not sure what this statement means, but there is no "parsing", and the only "logs" are the systemd ones. Just emailing the logs doesn't constitute re-logging it to a new log. > The default behaviour of earlier version of logwatch was to send email > to root. (via cron) The default behavior of earlier versions of the logwatch archlinux package, yes. What about the default behavior of logwatch itself? Also, like, the vast majority of system logs aren't automatically emailed to root by the software itself. I guess the vast majority of logs in a systemd-based distro aren't emailed at all (because unlike cron, systemd does not do this by default). > So I guess if the timer was meant to be drop in replacement for cron > then it should e-mail too. Who said it was supposed to be a drop-in replacement for cron? The impression I got from looking at https://bugs.archlinux.org/task/56357 is that the timer was supposed to be a "migration from cron installs to the upstream systemd service". I really don't see why you think archlinux should be opinionated and modify upstream service files. I hear your argument that the package should have a post_upgrade message. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Recent logwatch update may need a news item?
On September 19, 2019 1:00:26 PM EDT, Amish via arch-general wrote: > Hello, > > Recently logwatch package was updated. > > The cron file (from cron.daily) was removed and replaced with > systemd.timer. > > But logwatch.timer is not activated automatically, which means the > users > who use logwatch will stop getting daily "auditing" emails and may not > > realize this for some days that emails from logwatch have stopped > coming. > > This requires manual intervention to activate logwatch.timer. > > Since keeping an eye on logs is very important thing to do, this > should > be put as NEWS item. (in my opinion). Your opinion is all nice and well, but what's wrong with a package post_upgrade notice? NEWS items for breaking changes are done when the breaking change needs to be resolved in order to successfully execute Pacman and upgrade the package at all. > > Additionally, current logwatch.service calls "/usr/sbin/logwatch" > alone. > Which means by default it sends output to systemd journal. (whereas > cron > based timer used to send an email to root which could be an alias to > real email address) > > To preserve the existing behaviour, the ExecStart line should be > changed > to ExecStart=/usr/bin/logwatch --output mail" > > Even if this is not made a news item, this email is also sent to alert > > those users who use logwatch that they need to take following actions: > > 1) pacman -Syu > > 2) cat /usr/lib/systemd/system/logwatch.service.d/local.conf > [Service] > ExecStart= > ExecStart=/usr/bin/logwatch --output mail > > 3) systemctl daemon-reload > 4) systemctl --now enable logwatch.timer I guess it's entirely possible that users were logging without using mail at all. There are guides for generically forwarding systemd logs via email, though. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: PGP signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 6:27 PM, Xianwen Chen (陈贤文) via arch-general wrote: > For example, > > $ sudo pacrepairfile --uid --gid --mode --mtime > /usr/lib/tmpfiles.d/colord.conf > > outputs > > /usr/lib/tmpfiles.d/colord.conf: set uid to 0 > /usr/lib/tmpfiles.d/colord.conf: set gid to 0 > warning: /usr/lib/tmpfiles.d/colord.conf: unable to set permissions > (Operation not supported) > /usr/lib/tmpfiles.d/colord.conf: set modification time to 111829 > > What happened with pacrepairfile? Ah, now I remember that https://github.com/andrewgregory/pacutils/issues/32 is a thing. :) The --mode option has some issues. Perhaps try asking for a status update there? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 4:40 PM, Xianwen Chen (陈贤文) via arch-general wrote: > Dear Eli, > > Thank you! > > Is there a way to ask paccheck to list only files that need to be fixed? > > For example, if I run > > sudo paccheck --file-properties --quiet > > I get list of files with package information and error information, such as > > screen: '/usr/lib/tmpfiles.d/screen.conf' permission mismatch > (expected 644) > > Or maybe I need to write a regular expression to extract file name and > path from such an output myself? No, paccheck does not have an option to do this. You could try submitting a feature request for it. :) You can extract everything between the '' though, which I think should handle any filenames since packaged filenames can contain spaces or single quotes but not newlines, and the paccheck output doesn't contain any more single quotes after the quoted filename. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
to be seen. Well, sure, that is why it is just a check by default. :) But permissions are "generally" okay. And modification time is nearly meaningless as it doesn't have any effect on the working of the system in nearly all cases. Depending on the files in question and whether they are backup files, size or checksum mismatch is probably an issue (unless they are kernel depmod products, of course). But they can only ever occur when something modifies the file *after* pacman installs it, so there is really no automated way to check for this. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] [ Pacman -Syu ] Creating temporary files..., error: command failed to execute correctly
On 9/8/19 5:20 AM, Ralph Corderoy wrote: > Dear Xianwen, > >> After searching on-line, it seemed that similar problems were reported >> by other users of systemd. The fix is to set owner of / as root.root. >> I tried the solution and it worked! > > I'm glad you fixed it. / not being root:root is strange. You may wish > to > > sudo -i pacman -Qqkk > > to check for other odd permissions, etc., in case they too cause > problems later. Note, it seems normal for some packages to cause > grumbles from the above command. If a package is listed, I then do > > sudo -i pacman -Qkk atop > > to see more detail of the problem. Though unfortunately not enough > detail, i.e. > > warning: atop: /var/log/atop/dummy_after (Permissions mismatch) > > doesn't tell me what they should be. One has to grovel around in the > mtree file for that. > > $ zcat /var/lib/pacman/local/atop-*/mtree | > > grep '^./var/log/atop/dummy_after ' | > > fmt > ./var/log/atop/dummy_after time=1549485614.0 > size=0 md5digest=d41d8cd98f00b204e9800998ecf8427e > > sha256digest=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 > $ > > This entry doesn't have a ‘mode=...’ stating the desired permissions. > mtree(5) doesn't say so, but I think it defaults to 0644 for files based > on the other mode-less entries in that mtree file that don't cause > pacman to complain. > > Not every error means the file on disk must be changed, perhaps it's a > packaging problem, but it can be a useful aid. pacman -S pacutils && paccheck --file-properties -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Whatsapp group
On 8/14/19 1:25 AM, varshit bhat via arch-general wrote: > Hey,why not make telegram group official? > @archlinuxgroup I don't think many active members of the Arch community know what that group is. In fact, I am personally somewhat skeptical of Telegram in the same way I am skeptical about WhatsApp. (It may not be run by an unscrupulous social media company, but it is still a closed-source server model). What would making it "official" mean? Users are free to reach out to other users however they would like to personally agree to reach out. The forums and mailing lists we host on our own website are a special case, and the IRC and reddit communities exist because many users wanted them to. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Opening a document with unicode in path
On 8/2/19 1:24 PM, John Z. wrote: >> Could you verify that the encoding of the filepath is, in fact, UTF8? >> Filepaths in linux are free to be arbitrary bytes despite the locale >> settings. Most tools don't care, though I would expect the filepath to >> display incorrectly in the terminal and file browser if it were not UTF8. >> So it is probably a long shot but perhaps worth checking. > > Hi, thank you for the suggestion. I tried running your script, and all > filenames are decoded correctly, no exception was thrown (I also tried > without try/except just in case something else gets thrown) > > However, you might be onto something here because, interestingly enough: > while BASH prompt and autocompletition feature both decode the character > correctly, `ls` does not and outputs a sequence of escape codes: > > Proc'$'\303\251''dures > > instead of > > Procedures (where first 'e' is the unicode char, and has french accent) The ls command will by default escape the character into its numeric code if it thinks the character is invalid in your locale. I can get ls to print the same thing as you (using shell-escaped $'\303\251') *iff* I first export LC_ALL=C (which is not a UTF-8 locale and therefore cannot print unicode characters). This indicates something is wrong with your locale, because at the very least, your shell cannot parse the character correctly -- maybe neither can libreoffice. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Opening a document with unicode in path
On 8/2/19 8:59 AM, John Z. wrote: > Hi everyone, > there's a document on Dropbox, that has unicode character in its > path (french character). Trying to open this document with libre > office (Plasma is running) fails with 'file not found', and the path > shown with error clearly presents the path with that unicode > character replaced by '??' > > What I tried: > * copy the document in a path where there's no unicode - it opens > * copy the document using shell - it works > * copy the document using Dolphin (from Plasma) - it works > * check $LANG - its set to `en_CA.UTF8` > * search for 'libreoffice unicode path', 'archlinux unicode path' > and plethora of similar search terms - not much came through > > This makes me think the issue is actually with LibreOffice, but the > reason I ask here, and not in their forum, is that on another > computer running Ubuntu - this works without fail, so I'm fairly > certain the issue is in some local configuration. > > Could anyone shed some light on this, please, or at least point me > in some direction where I could look? Can you determine some steps that exactly reproduce the problem? Assuming that the problem should manifest when opening the file using /usr/bin/loffice /path/to/file, I tried creating a test file and opening it, and it worked: $ mkdir -p '/tmp/unicode paths are /' $ touch '/tmp/unicode paths are /testfile.txt' $ loffice '/tmp/unicode paths are /testfile.txt' $ I could successfully edit this file in libreoffice, save content, or reopen it. Tested with LANG=en_US.UTF-8 and the libreoffice-fresh package -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
