[arch-general] https://git.archlinux.org/svntogit obsolete?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I was surprised to find git.archlinux.org/svntogit/packages.git/ and git.archlinux.org/svntogit/community.git/ being no longer updated since a few days. I know, there was a github mirror of the repositories set up some time ago - did I miss some deprecation notice for the old locations or is this some oversight on the arch end? regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl/ffMIACgkQCu7JB1Xa e1qskg//T0HkTdj33ygNCpDNwvDf2H6V1zOBkjadlHrXph4/WkQIyYa7QJxmWXfV d0CWioelIJM4qkBpXrwTa4xMvowW7HLgvpUnCfnXSSaiCODEbJDXC/b0OokHSS9c K+9rGdMgVwfmsMevc/k919ifzmNIUkmX3tOd4lRc1CO6A2EHxFELndY3MbBhpz12 gP599BPvopC+AlYg0MEu1l0/1wAq5p0zSJvneyh2R8LIo8RW/8N7JWnmt0CJf8sM iNiBHvj7byk1Y8uXghibaN9LqLAtRTodhb++Fm5NKdHmlVAnGxrdA3aKlYJYYXsL Q/OYBSTwuhNvxXJnewLtErWjcVu7IL29gPX2Hh7Yhyf+XHScond/Z6WWza3dBYMx rEC9sknS9aSQeuvJqAyfq0mCDQJxbDFAs2p2zh0LG65pbY04yZstmDo/Al+xZV5D wwqedpiTAUVI23m9IePMfxEUnWuRaF5GYeJIa/EFmYn5OXPWMuUO/Y5p2G54QLvX Zwbxu08NDzf+jznhVw2CiP/V7SDMtdLa0hMblvD63z+ywZql0KGIjhiyA9EtXMZm NGQexY5yHyb2R5gKx8e4a7o8ZRJP/n/85laRj3dBYA1ulr5Sp7FCNdYFOLs9xz64 IygVzAJG6Og4kDD7trPl++OwLzaKZ//Qodm3w/+egG3HY75/KvM= =vYL+ -END PGP SIGNATURE-
Re: [arch-general] netcl leaves network down until reenable performed - do we need note?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi list, I got hit by this, too. On Mon, 17 Aug 2020, Eli Schwartz via arch-general wrote: On 8/17/20 5:25 PM, David C. Rankin wrote: 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. That's true, however, when this warning first appeared, `netctl reenable my-profile` did not help - same was true several days later (probably also weeks/months). So I forgot about the warning (I'm not keen to put `for profile in $list; do netctl reenable $profile; done` into my common update routine for all my arch boxes). 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. In my opinion, a news post would have been appropriate. But now it's "too late" (see below). Hopefully anyone with remotely adminned boxes caught this while monitoring journalctl logs. Logs were unhelpful at that time, see above. 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. Additionally, people on the list might catch this issue in advance (if they don't update too often and have not yet been hit by this issue). This makes a news post obsolete, now, I believe. 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. I think, it's not arch's way to do such things. Arch rather says "your config is broken/old, run `xyz` to fix it" than simply running `xyz`. -- Eli Schwartz Bug Wrangler and Trusted User regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl87ZzQACgkQCu7JB1Xa e1qq7w/+KHd/vyL9AloIgirCeEcYf/+JxcCOngmROoxbM/Gs3rtxynewpwqV6iCi VJGIlrH5Xl2/NasKONRQuzNyGD0qqIMMRbAiNOZq3r37RAb8vmWmRxJmY5rkymO7 yoG4ox4HSgfeTyCvQhUnMZWE8Qm7INjcI/nHvs//wIwqB5ppeLkkFLHK9LCWBpaF +dkKP5vrsvjrD9785RjjMg46iHDCJ3AEAPuZmWes7IgUR161MD7Ujf07YMDfit8u 1SrdtxsncPSR0OX/m4DKC31tBP5WjS4kGL61NjUfQm354YtkjhyULQ7ecobRNBqA xQ4i6nLpbbZJSx38S0jfOgsAqKxM5HV6pFXRUR1GTT6a0MTxXG9bERmVm6oaFQeN 9cm3b4MbeBDVXp5x7MI2VGlG2mmNaIxZWpMKtUufQwBOxSkDSp5rifqy+NUgPhLX H/WcdK8pCQfIVfiopENVA9aNrb25/ST79io0KfUNmON3HHEnCWaJGHmCFMB/yOe7 2frLccn6TP17KkSSL5cJev5tpB+epH9k3BUxln7BT9ZDGVNJwbhlksaKXWncj8Hg OEvt6vqHCuswwvcrAvTJwDeCVtQRU4dt3cqSqCHuJjKzNg6egE1gU9KOxvFkZE0T 5dNq9DrcixQoXbG59DhNsOkM8b186HvvXOxTVBJvsFwS46Nnn4g= =/I9c -END PGP SIGNATURE-
Re: [arch-general] announce libraries in provides=()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, 16 May 2019, Andy Pieters wrote: On Thu, May 16, 2019 at 3:23 PM mike lojkovic via arch-general < arch-general@archlinux.org> wrote: Suggesting pacman add some portage style features for dependency resolution and packaging? Modifying packages on a local system to fix bugs caused by versions of packages? Arch Linux has always made it clear that partial upgrades are unsupported. I have had to do some hair-raising things to recover some systems after doing partial upgrades, but this perhaps may make all of our lives a bit easier. Even if their official stance on partial upgrades remains, it would at least a more sane safeguard against ending up in a system that can only be recovered by the guruest of gurus. (e.g. you upgraded glibc and nothing works any more, or you've broken pacman,...) Hi, don't get me wrong, I'm not proposing to add versioned dependencies on libraries to official arch packages, but to add the respective "provides" entries, so _unofficial_ packages can have versioned dependencies if they want. What does "partial upgrade" mean in the context of a package compiled by the user? regards, Erich -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAlzecZ8ACgkQCu7JB1Xa e1p5Pg/7BsXOncdq8fP4pU83UXh9dgYkXEI0jfw7/A8pTq1I6h/l827owf6QNG6F ynNvVKDrIGg1z2n8pf5D/qBnHsIGg34ENVrknuU5RU9Uu8uHgGg88lkFPHS3eU4H VLwzzKC20l8+iDQIroNhcDGL+cycgolxpp6sxgj42mxOxdh3X8TZYQPBagj6e3RC Og0GOVLI9TYF3hPbqHiHgQBlFdGjtK7tTNhQThAGsZc5I5dWAYxAtg1H35z5Zjuh +RWvzMPHg3p6/gR6lo0K8BtTacPJiBSRBB7FOXGykV2PTojKGJuSVmB3CHs4FI4r u3gf5/uP++YgOIYOxBZsbrpJOHloMqnAwBZGTOCx9QEgM6QyNxMAs4mJDPlZsU+h Q4ECvoiDFuoqfJkJUFW4oIzy6twNvF/PszYR9nG9uCiH0+Rse87cdwUATIWpHIKe PgW+EZr/scVt8fBaic2+xULoHCnTnj1C8PhxZTR+o40X+aw+bbZo2RDu8ok/4HJF AyrVC+KctPtYmI2fXDp7AJR0yiCnqKTbUAEyIT6eQU3N57iF0+pJjJHuc6qFSbRc 4+jaESDlrApBagcxp0cfWCEn2bo43gTuaaaiXEiSJc/oRaWGwEvG2Iw7vmZABtHm i6D3yo7s9lx3iq/eI/2+qJAoO51y+qUuymqnxuJuNIdFrxo2v7k= =8QaE -END PGP SIGNATURE-
[arch-general] announce libraries in provides=()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
I would like to encourage adding provided libraries of a package to its
"provides=()" array in the PKGBUILD.
Some background:
Updating the system libraries may break manually compiled packages. Having
the version of the system libraries fixed in the dependencies of the
manually compiled package, this could be avoided, because then pacman
would refuse to replace the system library.
The current behaviour can be annoying if the manually compiled package is
vital (e.g. a mail server), requires some time for compilation and/or
fails to build for unrelated reasons.
If the libraries are added to the provides array, makepkg will
automatically version those dependencies.
libvorbis, for example has
provides=('libvorbis.so' 'libvorbisenc.so' 'libvorbisfile.so')
in the PKGBUILD which becomes
Provides: libvorbis.so=0-64 libvorbisenc.so=2-64 libvorbisfile.so=3-64
in the package.
This way, external packages can pick up versioned dependencies on the
library by using "depends=()".
Since my proposal[1] got denied for a single package, I currently have a
horrible hack in place which manually adds depends= entries in the
package() function looking at the compiled binaries with objdump. Because
I can only add dependencies based on the $pkgver of the package, but not
on the soname version of the library, I have to recompile for each version
change - not only the ones which actually change soname. The only current
alternative would be to manually build the required libraries, too (with
the provides=() entries added) - which is obviously also a bad idea.
Can we please have a todo list of packages that provide libraries in
/usr/lib but not announce them in the metadata?
Or should we enable makepkg to automatically search through the library
directory? (Probably not a good idea, as there might be differing
locations, libraries which should deliberately not be announced, etc. ...)
Or is my approach flawed from the beginning? How should I else circumvent
breaking the linking?
regards
Erich Eckner
1] https://bugs.archlinux.org/task/61018
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAlzcCZAACgkQCu7JB1Xa
e1r7Ag/7Ba4iTOHQ3r7qa9h1b9A+h9BGHlZ3lw4CYYR/hxI9lFWGDpL50KQot0Or
FUs/07F4mdQsiwHWEgb9epQFG3EQ3Uxdj0fUjdOVTVgKR9Qr0Tn2qxq4dlfvU0LD
IGIEc09xqEsvhNCgpGz0+Lr2P18JCadpTSn9RKELcYwNGG8IV+uThE6ovMH3BS51
DfRv4ToSD23BV+tmsBP4eFWwK3Io87R2qzgcw0ulJAqG2BA0UkNXU3rM7SKogXT2
uBeU7jTvlMtWIPcQ+pUCwyK+4PUwGrFrhVp2/s7pY/UA+Ve4S0asXLCc9YQqq8Ri
ppByDnNaT4YM34aw67kgIOuKYElzYyoDVsmrbH1sHeAYZuSOG3ibmS0+gr0gLQCr
U83E27SO+K60DxgNTtYcUdfnryCZbcqp+kDJmWh5MtRdwyBXajwSQasy+SU2ZYuR
fvdAD7/8Q8KFniV4AIVehIEjGVhbavXqrc6zGC7UqonhzVFi9qZ9UoxPUomqzHAQ
pFSHABPyL4RSH6IfLO28U3JKeBVxC9RyOwl+eqaPjWwmo6c0vlxyzIMdH9g83hnZ
innbdlKnSFSNbV6kG+FqkuUYxFlR2lc0VicBVCh5ObpvLE8MscUP0ns+xxBxQW2c
N4Xj6hGS8d6VtyDutf3E8zh2/rf+/jXuIkliZ/X3cei7eYAserA=
=nrCB
-END PGP SIGNATURE-
