Re: [arch-dev-public] Chromium losing Sync support on March 15
On 1/26/21 6:23 PM, Konstantin Gizdov via arch-dev-public wrote: I am not sure how this would be taken, but I propose we not only remove it from the repos, but we clean the AUR of Chromium and Chrome too and we enforce no one uploads any more such variants. This, I believe, is the only way the message will be loud and clear to our users because people will have to really share Chrome PKGBUILDs on 3rd party platforms as if it were illegal. In the end, this is what Google wants, right!? We cannot distribute Chrome's binary nor can we build a functioning Chromium. They essentially want their software no where near our _dirty_ platform. I think we should abide. This is histrionics. I don't see why we should ban the proprietary google-chrome package, which is already somewhat inconvenient to use because of the AUR, over politics. Where is your respect for the rights of our users? We're not in the business of telling people they're not allowed to use the AUR for the express purpose which the AUR was created for. That's a REALLY hot take. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] hardlink in util-linux
On 2/17/21 6:18 AM, Christian Hesse via arch-dev-public wrote: > Hello everybody, > > upstream util-linux replaced the current implementation of hardlink (which we > do not ship) with Debian's [0]. For util-linux 2.37 I plan to package the > hardlink executable and set provides, conflicts and replaces on hardlink > package. Any objections? > > [0] > https://github.com/karelzak/util-linux/commit/2180ecc81b5f7635adbe5412010642e15fa212d3 This sounds like a great plan. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: Use x86_64-v2 architecture
On 3/2/21 7:54 PM, Allan McRae via arch-dev-public wrote: > On 2/3/21 9:51 pm, Allan McRae wrote: >> Hi all, >> >> A new RFC has been opened here: >> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 >> >> Summary: >> Make -march=x86_64-v2 the default for our packages. This assumes the >> following instruction sets which are essentially available on all but >> the oldest AMD CPUs: >> >> CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 >> >> Please visit the above link for discussion. > > I'm following this up with a more detailed explanation than in the RFC, > because this is really a discussion about the core of Arch Linux. > > The clear disadvantage of this proposal is that processors older than > ~2008 will no longer be supported. We have heard from people who run > Arch on these processors, because they will be affected. But that does > not mean theses are a high proportion. I suspect we caused more people > to not be able to run Arch when we dropped i686 (based purely on the > size of the immediate outrage...). > > What are the advantages? Optimization of binaries. > > It has been pointed out that glibc and some other packages do hardware > detection that allows the use of optimized routines for some functions, > so this limits benefits. Great for that software, but not all software > than can benefit does this. > > Also some packages already have variants provided with a -sse4 or -avx2 > suffix where there is a major benefit. But this is done on an as-wanted > basis, and is a maintenance burden. > > While the performance gains we will get are debatable in size, another > major benefit is power usage. I recompiled my entire system as a test > last year to something equivalent to x86_64-v3 (so more optimised than > the proposal) and saw a *substantial* increase in battery life on my > laptop under usual usage. So there are advantages beyond pure speed > improvements. > > > I think this discussion comes down to how Arch Linux wants to position > itself and its guiding philosophies. In the early days, the selling > points of Arch were rolling release, optimised binaries, and simple > packaging (including lack of splitting). > > We still do rolling release. But I'd venture that openSUSE Tumbleweed > does it in a more robust way these days. Our lack of package splitting > (e.g. including development headers in the package), does have > significant advantages still. However, we have lost our lead on > optimized binaries. > > When we provided i686, other distros were still doing i386 or maybe > i486. At that stage, Arch was rejecting older processors. RHEL have > announced they will use x86_64-v2 for EL9 [1]. I have not seen any > discussion of this, but you would assume Fedora would do it first. > Given SUSE was involved in the definition of the three new x86_64 > microarchitectures, I'd expect them to move there too. That would make > Tumbleweed very attractive over Arch (and I say that with a vested > interest in the Arch package manager...). > > Is Arch a distribution that supports processors that are more than a > decade old? There are dozens of other distros that do that too. Or do > we drop support for a small fraction of hardware in current use (as we > have done on previous occasions) and continue to push the boundaries of > a binary based Linux distribution? Are we a distribution that takes a > leap before other distros, or just another rolling release distro? I wonder, might this be an interesting time to reintroduce multiple architectures? We used to offer i686 and x86_64. Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right to -v4. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: Use x86_64-v2 architecture
On 3/2/21 8:10 PM, Allan McRae via arch-dev-public wrote: > On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote: >> I wonder, might this be an interesting time to reintroduce multiple >> architectures? >> >> We used to offer i686 and x86_64. >> >> Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right >> to -v4. >> > > That is a possibility that has been discussed over the years. It was > previously decided that we needed other architecture builds to be > automated, and thus automated package signing. This becomes a > possibility once we manage to sign databases (which will hit a decade of > pacman support in October!). I wasn't on the packaging team back when i686 was supported, so I don't know about the experience firsthand. But I thought it was just "run extra-*-build twice and commit the result"? Like i686 builds from a developer with an x86_64 laptop, this is something that should be doable for all architectures from one machine. Building the more advanced architectures might, for some people, require using build.archlinux.org (via offload-build), which come to think of it supports x86-64-v3 but not x86-64-v4... I'm aware of discussion about CPU architectures that are not x86 and which, by and large, members of the packaging team don't have hardware for. (RISC-V, aarch64) This is thoroughly blocked on the theory of autobuilding for practical reasons in ways that x86-64-v2 is not. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: Use x86_64-v2 architecture
On 3/2/21 9:12 PM, Allan McRae via arch-dev-public wrote: > On 3/3/21 11:56 am, Filipe Laíns wrote: >> On Wed, 2021-03-03 at 11:10 +1000, Allan McRae via arch-dev-public wrote: >>> On 3/3/21 11:03 am, Eli Schwartz via arch-dev-public wrote: >>>> I wonder, might this be an interesting time to reintroduce multiple >>>> architectures? >>>> >>>> We used to offer i686 and x86_64. >>>> >>>> Maybe now we could offer x86_64, x86_64-v2, and x86_64-v3. Or go right >>>> to -v4. >>>> >>> >>> That is a possibility that has been discussed over the years. It was >>> previously decided that we needed other architecture builds to be >>> automated, and thus automated package signing. This becomes a >>> possibility once we manage to sign databases (which will hit a decade of >>> pacman support in October!). >>> >>> Allan >> >> Is it possible to get pacman to allow us to enable multiple architectures at >> once and prioritize one of them? This way we could just do x86_64 and the >> maintainer could opt-in into x86_64-* if it makes sense for the package. >> >> This would not introduce new effort to maintainers and would solve the issue >> quite nicely IMO. >> > > No it is not possible in pacman (without abusing fall through when > failing to download a package from a server). Right, we could have some packages built for arch=(x86_64) but with optimizations and package them in a [community-optimized] repo or something. This seems complicated and doesn't handle conflicting filenames -- which is a serious problem for the server pool and archive. Usually clashes would be eliminated by keying off of the architecture; only one of each package per arch. This would not permit fallthrough though. pacman could, theoretically, learn to support multiple "Architecture"s in pacman.conf, e.g. configure it to support Architecture = x86_64-v2 x86_64 and accept both types of packages. This would be needed in order to support selectively optimizing packages while keeping the same pkgname. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Tracking different CPU architectures with pkgstats
On 3/7/21 8:40 AM, Pierre Schmitz via arch-dev-public wrote: > While I am at it, I'd like to also support different ARM architectures > provided by archlinuxarm.org (or maybe even i486/i686 by > archlinux32.org). There is a small catch though and the reason I am > asking for your opinion: While we will know how many users use which > architecture, all package usage data will be aggregated regardless of > architecture. This means for a given package we cannot tell how often > it is used on a specific architecture compared to others. I do not > think that this would matter for most packages though. Given we should anyways be building the entire distro for any officially supported architecture, I'd say it won't matter at all. I'd definitely be interested in pkgstats for architectures. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] ON HOLD - RFC: Use x86_64-v2 architecture
On 3/4/21 6:33 AM, Allan McRae via arch-dev-public wrote: > On 3/3/21 10:54 am, Allan McRae via arch-dev-public wrote: >> On 2/3/21 9:51 pm, Allan McRae wrote: >>> Hi all, >>> >>> A new RFC has been opened here: >>> https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/2 >>> >>> Summary: >>> Make -march=x86_64-v2 the default for our packages. This assumes the >>> following instruction sets which are essentially available on all but >>> the oldest AMD CPUs: >>> >>> CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3 >>> >>> Please visit the above link for discussion. > > Lets put discussion on this RFC on hold for a while. Clearly there is a > reasonable amount of objection to making x86-64-v2 the default. While > this mostly appears to be objection based on personal circumstances and > not on the basis of whether this change is good for the distro, I will > work within these limits. > > A lot of comments have suggested adding x86-64-v2 and -v3 as additional > architectures instead. I will revamp the the proposal to take that > approach. Though, to do this automated would require more work it may > be the push we need for a signing enclave to be set up. For the record -- the RFC has now been revamped. The new form of the proposal is to add a -v3 (skipping right over -v2) additional architecture. ``` Alternatives Considered --- Moving the baseline to x86-64-v2 was discussed, but the gains were not considered enough to justify removal of support for hardware without SSE4.2. ``` -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Killing python2 v3...v4...v5
On 3/15/21 2:10 PM, Morten Linderud via arch-dev-public wrote: > Yo! > > As people know python2 has been unsupported for a year and we current have > ~170 > python2 packages in our repositories. Currently the removal has been fairly > slow > and done a bit ad-hoc. There has been a todo list but the follow up to that > has > not really been great and I think it's reasonable for us to try and fix the > remaining packages to the best of our abilities. > > Thus I'm proposing a game plan! > > 1) Todo list for removal of all python2 checkdepends in packages For the record, I'm not really happy about this since I feel we should endeavor to test all software in the repos. I don't believe python2 should be an exception. I believe we can do this right, though. For example, yesterday you asked me directly about html5lib and its check dependency on the lxml, bs4, soupsieve build cycle dependency. I responded that I don't want to drop the testsuite entirely, however, lxml is an optional treebuilder for html5lib and we only have html5lib in the repos *anyway* due to being used in the leaf package "python2-pip". So, I removed the checkdepends on python2-lxml, excluded the lxml treebuilder tests from the check() function, and stopped advertising lxml support in python2-html5lib: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/python-html5lib&id=872eb6022921c71ef871bd9699f6353262f29b5c However, I did not drop python2-pytest-expect since I need it to test the functionality which pip uses. I would like to continue doing so... > 2) Remove free python2 packages > 3) Remove packages with python3 equivalents > 4) Remove unported and unsupported packages depending on python2 > > Clearly this is ambitious and there are going to be exceptions, but it would > be > great to have most of this work done within the next couple of months. > > The exceptions are largely going to be anything still using python2 for their > build system dependencies. This is a fine compromise as this should leave us > with a minimal set of packages to take care of. > > Rest of the problematic packages can be found on a handy list with what fedora > is working on: https://fedora.portingdb.xyz/ > > If there are no objections I'll start preparing the needed todo lists and > figure > out the uneeded python2 packages. Should probably update the long-standing > python2 removal todo as well. > > https://archlinux.org/todo/conversion-of-programs-that-use-python-2-to-python-3/ > > > Cheers! > -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_signature Description: OpenPGP digital signature
[arch-dev-public] On holiday for the next 2 weeks
It's that time of year again, the Passover holiday, so I'll be irregularly available or simply offline for days at a time until April 6 or thereabouts. I'll try to catch up with messages when I get a chance (expect delays!), but I'll be getting very little actual work done. Please feel free to bump my packages for me. -- Eli Schwartz Bug Wrangler and Trusted User
