Re: [arch-dev-public] Add active Python versions to the repos
On 11/22/20 10:05 AM, Filipe Laíns wrote: > On Sat, 2020-11-21 at 20:24 -0500, Eli Schwartz via arch-dev-public wrote: >> Your analysis is correct, it is indeed hell. I'm not sure why that is an >> argument in favor of doing even more of it though. >> >> Now, if you were proposing to get rid of some of this, I could get >> behind that. > > It was not an analysis, "hell" was an used here as an idiom. https://i.imgur.com/axJmn.gif You were unintentionally accurate. >>> even Python. >> >> I don't know if maybe you've missed the fact that we've spent like a >> year now aggressively upgrading or removing leaf packages depending on >> python2 in search of that glorious Promised Future where we can finally >> remove the python2 package itself? > > I did not miss that. I absolutely want to see the python2 modules removed, not > _necessarily_ the python2 interpreter. Now I'm starting to see part of the reason why people are having a difference of opinions here. I think I probably speak for a bunch of people when I say I'd like to see the interpreter dropped due to not being needed by any packages *and* being an end of life interpreter. The interpreter is only useful inasmuch as people use it to run software, so if we don't have any... I expect by the time we finally remove all reverse dependencies for it, the gap between the python2 EOL and its removal from the distro will be quite a bit biger than it currently is. >> And we're doing that even for a major incompatible release that most >> people argue is actually a different language. >> >> I'm not sure how this suddenly became an argument to package a ton of >> point releases that aren't even incompatible. > > Except they are... Python does not follow semver, only patch releases are > supposed to be compatible. They do try to keep breakage to a minimum, but it > definitely exists. One very obvious example is the introduction of "async" and > "await" as reserved keywords. There are a bunch of other backwards > incompatible > changes, so yes, they are incompatible releases, to the point you could call > them different languages. This is the first time I ever heard anyone describe "backwards incompatible changes means it is now a different programming language". I had backwards incompatible changes in a patchlevel bugfix in the python 3.8.x release line causing immediate traceback and SystemExit on a program's startup, does that mean every bugfix is now a different programming language? (I mean this quite literally. Python bugfixed a function not working as expected under certain situations. The program it broke was working around the failure by manually doing $thing, the traceback happened when you try to do $thing twice.) >>> I don't think having people opening bugs because they are >>> deliberately using an older version of Python is a big problem. It >>> hasn't been for any of the other languages, I don't think it will be >>> here. >>> I think this is an hypothetical that doesn't really materialize into >>> reality. >> >> You're proposing something far beyond the scope of what we do for other >> languages, and ignoring that for other languages we only do it if driven >> to in desperation because another official repository package depends on it. >> >> We don't introduce leaf packages of ancient versions of currently >> packaged interpreters just for fun. I don't even think anyone else does >> that either. > > That was not of the point of me bringing up other languages. The whole point > of > me bringing up other languages was to show that Andreas' concern is unlikely > to > materialize into reality. You think no one reports bugs for python-* packages that we should provide the python2 version? I promise you, you're wrong. I've closed those bugs, so I know they exist. You specifically brought up Java and Javascript, languages where each application is forced to vendor their entire dependency list rather than using system modules. For this reason, people don't report the kind of bugs Andreas is concerned about for Java/nodejs... So I assumed you could not possibly be talking about Andreas' concern, and I responded somewhat tangentially myself. We can, of course, talk about Andreas' concern, but given I've now submitted the authoritative facts on the matter, I'm not sure what else there is to say. It does indisputably happen right now. The logical inference is, it will happen *more*, if we add more runtimes for people to submit bugtracker tickets for. >> You want to package old versions of the python3 interpreter "but not >> modules", because "people would like to use it for tox". > > People can use it to
Re: [arch-dev-public] Split openssl package
On 11/21/20 4:52 AM, Pierre Schmitz wrote: > Hi all, > > there is a new set of openssl packages in testing that are split into > openssl, openssl-doc and openssl-perl. See > https://bugs.archlinux.org/task/54887 > > As most users just need the library the perl dependency can be > dropped. Summing up: > > Before: > openssl: depends on Perl; size: 3.6 MiB (7.31 MiB) > > After: > openssl: depends just on glibc; size: 1.78 MiB (5.49 MiB) > openssl-perl: depends on Perl > openssl-doc: size: 1.82 MiB I wasn't going to mention this, originally, because even though I don't *like* splitting openssl into openssl-doc to remove 1/4 of a 7mb package (we don't generally split out -doc packages unless the size is noticeable enough to actually impact users, which this isn't IMHO, and man 5 pacman.conf contains "NoExtract" for a reason), this is ultimately a maintainer judgment call. This was before I realized, in addition to moving a bunch of section 3 developer-oriented manpages, you also moved the section 1 manpages documenting the end-user command-line tool /usr/bin/openssl and the section 5 manpages documenting the end-user configuration file format. This is entirely wrong, and if you are going to split out the API docs in usr/share/man/man3 it MUST be *only* the API docs in the man3/ directory, not the entire set of manual pages. > > We actually talked about this at ArchConf last year. Splitting the > package was the easy part, but dropping the Perl dependency means that > any package up the tree that depends on openssl needs to be checked if > it actually needs Perl itself. Thanks to everybody who did the hard > work here! > > PS: Do you think we should post a news item about this change? Most > people won't need to worry about this, but those few who need the perl > scripts need to install the separate package. > > Greetings, > > Pierre > -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_0x84818A6819AF4A9B.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Split openssl package
On 11/21/20 4:52 AM, Pierre Schmitz wrote: > Hi all, > > there is a new set of openssl packages in testing that are split into > openssl, openssl-doc and openssl-perl. See > https://bugs.archlinux.org/task/54887 As I mentioned there, I don't really see the need to make a split package just for 25kb of optional scripts that can just use optdepends. "I tendo o lean towards a separate package instead of using optdepends as it is more explicit and you do not end up with partly invalid package." Do you then propose Arch should switch policies and start using split packages everywhere instead of our usual optdepends? Not sure what to think here. This feels inconsistent. > As most users just need the library the perl dependency can be > dropped. Summing up: > > Before: > openssl: depends on Perl; size: 3.6 MiB (7.31 MiB) > > After: > openssl: depends just on glibc; size: 1.78 MiB (5.49 MiB) > openssl-perl: depends on Perl > openssl-doc: size: 1.82 MiB > > We actually talked about this at ArchConf last year. Splitting the > package was the easy part, but dropping the Perl dependency means that > any package up the tree that depends on openssl needs to be checked if > it actually needs Perl itself. Thanks to everybody who did the hard > work here! > > PS: Do you think we should post a news item about this change? Most > people won't need to worry about this, but those few who need the perl > scripts need to install the separate package. I don't see any need for a news post to tell people that a script no one uses comes in a different package. If you did want to message this to people, it doesn't require manual intervention so a post_upgrade message is perfectly suitable. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_0x84818A6819AF4A9B.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Add active Python versions to the repos
On 11/21/20 11:58 AM, Filipe Laíns via arch-dev-public wrote: > pyenv forces users to compile the Python interpreter themselves, which > can take a long time with --enable-optimizations. > None of the user repos available builds with optimizations, or has > signed packages AFAIK. Of course they could in the future, but I think > having the packages in the repos is much better in terms of security > and usability. I run one of the user which provides these packages and > I don't see myself fixing any of the issues I pointed out due to > technical limitations. Incidentally... if you don't see yourself fixing the --enable-optimizations or gpg --detach-sign problem for your own builds, I'm morbidly curious as to the technical limitations and would like to know why you think these technical limitations will vanish once you're uploading them to repos.archlinux.org specifically. -- Eli Schwartz Bug Wrangler and Trusted User OpenPGP_0x84818A6819AF4A9B.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [arch-dev-public] Add active Python versions to the repos
On 11/21/20 11:59 AM, Filipe Laíns via arch-dev-public wrote:
> On Sat, 2020-11-21 at 16:58 +0100, Andreas Radke via arch-dev-public
> wrote:
>> Am Sat, 21 Nov 2020 14:34:24 +
>> schrieb Filipe Laíns via arch-dev-public
>> :
>>
>>
>>> Does anyone have any big issue with this? What are your thoughts?
>>>
>>> [1] https://www.python.org/downloads/
>>>
>>> Cheers,
>>> Filipe Laíns
>>
>> -1
>>
>> Arch is yours. Whoever needs more and older releases on the system -
>> just do it yourself! In the past we said "use abs and AUR - Arch is
>> the base to make it your own".
>
> This argument can be used to deny adding any package to the repos. You
> need this library, tool, etc.? Just add it yourself.
>
> Why are we packaging software that is used by far less people but we
> can't package these Python interpreters which are being actively missed
> by people?
>
>> I don't want to see users raising bugs that something doesn't work
>> with an older version of python. And I don't want to see these
>> requests
>> pop up every now and then to add even more stuff in different
>> versions.
>
> We already have multiple versions of Java, Ruby, Javascript, etc. hell,
Your analysis is correct, it is indeed hell. I'm not sure why that is an
argument in favor of doing even more of it though.
Now, if you were proposing to get rid of some of this, I could get
behind that.
> even Python.
I don't know if maybe you've missed the fact that we've spent like a
year now aggressively upgrading or removing leaf packages depending on
python2 in search of that glorious Promised Future where we can finally
remove the python2 package itself?
And we're doing that even for a major incompatible release that most
people argue is actually a different language.
I'm not sure how this suddenly became an argument to package a ton of
point releases that aren't even incompatible.
> I don't think having people opening bugs because they are
> deliberately using an older version of Python is a big problem. It
> hasn't been for any of the other languages, I don't think it will be
> here.
> I think this is an hypothetical that doesn't really materialize into
> reality.
You're proposing something far beyond the scope of what we do for other
languages, and ignoring that for other languages we only do it if driven
to in desperation because another official repository package depends on it.
We don't introduce leaf packages of ancient versions of currently
packaged interpreters just for fun. I don't even think anyone else does
that either.
>> It's sad enough we still have python2 and gtk2 around. To have gcc9
>> around and other duplicates is not what I want to see growing in
>> Arch.
>
> What you call sad I call a bad UX. Why do we need to force users to
> compile active releases of the Python interpreters themselves, which
> can take a long time if they are building with optimization, or to
> resort to pre-built repos with much lower security standards than us,
> when there are people willing to maintain them?
>
> I can't understand how it's sad to help out users by not forcing them
> to resort the sort of things I mentioned above, as long as we are not
> struggling to do so. I like helping people, that's why I am a packager,
> that is the opposite of sad for me, so I really can't understand this.
I have... no idea what the problem is supposed to be here? I'm
desperately trying to understand what the actual point of your proposal is.
You want to package old versions of the python3 interpreter "but not
modules", because "people would like to use it for tox".
Old versions of stuff that people need for who knows what weird reason
is *the textbook reason* why the AUR exists. How long it takes to
compile stuff in the AUR is not our problem, and we don't have a
rationale to upload gcc-{4,5,6,7,8,9} because actual users need to use a
lot of diverse compilers "to test that it still works on really old
compilers".
Likewise, if people want to test support for old versions of python3,
they have options which don't involve uploading trash into [community].
- Do what normal people do, and build AUR packages they need
- Ask FFY00 to provide signed repos
- Use travis CI, which doesn't use distro packages but provides a
diverse set of hand-compiled python versions, which is apparently some
kind of gold standard for doing regression testing on lots of
different python releases ;)
- Use pyenv
Apparently none of these are viable options in your mind, and the most
Arch-like of them, option #1 "use the AUR" you believe to be problematic
because it takes a long time to build with optimizations... even though
you yourself said those packages don't enable optimizations and don't
take a long time???
(If you're using python-$old exclusively for regression tests in tox,
you don't need a super optimized version.)
>> I don't want to see our distribution transformed into another Debian.
>
> That is not what is happening.
Yeah, even Debian doesn't do this.
Re: [arch-dev-public] News draft: Accessibility features added to installation media
On 10/31/20 2:52 PM, David Runge wrote: > Hey all, > > below is the news item I would like to post once the installation medium > is released some time tomorrow: > > ``` > We are very happy to announce that accessibility features have been > added to our installation medium with [archiso > v49](https://gitlab.archlinux.org/archlinux/archiso/-/tags/v49). From > release 2020.11.01 onwards these are available via the 2nd boot loader > menu item. > > Many thanks go to Alexander Epaneshnikov who integrated the features > from the [TalkinArch](https://wiki.archlinux.org/index.php/TalkingArch) typo: missing "g" in the link text > project into archiso's releng profile, which is used for creating the > installation medium. > > Note: The bootloader timeouts have been set to 15s to allow blind users > to select the menu item as the bootloaders themselves do not offer > accessibility features. > The timeout is stopped as soon as e.g. an arrow key is pressed. > ``` > > If you have improvement suggestions, please let me know! > > Best, > David > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] archiso v49 with new features
On 10/30/20 1:14 PM, David Runge wrote: > Apart from that I thought it might be worthwhile to write a news item > about it after the next ISO has been released and share the above two > changes on the website. What do you think? Great work on the accessibility changes to help make Arch easier to use for people with disabilities! A news item would be fantastic. (As for deprecating build.sh I don't really think that is important news for Arch, as it is really just a developer change for people building ISO images. I guess if you're writing a news post anyway, it is an opportunity to add a footnote.) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] rfc: reflector and providing pacman-mirrorlist
On 10/18/20 7:01 PM, Xyne wrote: > Hi all, > > There's an open ticket to have the reflector package provide > "pacman-mirrorlist" so that users can remove the latter: > https://bugs.archlinux.org/task/67653#comment193375 > > The problem is that the package does not include a mirrorlist and it > will only create one if the user starts the provided service, which > is entirely optional (I do not use it, for example). The dependency > is thus not satisfied without user intervention. > > I'm inclined to leave it as is (no provides) rather than risk broken > pacman dependencies because a user forgot to run the service, but I'm > still weighing the pros and cons. Does anyone here have an opinion or > a suggestion of how to handle this elegantly? $ pacman -Qi nomirrorlist Description : Dummy package to replace pacman-mirrorlist Provides: pacman-mirrorlist Depends On : pacman reflector Conflicts With : pacman-mirrorlist Replaces: pacman-mirrorlist I have a dedicated personal package to force resolution to it rather than the official mirrorlist; I then have the freedom to make it generate a mirrorlist in post_install, or at least provide the file itself as a backup file with a randomly chosen mirror that at least works. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Autumn extra cleaning
On 10/5/20 1:16 AM, Sven-Hendrik Haase via arch-dev-public wrote: > Hey everyone, > > It was suggested as part of this year's spring cleanup of [community] > that we should be have a cleanup in [core]/[extra] and move packages > downwards into [community]. > > This round only concerns [extra] packages. > > Devs that want the packages in [extra], please adopt packages, and TUs > can notify which packages they are interested to maintain in [community] > > Orphaned packages in [extra]: > > a2ps > aalib > abook > adwaita-icon-theme (Jan can you just take this?) > antlr2 > antlr4 > arch-install-scripts Formerly dreisner's package. I'm upstream for this. One could, however, ask if this fairly central bit of software should be relegated to community? If not, I could maintain it... > asp > aspell-es > bzflag > c-ares > chromaprint > cln > cmark > convertlit > cvs > cvsps > davfs2 > dcraw > enca > expac I'd maintain it... > fakechroot > farstream > fastjar > font-bh-ttf > freetds > fvwm > geeqie > giblib > gifsicle > gnugo > gperftools > graphene > gsfonts > gstreamer > gtksourceview4 > gts > gupnp-igd > gv > hddtemp > hunspell-fr > hunspell-it > hunspell-ro > hyphen-fr > hyphen-it > icewm > id3lib > ifplugd > ispell > java-activation-gnu > java-bcel > java-commons-net1 > java-gnumail > java-hamcrest > java-inetlib > java-jdepend > java-jline > java-jsch > java-resolver > java-rhino > joe > jpegexiforient > junit > leveldb > libatomic_ops > libkate > liblqr > libmilter > libmng > libnet > libnice > libnma > libofa > libots > libpano13 > libspiro > libstroke > libtiger > libtommath > libuninameslist > libusb-compat > lua51 > lua52 > m17n-db > mercurial > mtools > munin > munin-node > mysql-python > mythes-fr > mythes-it > mythes-ro > nawk > netpbm > npapi-sdk > nss-mdns > ocamlbuild > opencore-amr > perl-http-daemon > pkgfile (I suggest we just drop this in favor of pacman -F) pkgfile is optimized and better, faster, and more featureful than pacman -F, so it's quite worth keeping and I don't intend to stop using it any time soon. I'd be happy to maintain the package. > potrace > psiconv > python2-cairo > python2-numpy > python2-ordered-set > python2-setuptools > rcs > rhino > rhino-javadoc > screen > shared-color-targets > snappy > snarf > swt > tcl > telepathy-farstream > telepathy-idle > telepathy-salut > time > tinycdb > tk > ttf-junicode > ttf-linux-libertine > uim > usbmuxd > vcdimager > vim-spell (and its 50 split packages) > w3c-mathml2 > x11-ssh-askpass > x11vnc > xalan-java > xerces2-java > xine-lib > xine-ui > xmltoman > xorg-font-util > xorg-xfontsel > xorg-xlsfonts > xournalpp > yajl > > Thanks to Morten for ghostwriting this. ;) > > Cheers, > Sven > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Bug tracker migration
On 8/29/20 7:02 PM, Frederik Schwan via arch-dev-public wrote: > Hi folks, > I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab > instance. This decision did not take place with input from the people affected by such a move, who may or may not want to use Gitlab. Can you clarify for the rest of us, which parties actually *did* have input, and *where* this took place? Announcing it as a foregone conclusion seems premature. We also don't know how it's supposed to work given gitlab is a git forge, and most things aren't actually git repos as of now. Some things never will be because they aren't even code. Furthermore it's straight-up a non-starter until such time as users interested in reporting bugs can open up accounts with which to open bugs. Currently https://gitlab.archlinux.org is closed to registration and relies on SSO accounts exclusive to internal team members... > TLDR: > - Bug wrangling day on the 13th of September; see 1) > - Flyspray will be read-only after we rewrite the Archweb URLs > - new bug tracker -> Gitlab > > > 1) I'd like to hold a bug wrangling day, where our goal is to close as many > bugs as possible. >Any TU, Reporter and bug wrangler is invited to help out :) Unfortunately > I can't offer any cookies that day :/ > >Rules: > a) Bug with no reply for at least 6 months which has been submitted for > a different version than the current one in > the repos shall be closed with a message that a reopen request may be > filled if this issue is still present. Bug wrangling is always a good thing, we don't need to limit it to September 13, but the usual approach we take is to investigate old bugs and close them with "I cannot reproduce the bug, it seems to be fixed", rather than closing them with "we do not care about bugs that weren't fixed in six months". We *have* had other bug days, you know. They weren't "lets close as many bugs as possible", they were "let's dig into old bugs and figure out what to do about them, triage them if possible, hunt down resolutions, or verify if they've been fixed". I am vehemently opposed to the concept of "stale bots", which are very popular on github and gitlab but which are merely the sign of a developer team that cares more about looking like there aren't so many bugs than actually fixing them. > b) Any infrastructure ticket shall not be touched. This will be handled > by $DevOps. Also tickets opened against things other than packages, for instance the *entire* Pacman and Aurweb projects. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Removing maintainer/contributor lines from PKGBUILDs
On 8/25/20 3:58 PM, Evangelos Foutras via arch-dev-public wrote: > I am not sure these serve any purpose. The maintainer line duplicates > information available from the archweb or aur interfaces and could > also be outdated. The contributor lines are mostly redundant with svn > or git history, can take up several lines in the PKGBUILD and can > become irrelevant after significant refactoring. > > What are your thoughts on dropping all these seemingly unnecessary > lines from our official PKGBUILDs? Anyone feel strongly about keeping > them (and why)? If they ever leave the git repository, they do become somewhat useful... "someday" it would be nice for pacman/repo-add to support "source repositories" containing `makepkg --source` artifacts. We also have a bunch of these in https://sources.archlinux.org/sources/ Certain downstream distros (Parabola, ALARM) sync the PKGBUILDs and check them into their own version control, with modifications. There's no git log there to point at the maintainers/contributors of the parts that were synced from us. As Lukas mentioned, your points only really touch on the Maintainer line, the Contributor lines aren't at all covered due to not actually being recorded in svn or git history at all: - svn *can't* store it - people in the AUR are as likely to pastebin a PKGBUILD update (with their name added to the Contributor: lines) as to submit a git patch - official repos <--> AUR don't have any links and probably will not even without svn as a factor, since they have different requirements like .SRCINFO I don't know whether it's actually a matter of care and concern to be able to tell, historically, who the old maintainer was, but I wouldn't actually assume that "the person who committed the change is the maintainer", it's often non-maintainer updates for various reasons. tl;dr The information cannot be replaced and is not redundant. But it might be that no one actually cares about the information. On the other hand, is it bothersome to have it there anyway? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [aur-general] AUR migration
On 7/28/20 4:13 PM, Gaetan Bisson via arch-dev-public wrote: > [2020-07-28 13:46:23 +0100] Filipe Laíns: >> If one machine gets compromised the keys are also compromised. > > I never suggested to use the same keys for multiple servers. > > Only that if luna's main purpose is to provide a service and this > service is moved to a different host, it makes sense to move the SSH > host keys too, and to generate new keys for luna. Again, those keys are still used for ssh://git.archlinux.org -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [aur-general] AUR migration
On 7/24/20 6:18 PM, Baptiste Jonglez wrote: > Can't you just copy the SSH host keys from the old machines? > > It's the same service as before and (presumably) the host private keys > were not compromised, so there is no reason to change keys. In theory one could, but this was not simply migrating one box to another physical device. The old AUR box is still available, running other services (e.g. git.archlinux.org), and is still using those keys. Per default, I don't see a good reason for two active boxes to have the same private keys, but if you know better, then let's have *that* discussion. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [aur-general] AUR migration
On 7/27/20 8:03 PM, Gaetan Bisson via arch-dev-public wrote: > [2020-07-25 00:18:55 +0200] Baptiste Jonglez: >> On 24-07-20, Giancarlo Razzolini via arch-dev-public wrote: >>> The migration is almost done. Since we are moving to a new machine, it will >>> have new host keys. They are: >>> >>>Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 >>>ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 >>>RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI >> >> Can't you just copy the SSH host keys from the old machines? >> >> It's the same service as before and (presumably) the host private keys >> were not compromised, so there is no reason to change keys. > > It's quite unsettling that we seem to be rushing to write a news post > while this very reasonable suggestion remains completely ignored. Nothing "unsettling", about it, the suggestion is not as reasonable as it seems on the surface (because the old box is still in use), but even without that knowledge, given devops clearly didn't do that I don't understand the rationale for refusing a news post after the fact. If you think the old box is out of use and deleted, then the keys would be gone and it would be too late to transfer them. > For future migrations I would greatly appreciate if not all on-disk data > were thrown away. On top of SSH keys, there are home directories which > contain not only user data but also in some cases things useful for the > distro as a whole (such as the service I use to version iana-etc files). Is there reason to believe that this data was thrown away? We were given warning when soyuz got decommissioned, to backup data before the decommissioning date. And orion is not decommissioned, it is still used for mail at least, so your data there is untouched and still accessible. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [aur-general] AUR migration
On 7/24/20 3:24 PM, Giancarlo Razzolini via arch-dev-public wrote: > Em julho 23, 2020 17:09 Giancarlo Razzolini via aur-general escreveu: >> Hi All, >> >> In continuing with the improvements being done to our infrastructure, >> we're >> planning to migrate the AUR to another machine. This means that, >> during the migration, >> there *will* be downtime of the whole AUR. >> >> I expect the migration to take around two hours and happen either >> tomorrow (Friday) >> or on Saturday, depending on availability. >> >> Regards, >> Giancarlo Razzolini >> > > The migration is almost done. Since we are moving to a new machine, it will > have new host keys. They are: This seems like it could be a reasonable situation for posting to https://www.archlinux.org/news/ so that people seeing the keys change understands why and that it's okay. Not everyone follows a-d-p or aur-general. Thoughts? > > Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 > ECDSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 > RSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI > > They are also be available on the home page when logged out. > > Regards, > Giancarlo Razzolini (I'm never logged out, so I never see them.) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [PATCH 2/2] makepkg.conf: Update our default FLAGS
On 7/10/20 2:38 PM, Jan Alexander Steffens (heftig) via arch-dev-public
wrote:
> From: "Jan Alexander Steffens (heftig)"
>
> I recently read [Fedora's documentation on build flags][1] and I think
> they have some useful ideas.
>
> 1. Move -D_FORTIFY_SOURCE=2 from CPPFLAGS to CFLAGS using -Wp:
>Unfortunately, there are still build systems (e.g. CMake, homegrown
>Makefile rules) which use CFLAGS but not CPPFLAGS. Ultimately, we can
>cover more code with this workaround.
Sounds like a job for
build() {
export CFLAGS="$CPPFLAGS $CFLAGS"
...
}
(I do not understand how -Wp, helps here, its purpose is only to prevent
the compiler driver from reinterpreting it before passing it to the
preprocessor, and only if you have special needs and believe it will
mangle your flags. -D_FORTIFY_SOURCE sounds sufficiently boring to say
it won't be mangled.)
Our cmake build already solves this with:
https://git.archlinux.org/svntogit/packages.git/tree/trunk/cmake-cppflags.patch?h=packages/cmake
> 2. -fexceptions:
>Slight hardening of C programs making use of automatic variable
>cleanup or pthread_cancel. Cost should be negligible.
>
> 3. -fstack-clash-protection:
>Hardening of large stack allocations. Cost should be negigible.
>
>We need to patch clang to ignore this, like we once did for -fno-plt.
>
> 4. -fcf-protection:
>Hardening which makes code compatible with Intel CET. Increases code
>size a bit but cost should be negligible.
>
>No processors supporting it are available yet, but the linker only
>marks binaries for CET when all code is compatible, so we could get a
>head-start on this.
>
> 5. -fasynchronous-unwind-tables:
>Generates DWARF unwinding information that doesn't get stripped.
>Increases binary size a bit.
>
>Should make sure tools like perf and gdb can unwind the stack
>completely even without debug symbols. This makes the debugger more
>useful if you only have debug symbols for some frames, since frames
>without symbols can no longer break unwinding.
If I can finish splitdebug package support in dbscripts...
> 6. -Wp,-D_GLIBCXX_ASSERTIONS:
>Enables some assertions in libstdc++. Hardening similar to
>_FORTIFY_SOURCE.
>
> 7. -grecord-gcc-switches:
>Useful information to record. But since we don't use `debug` yet,
>won't affect us much.
I wanted to add this to .BUILDINFO based on the contents of makepkg.conf
TBH. It would work independent of 'debug'.
> [1]:
> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md
> ---
> PKGBUILD | 2 +-
> makepkg.conf | 12 +++-
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/PKGBUILD b/PKGBUILD
> index 846a970..ed1d492 100644
> --- a/PKGBUILD
> +++ b/PKGBUILD
> @@ -27,7 +27,7 @@
> source=(https://sources.archlinux.org/other/pacman/$pkgname-$pkgver.tar.gz{,.sig
>
> sha256sums=('bb201a9f2fb53c28d011f661d50028efce6eef2c1d2a36728bdd0130189349a0'
> 'SKIP'
>
> '3353f363088c73f1f86a890547c0f87c7473e5caf43bbbc768c2e9a7397f2aa2'
> -
> 'd113252f97f019a13541237a4f4c7fbe9ffd0c3e71ecd7cd8d5d227b378819ab')
> +
> '3818559af64c11d9cda127ae75e48e5f8780bbe71513f5a3c484c38eb16a2b71')
>
>
> build() {
> diff --git a/makepkg.conf b/makepkg.conf
> index a277503..c8c917e 100644
> --- a/makepkg.conf
> +++ b/makepkg.conf
> @@ -36,16 +36,18 @@ CARCH="x86_64"
> CHOST="x86_64-pc-linux-gnu"
>
> #-- Compiler and Linker Flags
> -CPPFLAGS="-D_FORTIFY_SOURCE=2"
> -CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
> -CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
> +#CPPFLAGS=""
> +CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
> +-fstack-clash-protection -fcf-protection
> -fasynchronous-unwind-tables \
> +-Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS"
> +CXXFLAGS="$CFLAGS"
> LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
> #RUSTFLAGS="-C opt-level=2"
> #-- Make Flags: change this for DistCC/SMP systems
> #MAKEFLAGS="-j2"
> #-- Debugging flags
> -DEBUG_CFLAGS="-g -fvar-tracking-assignments"
> -DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
> +DEBUG_CFLAGS="-g -grecord-gcc-switches -fvar-tracking-assignments"
> +DEBUG_CXXFLAGS="-g -grecord-gcc-switches -fvar-tracking-assignments"
> #DEBUG_RUSTFLAGS="-C debuginfo=2"
>
> #
>
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] [PATCH 1/2] makepkg.conf: Change default compression to .zst (fast)
On 7/10/20 2:38 PM, Jan Alexander Steffens (heftig) via arch-dev-public
wrote:
> From: "Jan Alexander Steffens (heftig)"
>
> Most people create packages from the AUR for local installation. This
> allows these packages to be created more quickly.
This doesn't switch to .zst (we already set this to .zst), only COMPRESSZST.
Anyway people creating packages from the AUR for local installation
should use PKGEXT=.pkg.tar to disable compression, as this is instant,
pacman -U can install it faster because it doesn't need to decompress,
and it doesn't take up more disk space if the user will rm the package
after installing anyway...
> ---
> PKGBUILD | 2 +-
> makepkg.conf | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/PKGBUILD b/PKGBUILD
> index 8566270..846a970 100644
> --- a/PKGBUILD
> +++ b/PKGBUILD
> @@ -27,7 +27,7 @@
> source=(https://sources.archlinux.org/other/pacman/$pkgname-$pkgver.tar.gz{,.sig
>
> sha256sums=('bb201a9f2fb53c28d011f661d50028efce6eef2c1d2a36728bdd0130189349a0'
> 'SKIP'
>
> '3353f363088c73f1f86a890547c0f87c7473e5caf43bbbc768c2e9a7397f2aa2'
> -
> '9c769f13c09a6f24c393a9762474eded2f269d8966e7764d9160d62232a7919b')
> +
> 'd113252f97f019a13541237a4f4c7fbe9ffd0c3e71ecd7cd8d5d227b378819ab')
>
>
> build() {
> diff --git a/makepkg.conf b/makepkg.conf
> index d8bf59e..a277503 100644
> --- a/makepkg.conf
> +++ b/makepkg.conf
> @@ -132,7 +132,7 @@ DBGSRCDIR="/usr/src/debug"
> COMPRESSGZ=(gzip -c -f -n)
> COMPRESSBZ2=(bzip2 -c -f)
> COMPRESSXZ=(xz -c -z -)
> -COMPRESSZST=(zstd -c -z -q -)
> +COMPRESSZST=(zstd -c -T0 -)
> COMPRESSLRZ=(lrzip -q)
> COMPRESSLZO=(lzop -q)
> COMPRESSZ=(compress -c -f)
>
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Use detached package signatures by default
On 7/8/20 11:05 PM, Anatol Pomozov via arch-dev-public wrote: > TLDR; let’s start using detached package signatures to make system > updates faster. That all sounds great, but it's really down to how repo-add does its thing. So maybe this belongs on pacman-dev? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
On 6/26/20 2:39 AM, Andreas Radke via arch-dev-public wrote:
> We have to choose if we want simple
>
> makedepends=('xorg-font-utils') or
> makedepends=('xorg-mkfontscale' 'xorg-bdftopcf' 'xorg-font-util')
>
> Sure we can drop the meta package "xorg-font-utils" entirely but it
> simply covers all possible makedependencies to simplify packagers life.
> We should add another ToDo list to either fully remove the
> metapackage if we agree to do so or at least move it to a
> makedependency. Check all those packages that still depend on it at
> runtime probably all wrong:
> https://www.archlinux.org/packages/extra/any/xorg-font-utils/
I'm not really afraid of having 3 makedepends :) so the second TODO
seems reasonable.
Thanks.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
On 6/25/20 11:29 PM, Chih-Hsuan Yen via arch-dev-public wrote:
> On Thu, Jun 25, 2020 at 05:53:28PM -0400, Eli Schwartz via arch-dev-public
> wrote:
>> On 3/31/20 12:36 PM, Eli Schwartz wrote:
>>> On 3/30/20 6:35 AM, Chih-Hsuan Yen via arch-dev-public wrote:
>>>> On Mon, Mar 30, 2020 at 01:26:11AM +0200, Frederik Schwan via
>>>> arch-dev-public wrote:
>>>>> We received a Feature Request today to remove fontconfig and
>>>>> xorg-mkfontscale dependencies from our font packages according to our own
>>>>> font packaging guidelines [0].
>>>>>
>>>>> I discussed with Eli on #archlinux-bugs and we think it's a no-brainer
>>>>> but before creating a TODO we'd like to ask for your opinions first.
>>>>>
>>>>> Thank you
>>>>>
>>>>> [0] https://bugs.archlinux.org/task/66012
>>>>>
>>>> Just as a reference - in another similar feature request [1], Doug
>>>> Newgard mentioned that not everyone agrees on removing fontconfig and/or
>>>> xorg-mkfontscale. I believe the following two mails in the mentioned
>>>> arch-dev-public thread are most relevant: [2][3].
>>>>
>>>> Having said that, I agrees on removing fontconfig & xorg-mkfontscale.
>>>>
>>>> Best,
>>>>
>>>> Chih-Hsuan Yen
>>>>
>>>> [1] https://bugs.archlinux.org/task/59164
>>>> [2]
>>>> https://lists.archlinux.org/pipermail/arch-dev-public/2016-April/027946.html
>>>> [3]
>>>> https://lists.archlinux.org/pipermail/arch-dev-public/2016-April/027948.html
>>>
>>> heftig, City-busz, could you elaborate on just what this means? All I
>>> see there is mention that "it ensures the hooks are available", but that
>>> simply says "it needs to be installed for the sake of being installed".
>>> Is there an underlying reason here?
>>>
>>> Note that regardless of whether a font package depends on fontconfig,
>>> and regardless of whether you have any fonts installed, the fontconfig
>>> post_install and post_upgrade scripts run fc-cache --really-force during
>>> install time and on every single pkgver or pkgrel update, and then if
>>> fonts are installed it runs *again* at the end of the transaction. It's
>>> impossible to have fontconfig installed and *not* have the fontconfig cache.
>>>
>>> xorg-mkfontscale does the same thing to run
>>> /usr/share/libalpm/scripts/xorg-mkfontscale but in post_install only.
>>
>> Since there were no objections after several months and the bug reporter
>> is asking for a status update, I will assume the objection from 2016 no
>> longer applies. I'll create a TODO for this later tonight.
>>
>> --
>> Eli Schwartz
>> Bug Wrangler and Trusted User
>>
>
>
> Hi Eli,
>
> I saw the new TODO has been created. Thanks a lot for that! Just one
> question: https://bugs.archlinux.org/task/66012 also mentions
> xorg-font-utils. Should that be removed from dependencies as well?
It is a "Transitional package depending on xorg font utilities", the
package has no contents and simply
depends=('xorg-bdftopcf' 'xorg-mkfontdir' 'xorg-mkfontscale'
'xorg-font-util')
Not sure why it exists still TBH, but I'd venture to say it should be
removed too, yes...
e.g. why drag in a recursive dependency on xorg-bdftopcf in this day and
age?
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
On 3/31/20 12:36 PM, Eli Schwartz wrote: > On 3/30/20 6:35 AM, Chih-Hsuan Yen via arch-dev-public wrote: >> On Mon, Mar 30, 2020 at 01:26:11AM +0200, Frederik Schwan via >> arch-dev-public wrote: >>> We received a Feature Request today to remove fontconfig and >>> xorg-mkfontscale dependencies from our font packages according to our own >>> font packaging guidelines [0]. >>> >>> I discussed with Eli on #archlinux-bugs and we think it's a no-brainer but >>> before creating a TODO we'd like to ask for your opinions first. >>> >>> Thank you >>> >>> [0] https://bugs.archlinux.org/task/66012 >>> >> Just as a reference - in another similar feature request [1], Doug >> Newgard mentioned that not everyone agrees on removing fontconfig and/or >> xorg-mkfontscale. I believe the following two mails in the mentioned >> arch-dev-public thread are most relevant: [2][3]. >> >> Having said that, I agrees on removing fontconfig & xorg-mkfontscale. >> >> Best, >> >> Chih-Hsuan Yen >> >> [1] https://bugs.archlinux.org/task/59164 >> [2] >> https://lists.archlinux.org/pipermail/arch-dev-public/2016-April/027946.html >> [3] >> https://lists.archlinux.org/pipermail/arch-dev-public/2016-April/027948.html > > heftig, City-busz, could you elaborate on just what this means? All I > see there is mention that "it ensures the hooks are available", but that > simply says "it needs to be installed for the sake of being installed". > Is there an underlying reason here? > > Note that regardless of whether a font package depends on fontconfig, > and regardless of whether you have any fonts installed, the fontconfig > post_install and post_upgrade scripts run fc-cache --really-force during > install time and on every single pkgver or pkgrel update, and then if > fonts are installed it runs *again* at the end of the transaction. It's > impossible to have fontconfig installed and *not* have the fontconfig cache. > > xorg-mkfontscale does the same thing to run > /usr/share/libalpm/scripts/xorg-mkfontscale but in post_install only. Since there were no objections after several months and the bug reporter is asking for a status update, I will assume the objection from 2016 no longer applies. I'll create a TODO for this later tonight. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] SDR package naming
On 6/5/20 9:04 AM, Filipe Laíns via arch-dev-public wrote: > My main concern here is that it is not as simple as it just being > Kyle's decision, it sets a precedent. I believe the naming is > incorrect, and as such, should be fixed. I have tried initiating a > conversation with the maintainer but with that didn't result in > anything. It did result in something: he said "no". > I really don't want to step in anyone's toes, I have postponed this > email as much as I could. Giving the lack of the reply from Kyle, one > can only assume he does not care that much about the issue. I am fine > with waiting one or two weeks before taking action to make sure he has > time to reply, if there are no objections. "I don't agree with this, it fails to be memorable and using the upstream shortname is confusing and does a disservice to users" sure sounds like he objects to me. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] HEADS UP: Qt 5.15 in [testing]
On 6/2/20 3:35 PM, Ike Devolder via arch-dev-public wrote: > On Thu, May 28, 2020 at 10:05:58AM +0200, Antonio Rojas via arch-dev-public > wrote: >> El jueves, 28 de mayo de 2020 10:01:23 (CEST), Ike Devolder via >> arch-dev-public escribió: >>> I have segfaults with multiple programs (keepassxc, quasselclient) >>> >> >> Please open bug reports and attach backtraces > > All my issues were related to QT_QPA_PLATFORMTHEME=gtk2 the issues are > resolved by changing gtk2 to gtk3 The qt5-styleplugins package was removed from community because according to arojas it doesn't even build on qt 5.15 -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] GitLab switchover and SSO migration
On 5/17/20 7:22 PM, Sven-Hendrik Haase via arch-dev-public wrote: >> On a related note, will this impact projects that prefer email patch >> submissions in any way (except that they can now opt-in to GitLab too)? >> > > Yes and no: The current idea is to stop operating patchwork, the current > primary way for namcap, pacman, AUR, archiso to accept patches via > email. However, GitLab has some support for email-based collaboration > [2]. David, who recently became archiso maintainer, is fine with taking > archiso to GitLab and Allan is fine taking pacman dev over there as > well. It is my hope that the other projects who are currently primarily > relying on email patches will follow suit. It would be nice to > consolidate everything onto the same platform. We're in no hurry to shut > down patchwork right now though so we'll give everyone some time to > evaluate GitLab and if it turns out that it can't support some > much-desired development workflows, we'll re-evaluate. > > Cheers, > Sven > > [0] https://git.archlinux.org/svntogit/community.git/ > [1] https://git.archlinux.org/svntogit/packages.git/ > [2] > https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#new-merge-request-by-email-core-only ISTR some discussion long in the past about how gitlab could "do it all", but I poked into it recently out of curiosity and the status seems to be more confusing than that. This email submission thing is imperfect, since as far as I've been able to tell it creates a per-user email address for users who already have a gitlab account, so no anonymous or ad-hoc submissions. And it is strictly one way -- i.e. it enters the gitlab silo and emails don't leave. You could, I guess, email a mailing list or the project maintainers manually, and bcc your secret email submission endpoint with its user API token address. That would, however, simply end up with the two discussions being completely siloed away from each other. I haven't been able to find discussion about gitlab cc'ing a mailing list for issue or patch discussion, or even archive purposes. There is of course email notification that doesn't invoke a mailing list, but that doesn't provide patch diffs for inline comments so it's not quite the same experience and I think you'll inevitably end up interacting with merge requests mainly via the gitlab website (leaving aside the question of "what if someone just really likes mailing lists"). -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] GitLab switchover and SSO migration
On 5/17/20 4:37 PM, Lukas Fleischer via arch-dev-public wrote: > Email addresses of aurweb accounts have to be confirmed (and accounts > without verified email addresses are not usable and can be filtered out > by a simple SQL query). Old accounts have been purged in ~2014 and, to > the best of my knowledge, there should not be any active accounts left > that did not go through the email verification process. I think the other concern here was that after you've confirmed your email address, you can modify it and it won't be re-verified. The same rule applies to flyspray since it will email you a code to complete registration, but doesn't use a verification link when you change it. The current state of the forum and the wiki do, however, require verifying changes of email address for both sites. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On 5/13/20 4:16 PM, Morten Linderud via arch-dev-public wrote: > The complete future Go PKGBUILD is attached to this email below. ``` replaces=(go-pie) provides=(go-pie) ``` Should this provide it too? Anything that explicitly expected go-pie cannot assume the new package is a drop-in replacement, it will need changes for the flags and can, at the same time, swap out the requirement for go-pie. Yes, this would mean any PKGBUILD which makedepends on it needs to be updated immediately or fail to rebuild. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On 4/30/20 3:56 AM, Anatol Pomozov via arch-dev-public wrote: > Thank you for coming up with this document. > > Go is a fantastic language and I would love to see more people using > it. Having things documented will help our users to get more > comfortable with the golang packaging. This RFC is about packaging code, not encouraging people to use a particular language when writing their next big project. :p Let's focus on that. > My concern was related to use of vendorized sources. "-vendor" was not > created for the cache management. If one wants to warmup the gomodules > download cache then "go mod download" should be used. See more info > about this tool here https://github.com/golang/go/issues/26610 > > And if we plan to encourage adding the cache warmup to all golang > PKGBUILD (that's gonna be thousands of packages) then this extra > complexity need be justified. Anyone who wants to follow our advise > needs to have clear answers to following questions: Is this feature > solely to avoid the download during the build() step or there is > something else? Why downloading in build() is bad, does it hurt the > users? What use-cases does show an advantage of the cache warmup.. > etc.. I'd like to elaborate on this again. Because I don't either understand what the initial purpose of this RFC suggestion was. Why does it matter to makepkg how the go compiler downloads source code, or using which options? Any download that is done outside the source=() array is violating the PKGBUILD contract, and is not cached in $SRCDEST. It is therefore not persisted between successive clean chroot builds since those use a temporary $HOME and $BUILDDIR which is deleted between uses. And regardless of any other factors, it will not be able to work if the makepkg tool is executed in an environment where the network has been disabled. So, we don't get caching and we don't get offline builds. That's beyond question. What is the intended goal anyone intends to solve by warming up the gomodules download cache, precisely? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] Away on holiday for the next 2 weeks
I've been only sporadically available the last few days, as some people may have noticed, and I will be mostly inaccessible until after Passover[1] / the 19th. It's been very hectic here recently, and ugh, it is so frustrating to get ready for a major holiday in the middle of a pandemic. :( We have still done basically no shopping because my brother was sick so we were in quarantine. Fortunately he's feeling a lot better now and everyone else is fine, so we get to be even *busier*. \o/ I don't anticipate much other than routine updates for my packages; feel free to update anything that is needed. There are already a few updates I haven't had time to handle yet. Note to jelle: If/when calibre gets a new release it will probably need a new rapydscript-ng release, if so, ask upstream for one. -- Eli Schwartz Bug Wrangler and Trusted User [1] https://en.wikipedia.org/wiki/Passover signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Removing dependency on fontconfig/xorg-mkfontscale of font packages
On 3/30/20 6:35 AM, Chih-Hsuan Yen via arch-dev-public wrote: > On Mon, Mar 30, 2020 at 01:26:11AM +0200, Frederik Schwan via arch-dev-public > wrote: >> We received a Feature Request today to remove fontconfig and >> xorg-mkfontscale dependencies from our font packages according to our own >> font packaging guidelines [0]. >> >> I discussed with Eli on #archlinux-bugs and we think it's a no-brainer but >> before creating a TODO we'd like to ask for your opinions first. >> >> Thank you >> >> [0] https://bugs.archlinux.org/task/66012 >> > Just as a reference - in another similar feature request [1], Doug > Newgard mentioned that not everyone agrees on removing fontconfig and/or > xorg-mkfontscale. I believe the following two mails in the mentioned > arch-dev-public thread are most relevant: [2][3]. > > Having said that, I agrees on removing fontconfig & xorg-mkfontscale. > > Best, > > Chih-Hsuan Yen > > [1] https://bugs.archlinux.org/task/59164 > [2] > https://lists.archlinux.org/pipermail/arch-dev-public/2016-April/027946.html > [3] > https://lists.archlinux.org/pipermail/arch-dev-public/2016-April/027948.html heftig, City-busz, could you elaborate on just what this means? All I see there is mention that "it ensures the hooks are available", but that simply says "it needs to be installed for the sake of being installed". Is there an underlying reason here? Note that regardless of whether a font package depends on fontconfig, and regardless of whether you have any fonts installed, the fontconfig post_install and post_upgrade scripts run fc-cache --really-force during install time and on every single pkgver or pkgrel update, and then if fonts are installed it runs *again* at the end of the transaction. It's impossible to have fontconfig installed and *not* have the fontconfig cache. xorg-mkfontscale does the same thing to run /usr/share/libalpm/scripts/xorg-mkfontscale but in post_install only. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Discussion - Increasing our CPU requirements
On 3/29/20 11:25 AM, Filipe Laíns via arch-dev-public wrote: > I want to clarify what I am proposing. > > I would not be an entirely new architecture in the sense of i686, CPU > extensions are not different architectures and shouldn't be treated as > such. > > What I would for us to do is to create a x86-64-axv2, etc. that would > complement x86-64. We would not add it as a target for all packages, > just for the ones that make sense. > > For this pacman would have to support architecture priority. We could > have something like this: > > Architecture = x86-64-axv2 x86-64 > > This means if a x86-64-axv2 package is available, it would be selected > over the x86-64 one. That way we don't need to rebuild all packages. Where would you store this package? The pkgname must be unique in each repository database, so you would need a community-avx2 repository. Then it is as simple as Santiago said, just have users add the additional repository if they need it, giving it precedence in pacman.conf. (Except I will go one step further and say this is the *only* way.) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Proposal to remove PyGTK
On 3/13/20 6:33 AM, Jan de Groot wrote: > Balló György via arch-dev-public schreef op 2020-03-13 10:56: >> Hi all, >> >> I would propose to remove PyGTK from the official repositories. PyGTK >> was used to create GTK2 applications in python2. It's deprecated and >> unmaintained since 2011 in favor of PyGObject, and does not receive any >> fixes since then. >> >> ... >> >> >> Any objections? >> > > We can't keep supporting unmaintained software for ages. Pygtk is one of > those projects that keeps python2 in our repos, so I think it's best to > update/patch projects to a version that uses PyGobject and remove > features or drop the remaining packages that still depend on pygtk. > > Go for it! Packages using pygtk: - zbar Felix, the zbar package currently builds python2-zbar bindings using pygtk. These aren't used by any package, and upstream documents support for python3 and GObject Introspection bindings usable via python2/python3: https://github.com/mchehab/zbar#python-widgets Please drop the unused pygtk bindings and build python3/gobject ones instead. :D - python2-twisted ported to gobject for gtk3, which should work fine in python3, maybe we can just drop this checkdepends/optdepends and disable those tests to not advertise its existence? - libappindicator / lib32-libappindicator As far as I can tell, these don't even use pygtk at all these days, just gobject introspection. - gimp We hope and pray for the awaited gimp 3.0 release... - nmap Needed for zenmap, still unported. I see the nmap package has been updated to drop the zenmap program, which I don't think was really needed at the moment, since we could just wait until we're ready to finally drop pygtk itself... this is still blocked on gimp anyway. What's the upstream porting status? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On 3/15/20 4:40 PM, Morten Linderud via arch-dev-public wrote:
> I'm aware that go {list,build,test} fetches dependencies on the fly.
>
> And let me reiterate again; *This shouldn't happen*.
>
> We should be capable of performing complete software builds without internet
> connection. If we can't have the sources downloaded in the source array, they
> need to be fetched in prepare.
>
> This is why I'm also bringing up the prepare function in the first place.
But once you're in prepare(), you're no longer in $SRCDEST and you've
already failed, no caching is taking place.
You're also already inside the chroot, which means you cannot disable
the internet connection for the chroot (not that we have been able to do
so in the past, but fetching sources in prepare() certainly doesn't get
us closer to offline builds.)
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] "date" C++ library packaging
On 2/24/20 10:36 AM, Brett Cornwall via arch-dev-public wrote: > On 2020-02-13 02:24, David C. Rankin wrote: >> And with the note that much of Howard Hinnant's date/time library is >> being >> incorporated into the next C++ standard. Quite a feather in anyone's cap. > > > Does anyone have any strong opinions? Does waybar use just what is expected to be in the C++ standard down the line? I think using a more specific name like "chrono-date" seems reasonable, especially if it is going to be dropped again in a couple years once C++20 is available and targeted by applications like waybar. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
On 2/16/20 8:11 PM, Gaetan Bisson wrote: > [2020-02-16 20:03:16 -0500] Eli Schwartz via arch-dev-public: >> It's pretty plausible that this commit is simply incompatible with the >> previous version of sshd, therefore it could not reexec: >> https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac549e6ba89013abaf >> >> So this is "expected" behavior. > > That seems likely indeed. What troubles me is that upstream has never > broken live SSH daemons in such a way before, maybe it was just pure > luck, but I had assumed this was a conscious design choice on their > part. It could be this one was too difficult to handle since it changed the way marshaling the sshd_config worked? I suppose you'd need to double-check with them. In the meantime, it is definitely not just us: https://bugs.gentoo.org/709748 -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
On 2/16/20 7:54 PM, Gaetan Bisson wrote: >> Is it sufficient to add a post_upgrade message? > > Probably, yes but then we'd need a new package out of [testing] fast. > And users might complain that the post_upgrade message wasn't visible > enough... :) We could even try to detect a running sshd.service when upgrading from openssh <= 8.1p1-2 and restart it, I suppose. It should not close existing sessions, and new ones would not be able to be created anyway, so there's no downsides to doing this limited-scope restart in a situation where it is definitely required. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote: > And I also regret not being able to diagnose what the exact problem is > just now. As was pointed out in the bug: https://bugs.archlinux.org/task/65517#comment186483 ssh errors with: kex_exchange_identification: read: Connection reset by peer sshd logs the error: fatal: recv_rexec_state: buffer error: incomplete message It's pretty plausible that this commit is simply incompatible with the previous version of sshd, therefore it could not reexec: https://github.com/openssh/openssh-portable/commit/c2bd7f74b0e0f3a3ee9d19ac549e6ba89013abaf So this is "expected" behavior. There's no way to upgrade this without triggering the need for a restart. All consumers of openssh on any operating system will need to restart sshd, possibly via maintenance scripts provided by the distro. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Urgent news item: sshd needs restarting after upgrading to openssh-8.2p1
On 2/16/20 7:47 PM, Gaetan Bisson via arch-dev-public wrote: > Dear all, > > I'd like to post the following news item within the hour. > > > > Title: sshd needs restarting after upgrading to openssh-8.2p1 > > Conent: After upgrading to openssh-8.2p1, the existing SSH daemon will > be unable to accept new connections. When upgrading remote > hosts, please make sure to restart the SSH daemon using > `systemctl restart sshd` right after `pacman -Syu`. > > > > I deeply regret not spotting this while the package was in [testing]. > And I also regret not being able to diagnose what the exact problem is > just now. Given time is of the essence, I propose posting the above news > quickly even I don't consider it a very satisfying solution... Is it sufficient to add a post_upgrade message? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] Absent until next week
Due to a family wedding, I will be gone for a week, until late Monday Feb. 3 or Tuesday Feb. 4. I won't have internet other than limited mobile data, but can still be contacted via email/IRC, which I shall check semi-regularly. Sorry for the late notice. :) Feel free to update anything that needs updating while I'm gone. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] rsync & bundled zlib
On 1/13/20 11:23 AM, Christian Hesse wrote: > Hello everybody, > > to date we ship rsync with bundled zlib to keep compatibility with rsync > up to version 3.1.0 and it's old-style --compress option. This is no longer > required with rsync 3.1.1, which was released on 2014-06-22 - nearly six > years ago! > The bundled zlib carries some security issues, so time to act - one way > or another. > > Even old-stable Debian Jessie [0] has rsync version 3.1.1. So any concern to > finally drop bundled zlib and use system zlib? Definitely. > I would suggest to post a news item, feel free to give thoughts and feedback. Not sure... how likely is it that people will be contacting servers which are running a version of rsync even older than Debian Jessie? FWIW, the original bug report: https://bugs.archlinux.org/task/41024 rsync already spits out an error stating the remote machine does not understand the relevant option: "rsync: on remote machine: --new-compress: unknown option" So this seems like an obviously debuggable issue -- and the solution is just "upgrade your remote server". It doesn't stop you from using ssh, scp, or rsync without compression. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Todos for language specific rebuilds
On 1/10/20 4:42 PM, Christian Rebischke via arch-dev-public wrote: > Hi everybody, > > I would like to propose that we create todos for rebuilds of language > specific packages. > > We had two major rebuilds in the last months: python3.8 and ruby2.7. > > Can we agree that we create a todo before such rebuilds? > The advantages outweigh the disadvantages. We would gain: > > * More people help rebuilding the packages.' What help is needed? If this is just about having more people sed the pkgrel variable with "$pkgrel + 1", then try to build it, more people doesn't actually help. We have automated rebuilders which are very capable in this regard. > * Every maintainer gets informed about the rebuild. I agree with you that this is indeed a problem, and I would like to propose a pretty simple solution. Let's post on arch-dev-public to give people a heads-up. This means even if your package failed to be detected for rebuilding and would never appear on any TODO, you as a maintainer know that it happened and can manually rebuild your package. > * Maintainers have the possibility to test the packages. At least for the python rebuilds, the process of rebuilding the ecosystem is long and painfully drawn out, *because* packages with failing testsuites cannot be rebuilt automatically and go onto a TODO list of broken packages. Given this thread started because we just rebuilt ruby, can I assume that PKGBUILDs for ruby packages are in the general habit of not containing check() functions for running unittests? Either because upstream does not have unittests or because they are not being run? If packages have upstream unittests but don't run them, then the maintainer of the package has been derelict in his or her duty. If packages do NOT have upstream unittests, then this is unfortunate, and I don't currently have an answer for what we should do. :( > If tools exist for creating todos, I would like to ask the persons with > such tools to make them available for everybody (if not already > happened). It's a website submission form that expects you to write some explanatory message, then fill in a newline-separated list of pkgnames. Any rebuilder must by definition have the latter, even if that rebuilder is "I scrolled through archweb and did it all manually by flipping back and forth between my terminal and my browser". No "tool for creating todos" need exist. Ask instead about tools for enumerating language dependencies. ... For python, it's pretty simple. pkgfile -d '/usr/lib/python3.8/' For ruby, it's also pretty simple: pkgfile -d '/usr/lib/ruby/' Also sogrep to see if any packages link to the shared library libpython3.8 or libruby, but hey, that's what we already do for rebuilds of only 3 or 4 packages. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Todos for language specific rebuilds
On 1/11/20 4:51 PM, Jelle van der Waa wrote: > Some languages however require special treatment such as Haskell and > require rebuilds from GHC => Haskell-foo => Haskell-bar etc which can > become complicated. For example if I want to update a dependency of > taskell I will have to rebuild all depending programs/libs so tooling > which makes that easier is welcome to me. I know Felix has some stuff > but we should make this more visible. Haskell is *not* different. Haskell is an excellent example of a language where problems can be caught by the person doing the rebuild, because it's all shared libraries which can be caught by our soname detection. Sure, haskell is complex and fiddly and requires complex rebuilds for every trivial change, which requires complex orchestration to pull off, but the underlying cause isn't all that complex. This thread was founded with the premise that language maintainers should not just do silent rebuilds, because package maintainers need to do it themselves in order to know the resulting packages work. You're arguing instead, that it's fine for Haskell to be rebuilt automatically... but that we need to preserve valuable institutional knowledge on how the current maintainer handles this, to reduce the bus factor and, I guess, that if Felix retires no one will know how to rebuild haskell anymore. This is an important topic which deserves discussion about documenting HOWTOs, but is, I think, ultimately unrelated to and a distraction from, *this* thread. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
On 1/2/20 11:35 PM, Eli Schwartz wrote: > After a bit of research work and making sure one or two things have been > properly packaged, I've developed a PKGBUILD which ensures that a system > has the POSIX shell and utilities (XCU) section installed. I believe > this is an interesting thing to track, and people will want to know they > have it installed... in aid of this, I've gotten two major holdouts > packaged a while back -- pax (thanks to dbermond) and ncompress. > > I'd like to add this package to community, although given it's never > been in the AUR before, it's never had AUR votes... As there do not seem to be any objections, I've uploaded this now. https://www.archlinux.org/packages/community/any/posix/ -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
On 1/3/20 9:47 PM, Sébastien Luttringer wrote: >> I would argue that POSIX is a standard which people actually care about, >> and LSB is a standard which no one cares about. > > I agree that few people are interested in LSB. I think it's barely the same > for > POSIX. > > Our scripts are not written POSIX compatible (i.e they rely on more tools than > the standard). Do you still know people writing POSIX compatible scripts > nowadays (students excluded)? Lots of people? Anyone who works with non-Linux variants of Unix. There are many such people. > The GNU Operating System (our core rely on it) have disagreements with POSIX > and are de-facto non-POSIX (e.g df). The GNU coreutils and other GNU projects are mostly POSIX compatible, and in the uncommon cases where they deviate from POSIX, they have carefully thought out rationales. Furthermore, even in those cases, they take great pains to *still* be POSIX compatible, if you export the environment variable "POSIXLY_CORRECT". In the case of df, I believe the only deviation from POSIX is in the default block size (POSIX says 512 bytes, and POSIXLY_CORRECT will ensure this is so, but it may otherwise default to 1024). > I'm not able to tell you something in Arch that rely on POSIX.2 (Shell and > Utilities). > What make you think people care about this standard? As Ralph Corderoy has mentioned on arch-general, Arch users may be writing scripts that also target non-Linux platforms, or use scripts which are authored by people on non-Linux platforms. This will probably tend to be more noticeable in areas where BSD, or commercial UNIX, has a stronger presence than in the desktop sector. On a personal level, my scripts feel comfortable assuming certain POSIX required utilities exist, like "cmp" (which is notably not installed by default on archlinux, ever since the move of base from a group to a metapackage). And POSIX doesn't say you cannot rely on non-POSIX tools -- it just says you can rely on the POSIX ones existing, and having certain behavior. I have certainly never gone out of my way to document that a script relies on the "cp" command existing, whereas I would probably document its reliance on "wget"... > I'm not opposed to add a posix metapackage. I'm just very reserved about its > usefulness. > > One unfortunate consequence could be to have packages rely on it to make > dependencies shorter, and make us pull cups or cronie. The posix metapackage shall not be (mis)used in such a manner, please report a bug if anyone does so. It is not the business of a package dependency list to rely on "POSIX", it is the business of a package list to rely on archlinux's mandatory base and otherwise specify its own requirements without forcing a POSIX conformity the user never asked for. It shall be used to help individuals ensure their system is a suitable platform for running a POSIX userland, for example, to know that thirdparty ISV scripts will work or that they may rely on certain interactive commands existing on an offline system (vi, if the user portability option is selected). -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
On 1/3/20 10:48 AM, Sébastien Luttringer wrote: > > On Thu, 2020-01-02 at 23:35 -0500, Eli Schwartz via arch-dev-public wrote: >> ... >> >> Thoughts? > > Posix is an old standard which fail to make a common ground to Unix systems. > > If we think user needs meta packages to install their Arch, is the Linux > Standard Base more relevant to us? I would argue that POSIX is a standard which people actually care about, and LSB is a standard which no one cares about. POSIX defines minimally supported featuresets, LSB defines binary compatibility ABIs. Also, requirements like "must be able to install software in the rpm format" don't actually provide value IMO. But at the end of the day, if someone wanted to work on LSB compliance in Arch Linux, I'd be personally okay with that. I just won't work on it myself. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Adding a "posix" metapackage
On 1/3/20 10:22 AM, Santiago Torres-Arias via arch-dev-public wrote:
> On Fri, Jan 03, 2020 at 03:49:11PM +0100, Robin Broda via arch-dev-public
> wrote:
>> On 1/3/20 5:35 AM, Eli Schwartz via arch-dev-public wrote:
>>> After a bit of research work and making sure one or two things have been
>>> properly packaged, I've developed a PKGBUILD which ensures that a system
>>> has the POSIX shell and utilities (XCU) section installed. I believe
>>> this is an interesting thing to track, and people will want to know they
>>> have it installed... in aid of this, I've gotten two major holdouts
>>> packaged a while back -- pax (thanks to dbermond) and ncompress.
>>>
>>> I'd like to add this package to community, although given it's never
>>> been in the AUR before, it's never had AUR votes...
>>>
>>> One of the advantages of having this metapackage is that someone can,
>>> while installing arch, `pacman -S posix-user-portability` and get
>>> essentially everything one would expect to have available on a unix-like
>>> platform, most notably, the interesting parts of the base group that no
>>> longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed.
>>>
>>> I've only included XCU for now, because the system interfaces and
>>> headers are a bit out of scope for me to package and replace in the
>>> event that they'd be missing anything... and also because I'm mainly
>>> interested in the POSIX toolset itself. That being said, I'd certainly
>>> be open to suggested improvements, should anyone have recommendations
>>> for expanding the scope.
>>>
>>> Thoughts?
>>>
>>
>> I think it's a great idea, i definitely see myself using
>> posix{,-user-portability} once it becomes available.
>>
>
> +1 to this. I definitely think this would be useful to have when
> needed. 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?).
Depends on the alternative. I think the most logical way to do providers
would be via https://wiki.archlinux.org/index.php/User:Allan/Alternatives
Currently, the repos do things like have cronie and fcron available, but
if you actually want crontab you need to install the former -- the
latter doesn't provide the POSIX tool, it provides "fcrontab" which is
the wrong name. So it's not eligible *today* to meet the requirements.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
[arch-dev-public] Adding a "posix" metapackage
After a bit of research work and making sure one or two things have been
properly packaged, I've developed a PKGBUILD which ensures that a system
has the POSIX shell and utilities (XCU) section installed. I believe
this is an interesting thing to track, and people will want to know they
have it installed... in aid of this, I've gotten two major holdouts
packaged a while back -- pax (thanks to dbermond) and ncompress.
I'd like to add this package to community, although given it's never
been in the AUR before, it's never had AUR votes...
One of the advantages of having this metapackage is that someone can,
while installing arch, `pacman -S posix-user-portability` and get
essentially everything one would expect to have available on a unix-like
platform, most notably, the interesting parts of the base group that no
longer have an equivalent. i.e. man-db, vi, patch, diffutils, ed.
I've only included XCU for now, because the system interfaces and
headers are a bit out of scope for me to package and replace in the
event that they'd be missing anything... and also because I'm mainly
interested in the POSIX toolset itself. That being said, I'd certainly
be open to suggested improvements, should anyone have recommendations
for expanding the scope.
Thoughts?
For reference, here is my PKGBUILD: https://paste.xinu.at/m-XoggqFGE/
And reproduced here:
# Maintainer: Eli Schwartz
# The list of utilities can be found at
# https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html
# Not all utilities are required: if the synopsis is boxed up and annotated
# with a code, it is only needed for that code. Examples: user portability,
# XSI, Software Development, C Development. Some of these groups were
# implemented here too, though almost certainly the only important ones
are UP
# and XSI.
pkgbase=posix
pkgname=('posix' 'posix-xsi' 'posix-user-portability'
'posix-c-development' 'posix-software-development')
pkgver=2017
pkgrel=1
pkgdesc="metapackage providing the POSIX shell and utilities (XCU)"
arch=('any')
url="https://pubs.opengroup.org/onlinepubs/9699919799/;
depends=('at' # at batch
'awk'
'coreutils' # basename cat chgrp chmod chown cksum comm cp
csplit cut date dd df dirname
# du echo env expand expr false fold head id join
ln logname ls mkdir mkfifo
# mv nice nohup od paste pathchk pr printf pwd rm
rmdir sleep sort split stty
# tail tee test touch tr true tsort tty uname
unexpand uniq unlink wc who
'bc'
'diffutils' # cmp diff
'cronie' # crontab
'ed'
'file'
'findutils' # find xargs
'glibc' # gencat getconf iconv locale localedef
'grep'
'util-linux' # kill logger mesg newgrp renice write
'cups' # lp -- sorry!
'm4'
's-nail' # mailx
'man-db' # man
'patch'
'pax'
'procps-ng' # ps
'sed'
'sh'
'binutils' # strings
'ncurses' # tabs tput
# 'time' # is a shell builtin too
'sharutils' # uudecode uuencode
)
package_posix() {
:
}
package_posix-xsi() {
pkgdesc+=": X/Open System Interfaces"
depends=('posix'
'util-linux' # cal ipcrm ipcs kill
'ncompress' # compress
'coreutils' # df link nl od
'psmisc' # fuser
'procps-ng' # ps
'ncurses' # tabs
'gzip' # uncompress (but not compress...) zcat
'uucp' # uucp uustat uux
# missing: cflow cxref
# missing SCCS: admin delta get prs rmdel sact sccs unget
val what
)
install=xsi.install
}
package_posix-user-portability() {
pkgdesc+=": User Portability Utilities"
depends=('posix'
'vi' # ex vi
'util-linux' # more
'inetutils' # talk
)
}
package_posix-c-development() {
pkgdesc+=": C-Language Development Utilities"
depends=('posix'
'gcc' # c99
'flex' # lex
'bison' # yacc
)
}
package_posix-software-development() {
pkgdesc+=": Software Development"
depends=('posix'
'binutils' # ar nm strip
'ctags'
'make'
)
}
# xsi.install
post_install() {
cat << '__EOF__'
warning: XSI compliance is not 100% complete, not all tools are packaged.
- The SCCS development tools are not available, but may be obtained
from the AUR in the event you believe anyone still uses it.
- The cflow package can likewise be obtained from the AUR.
- A cxref package may need to be created, if there are interested
parties.
__EOF__
}
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Killing Python 2 (v2)
On 1/2/20 7:19 PM, keenerd via arch-dev-public wrote: > On 1/2/20, Jelle van der Waa wrote: >> * rox - python2, dead and GTK2 > > Also was an easy fix. Well, the python2 part at least. > > -Kyle https://bugs.archlinux.org/task/65023 There are a couple of forks apparently, which might be worth looking into and/or asking about gtk3: https://sourceforge.net/p/rox/mailman/rox-users/thread/159e19f9-3379-c689-1034-70ec021ebf3f%40videotron.ca/#msg36271941 https://github.com/jun7/rox-filer -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Killing Python 2 (v2)
On 1/2/20 11:12 AM, Jelle van der Waa wrote: > # Remove python2 support > > * pycharm-community-edition - remove python2 support Seems reasonable to not encourage people to use python2 in an IDE these days. > * vim - remove python2 support Are there any stats on vim ecosystem plugins which use the python2 binding? Including non-packaged plugins? Because it's more annoying to disable support for python2 in something that requires recompiling the package to use it, and if we have packaged plugins which use python2 then we definitely cannot remove non-leaf functionality first. Most other things like bindings could most likely be built separately if someone really needed them... > * graphviz - remove python2 bindings or update to python3 > * notmuch - switch to python3 bindings > * libproxy - remove python2 bindings These all seem perfectly reasonable, no different from dropping any python2 leaf module that serves no useful purpose. > * many others! > > Greetings, > > Jelle van der Waa > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] libx11/xorgproto dependency
On 12/21/19 3:41 AM, Andreas Radke via arch-dev-public wrote: > With this move I've "fixed" libx11 no more depending at runtime on > xorgproto package. I think no headers belong to an end user system and > the libx11 library itself doesn't depend on it. But we also ship > libx11-devel part inside the package and this indead depends on > xorgproto headers. The libx11 .pc file clearly wants to have the headers > installed. In the past it was enough to include libx11 to also pull in > the proto headers at build time. This is now broken. Some devs call > libx11 broken though only its -devel part is. > > After some discussion on IRC these solution are possible: > > a) revert to make libx11 depend again on xorgproto headers. This is the > pragmatic way and would not need any further work. It just installs > header files to the user system that aren't needed in any way there. So > we did in the past and I don't really like it as it's not correct to me. I'm not even sure I understand the question. The current state of affairs is that the libx11 package provides two things: - the libx11 client libraries - the libx11 development headers This is per standard Arch policy to not split headers into subpackages. Part of the feature functionality of the libx11 package is broken without xorgproto installed. *only* libx11 cares about xorgproto. What makes this "wrong"? The functionality that the package is intended to provide is indeed functionality that depends on xorgproto. It's not even merely pragmatic -- it is technically correct. ... People who are sincerely bothered by the installation of 1.5MB of headers should consider optionally adding a pacman.conf NoExtract rule to not install them; on my machine, it would save me 400MB, although personally I rather like headers since I tend to use them. > b) stay with changed libx11 and add xorgproto to packages that check > for any of its headers. This needs to be done to an amount of ~300 > packages when hitting build errors over the next time. This is unambiguously wrong, unless those 300 packages actually check for xproto.pc or kbproto.pc, which seems doubtful. The fact that it requires teaching hundreds of packages far too much about libx11 internals that they don't actually depend on is pretty annoying too, yes, but I'd argue this solution is technically incorrect either way. > c) go an unusual way here and split libx11 into libx11, libx11-devel > depending on xorgproto and maybe even libx11-xcb. This is the way > distros go that support splitting libraries. It's probably the > technical correct solution but will also require packages to > makedepend on libx11-devel and save us no work. Is it the technically correct solution for just libx11, or for all packages? IMO this only makes sense if we do it consistently. Personally, the fact that Arch does *not* do this is one of the things I consider a great advantage over confusing distros like Debian. > Other distributions have chosen what they prefer. That a decision that > needs to be done downstream. > > I'd like to have either solution b) or c) in Arch to have a clear > and more "transient" build time dependency. I guess it may help us > also in the future when moving some day away from Xorg to its successor. > But if majority wants solution a) back I'm fine reverting this change. > > Please vote. > > -Andy > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] cleanup dead Xorg packages | news draft
On 12/19/19 6:05 PM, Allan McRae via arch-dev-public wrote:
>> There's no package replacing libdmx and libxxf86dga so manual
>> intervention will be needed. So here's a small news draft:
>>
>> "Xorg cleanup requires manual intervention
>>
>> "In the process of Xorg cleanup [1] the update requires manual
>> intervention when you hit this message:
>>
>> :: installing xorgproto (2019.2-2) breaks dependency 'inputproto' required
>> by lib32-libxi
>> :: installing xorgproto (2019.2-2) breaks dependency 'dmxproto' required by
>> libdmx
>> :: installing xorgproto (2019.2-2) breaks dependency 'xf86dgaproto'
>> required by libxxf86dga
>>
>> when updating, use:
>> `pacman -Rdd libdmx libxxf86dga && pacman -Syu`
>>
>> to perform the upgrade. After the update it will be safe to also remove
>> the "xorgproto" package.
>
> This why does xorgproto not provides=('inputproto' )? Then all we
> need to do is announce, update and remove.
>
> Allan
Well, this is our new fancy all-the-everything-in-one package, but the
inputproto headers / inputproto.pc won't be provided anymore...
I think conflicts would be better fitted here, but the bigger question I
have is why do we need to be so quick to remove things which apparently
work, even if they're legacy/dead, *before* we fix the downstream users?
It's hardly difficult to deprecate packages before pulling the plug on
them, in cases like this.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
On 12/14/19 1:58 PM, Robin Broda via arch-dev-public wrote:
> Hello again,
>
> We are on our way to getting zstd merged.
>
> The planned merge window for this is **2019/12/27** at around 20:00
> Europe/Berlin time.
> Several team members will be meeting at the 36c3, so we figured this is a
> good opportunity to do this,
> as it makes sure that several people are aware, ready, and together for this
> - should anything immediately explode.
>
> This has been ACK'd by anthraxx. Foxboron is also aware.
> I have been mentioning this on IRC, and discussed it with anthraxx via e-mail.
> This mail serves to formalize the plans.
>
> **There is one hard requirement on the merge happening:**
>
> All critical Arch Linux production infrastructure needs to be ready.
> The known-unsolved problems are labelled below, please see to them if any of
> you can.
> I will also take a look myself, but I do not have much involvement with these
> parts of the puzzle,
> so I would really appreciate someone with more in-depth knowledge taking a
> look.
>
> If the known issues are solved and nothing major comes up, the deployment
> will happen as planned.
>
> On 12/8/19 1:39 PM, Robin Broda via arch-dev-public wrote:
>> What still needs to be done:
>> - infrastructure:
>> - nginx rewrite rules hardcode xz PKGEXT
>> https://github.com/archlinux/infrastructure/blob/7d0ad69030982875f862bc4916629ac3a74d1c49/roles/archive/templates/nginx.d.conf.j2#L32-L35
>> - archive config(?) hardcodes PKGEXT
>> https://github.com/archlinux/infrastructure/blob/7d0ad69030982875f862bc4916629ac3a74d1c49/roles/archive/templates/archive.conf.j2#L15
>
> Unsolved: This needs fixing. I would *really* like someone from devtools to
> take a look at this, but if unsolved i will also attempt to fix it.
>
>> - archivetools: https://github.com/archlinux/archivetools/issues/6
>
> Unsolved: This needs fixing. If nobody else gets to it, I'll see to it myself.
Oof, this looks a bit confusing. It's using the $PKGEXT variable as both
a /usr/bin/find glob pattern and a sed injection (counting the number of
characters and trimming them off using .{number} !)
See https://github.com/archlinux/dbscripts/pull/4 for inspiration in
working around this misuse.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Proposal: Build a ruleset for new packages and package quality
On 12/12/19 7:21 AM, Christian Rebischke via arch-dev-public wrote: > 5. What do we do with the existing beta and alpha packages? Are they > granted asylum? Or do we remove them, to be consistent? > > extra libmspack 1:0.10.1alpha-2 > extra qt5-webkit 5.212.0alpha3-6 qt5-webkit is a security-critical component (a browser), and upstream has not historically been good about updating the version of webkit they build on. Currently, there is a years-long effort by annulen, to fix this and get webkit back into good shape. Given a choice between no qt5-webkit, a qt5-webkit which is so ancient it's intolerably dangerous, and packaging the resuscitated annulen version, this is an acceptable exception. > community d-containers 0.8.0alpha.19-1 > extra frozen-bubble 2.2.1beta1-14 > extra hddtemp 0.3.beta15.53-1 > extra libcaca 0.99.beta19-2 > extra tsocks 1.8beta5-8 > community hydrogen 1.0.0beta1-1 I know this one too: https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/hydrogen=bf63a0be79e954863a014bb9ea23157aaf70d7c4 We needed to upgrade to the beta in order to migrate from qt4, which was in the process of being dropped, to qt5. It was not a lightly made decision. > community lablgtk3 3.0.beta6-2 > community modclean 3.0.0beta.1-1 > community sdedit 4.2beta8-1 > community sniffit 0.3.7.beta-17 > community vbindiff 3.0_beta5-1 > community wqy-microhei 0.2.0_beta-9 > community wqy-microhei-lite 0.2.0_beta-9 I'm unsure / have insufficiently researched the other cases, but I do dearly hope that their respective maintainers considered the tradeoffs before packaging an unstable release. > 6. How do we define stable packages? beta or alpha is just a human made > word. I've seen devs who said their "1.0" version is unstable and > shouldn't be used in production. Should such a software get packaged? > And what about projects who use semantic versioning (the devs said so), > but they have a 0.* prefix release? Semantic versioning defines 0.* as stable, so this is not a question. As per semantic versionining, a version indicator ending in one of the globs: -alpha* -beta* is considered an alpha or beta prerelease and therefore unstable. > 7. Another topic is a rule about "touching packages of others". In the > #archlinux-tu channel we came to the conclusion that TUs or devs should > ask the package maintainer before touching another devs/TUs package, how > do we want to handle this? Is this the consensus, or are touches without > prior question allowed? What do we do if somebody violates our rules? > etc > > 8. A few guys in the IRC pointed me to this guidelines in our wiki: > > Note: This page is only editable with Wiki-Admin/Dev Permission. > > https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_versioning > > My questions to this guidelines: > > 8.1. under which consensus where this rules defined? Are these rules the > result of a developer vote? of a leader decision? Or are they made up by > a few persons without consensus. > > 8.2 I can't find any list about punishments for violations of these > rules. > > 8.3 There is no documentation about our alpha and beta packages. I see > that there are exceptions for alpha and betas, but it's not clear for me > how these exceptions apply to the packages we have in our repositories. > > This needs to be documented, otherwise every person could push an alpha > package and just 'claim' that one of those exceptions apply for the > package and if nobody checks this claim, the package will be in the > repository. The most likely place to find out about exceptions is by reading the svntogit commit logs, which is an excellent place to store information about, well, changes made to the package, and I encourage people to make use of that fact. :) > 9. Do we consider packages, that are build from the latest git tag, as > alphas or betas? >> pacman -Ss|grep -E '\+[0-9]+\+g' Well, those don't build from "the latest git tag", they build from "the latest git commit" perhaps. Given it is not tagged upstream as a stable release, nor is it tagged upstream as an alpha or beta, it seems obvious to me that they are not alphas or betas or even stable releases... they are *-git packages. > 10. Do we need to ask software developers in the future if they consider > their project stable? It's not clear which versioning schema the devs > use, some consider their 0.1 release as unstable, some consider it as > stable. Is semantic versioning applied? Do they follow a different > schema? Semantic versioning as well as common convention states that they are stable, if upstream says that it's actually only beta quality then I encourage you to do some soul searching about whether to package it. Most software with a 0.* version will be versioned that way because "we are not ready to commit to a stable API, so any new version has the potential to change how the software works, to the same degree that a semver major version can". Alternatively, the
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
On 12/8/19 7:39 AM, Robin Broda via arch-dev-public wrote: > Hello everyone, > > Now that Zstd 1.4.4 has been out, and released into our repos as well, i > think it's time for a new status report on this. > > I re-ran the benchmarks with the new zstd, and we are hitting marginally > better times in compression & decompression in all scenarios. > > In the past few weeks, other team members and I have taken a look at our own > projects, and what would be needed to finally transition to zstd. > Notable progress: > - A news post was made by eworm, indicating that users should upgrade if they > haven't done so since September 2018 > (https://www.archlinux.org/news/required-update-to-recent-libarchive/) > - dbscripts has been updated by eschwartz to support zstd > > What still needs to be done: > - infrastructure: > - nginx rewrite rules hardcode xz PKGEXT > https://github.com/archlinux/infrastructure/blob/7d0ad69030982875f862bc4916629ac3a74d1c49/roles/archive/templates/nginx.d.conf.j2#L32-L35 > - archive config(?) hardcodes PKGEXT > https://github.com/archlinux/infrastructure/blob/7d0ad69030982875f862bc4916629ac3a74d1c49/roles/archive/templates/archive.conf.j2#L15 > - potentially more things, someone from devops should take a look > - archivetools: https://github.com/archlinux/archivetools/issues/6 > - namcap? some files refer to a hardcoded .xz, though jelle concluded that > this is irrelevant > - someone with namcap knowledge should look into this namcap is indeed irrelevant. It hardcodes 'xz' in three places: - the README - the makepkg.conf used for building packages within the namcap self-test suite - the case statement in the main script, which detects files ending in .xz, .zst, and other valid extensions, in order to choose the right decompressor before finally handing the uncompressed .tar to namcap itself > - srcpac (is this still used?) > - hardcodes 'pkg.tar.?z' Definitely not still used. :p It hasn't been developed in 5 years. It also still hardcodes the `abs` program. > - kde-build hardcodes pkg.tar.xz > https://git.archlinux.org/kde-build.git/tree/build-packages?id=cda04698f4064cb87d427ccb3bdf954f127c65f7#n35 > - devtools: > - hardcodes 'pkg.tar?(.?z)' > https://git.archlinux.org/devtools.git/tree/lib/common.sh?id=2c611d20bdd04feae6ab32a7ef8947aeb4118604#n155 > - more than one occurrence of this iirc > > There might be things I've missed. > I encourage every Arch Linux project maintainer to check their own code for > hardcoded xz extensions, you probably know your code best. > > > As soon as these things are out of the way, we can proceed with the proposal. > > The changeset proposal remains on these settings: > PKGEXT='.pkg.tar.zst' > COMPRESSZST=(zstd -c -T0 --ultra -20 -) > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [arch-devops] soyuz (pkgbuild.com) server move to homedir.archlinux.org
On 11/18/19 1:34 AM, Sven-Hendrik Haase via arch-devops wrote: > Hi all, > > I set up a new Hetzner VPS that is going to become our new > homedir/public_html server available to all TUs and Devs like soyuz was. We > decided to decommission soyuz and put the public_html stuff on its own > server for security reasons, to cut costs, and so that we can > compartmentalize further. [...] > If you had stuff hosted in the public_html of soyuz, I'd ask you to > transfer stuff over to the new box which is already reachable at the names > pkgbuild.com (you'll get an SSH error because of this) and > homedir.archlinux.org. Please check if you can throw away some old > stuff/junk that you might not necessarily need on the new server. Reminder for those who forgot how they initially made their homedir accessible: setfacl -m 'u:http:x' "$HOME" And make sure that public_html/ has granted chmod o+rX permission for the http user, and, optionally, that any super secretive files directly under $HOME are chmod o-rwx to prevent the http user from guessing they are there and attempting to read them by name. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Reproducible builds progress and the upcoming rebuild of [core]
On 11/14/19 12:21 PM, Robin Broda via arch-dev-public wrote: > On 11/13/19 3:46 AM, Allan McRae via arch-dev-public wrote: >> To keep this momentum going, it would be great to rebuild every package >> in [core] using makepkg from pacman-5.2+. That way we can test which >> packages are actually reproducible and work towards fixing those that >> are not. So be prepared for almost the entire repo to hit [testing] >> soon, and get your sign-off shoes on! >> > > Hmm, what do you think about postponing this until we roll out zstd, > which should be somewhat soon? > > As i don't think we're gonna rebuild everything for zstd, this would > be a great opportunity to get both of these things done at once. Bit too late for that, I think. :p Anyway, there are no major downsides to letting zstd phase in gradually. OTOH reproducible builds are pretty important, so we want those ASAP, and we also want to get more testing for our reproducer tools. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
On 11/12/19 1:24 PM, Sébastien Luttringer wrote: > On Mon, 2019-11-11 at 15:41 -0500, Eli Schwartz via arch-dev-public wrote: >> On 11/10/19 9:54 PM, Sébastien Luttringer via arch-dev-public wrote: >> As I said above, the documentation for kernel-install is pretty clear on >> its expected usage. It's a one-stop shop, it executes mkinitcpio or >> whatever other plugin you've installed for generating an initramfs, and >> it's totally 100% independent of the mkinitcpio hook. > > Hi Eli, > > Let me first agree on the clarity of kernel-install documentation. Its goal is > well summed in the man page NAME section: "Add and remove kernel and initramfs > images to and from /boot. > >> ... >> >> Also, yes, kernel-install mandates the use of systemd-boot. > No, kernel-install doesn't mandate use of systemd-boot. > It's a modular framework to make your machine bootable. > The default plugin, install kernel for systemd-boot which is different. The script /usr/bin/kernel-install mandates systemd-boot, because it detects the directory to install the kernel to by looking for a systemd-boot config. I guess if you have both then it will still work. If /boot/efi is your EFI partition mountpoint, but it is a 2mb partition (it is on my system, because it contains exactly one file, that being grubx64.efi), then this will be detected as the root install location of your kernels. My kernels are installed to a btrfs partition that does not conform to systemd-boot's logic. This is supported by both grub and rEFInd. > Since 2014, I use kernel-install[1] to manage kernel upgrades on over than 300 > Arch servers. There is regular Arch kernels, custom versioned kernels, some > are > booted with grub (uefi or not) others with systemd-boot. > >> Meanwhile, mkinitcpio's presets and the kernel file which was >> historically installed by the linux package install directly to: >> >> /boot/vmlinuz-linux >> /boot/initramfs-linux.img > An Arch plugin of few lines could easily put the files in our historical > location. This are just examples [2][3]. > >> Under no circumstances can we unilaterally remove mkinitcpio presets and >> switch to kernel-install without a mandatory manual intervention for all >> (or most) archlinux users. > We can easily switch to kernel-install, without user intervention, as it was > done with pacman hooks. Switching from mkinitcpio is another topic. The kernel-install hook you linked to seems to create two copies of each installed kernel, in a filesystem that is very commonly quite small in size. This is fine if you opt into it, but I don't consider this to be "no manual intervention" grade quality. It also runs mkinitcpio manually, without respecting mkinitcpio.d presets, so if anyone relies on something configured into those presets, then automatically switching from using mkinitcpio via the current pacman hook (which thus far has only moved from one package to another, but still does the same thing once you've migrated to the latest mkinitcpio package), to using mkinitcpio via kernel-install, represents a *behavior change*. Having kernel-install do the potential upgrade path of: - move over the kernel - execute the mkinitcpio preset - copy /boot/initramfs-linux.img to its special directory - run grub-mkconfig to configure a one-to-one copy of the non kernel-install initramfs/kernel for booting, when the originals still work flawlessly despite not having been cp'ed into a kernel-install specific directory means that you're moving lots of stuff into kernel-install, then not actually using it. It means using kernel-install for the sake of using kernel-install, rather than because it fundamentally handles performing a single 'cp' command better than a custom hook. It's a lot of effort to go to if you're not actually going to buy into kernel-install's intended use case, which is "we hardcode systemd-boot into the non-configurable part of the tool". It also depends on running grub-mkconfig. I will not install or update to any version of any package that automatically modifies my grub.cfg without my consent, as it absolutely will break my boot. I never used grub-mkconfig, because I consider it conceptually broken by design (it tries to be way too clever for its own good, doesn't handle corner cases properly, and is a nightmare to debug), haven't configured its obtuse configuration file to work with my system, etc. I've written quite a bit of wiki documentation for using grub, from scratch, because none of the current documentation is any good, and all of it tells you to use grub-mkconfig (which as you may have noticed at this point, I have very biased and emotional feelings about): https://wiki.archlinux.org/index.php/User:Eschwartz/Grub#Configuration Moving beyond grub. Should we also provide kernel-install plugins
Re: [arch-dev-public] New kernel packages and mkinitcpio hooks
On 11/10/19 9:54 PM, Sébastien Luttringer via arch-dev-public wrote:
> Nice to see that moving forward. It is a smart to move pacman installed kernel
> out of /boot.
> Why do you rely on mkinitcpio (or later dracut) to install them in /boot
> instead of the systemd kernel-install logic?
As I said above, the documentation for kernel-install is pretty clear on
its expected usage. It's a one-stop shop, it executes mkinitcpio or
whatever other plugin you've installed for generating an initramfs, and
it's totally 100% independent of the mkinitcpio hook.
Interested parties who would like to see kernel-install in use should
mask the *standalone* mkinitcpio hook, not extend it to also call
kernel-install. You'd be replacing the current infrastructure from
scratch, not adding kernel-install to the mix.
On compatibility:
kernel-install documentation mandates that your boot partition will be
autodetected based on filesystem structure, with the candidate options
being:
- /efi
- /boot/efi
- /boot
and mandates that the subdirectory $MACHINE_ID/$KERNEL_VERSION/ be used
for all installation of relevant files. kernel-install will additionally
autogenerate a systemd-boot loader/entries/*.conf with a boot menu
option it has determined is in the best interest of the user. (Think
grub-mkconfig, but for systemd-boot.)
Also, yes, kernel-install mandates the use of systemd-boot. Your kernel
is installed into a filesystem directory structure which is not
supported by grub-mkconfig's autodetection, and which uses continually
changing paths which encode the kernel version. There is no unversioned
kernel installed, so you cannot write a bootloader config once and then
let that keep on being used. Therefore you must autogenerate a
bootloader configuration *somehow*, and it is either use the
systemd-boot one which kernel-install installs, or write your own
generator script.
Meanwhile, mkinitcpio's presets and the kernel file which was
historically installed by the linux package install directly to:
/boot/vmlinuz-linux
/boot/initramfs-linux.img
Under no circumstances can we unilaterally remove mkinitcpio presets and
switch to kernel-install without a mandatory manual intervention for all
(or most) archlinux users. It seems more polite to keep the status quo
and work on making this a user-configurable choice (it really seems like
they can coexist in the wider archlinux community just fine), and
perhaps giving preferential status for ${bootloader_of_the_day} in the
installation guide.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
On 9/3/19 4:47 AM, David Runge wrote: > Not that it is of our direct concern, but qt5-webengine seems to suffer > from unresolved questionable licensing issues, which is why e.g. > Parabola doesn't package it [1]. I don't know the specifics, but assume, > that it is due to the Chromium license [2]. > > Best, > David > > [1] https://www.parabola.nu/packages/?q=qt5- > [2] https://github.com/qt/qtwebengine/blob/5.12/LICENSE.Chromium I mean, if we're concerned about that we should remove the chromium package first, *then* remove qt5-webengine (and electron). Since it is a complex issue, I will mostly drop links and expect interested people to read up on it, rather than giving a summary myself. The GNU FSDG considers chromium to be "not provably free": https://libreplanet.org/wiki/List_of_software_that_does_not_respect_the_Free_System_Distribution_Guidelines#chromium-browser Original chromium project bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=28291 Parabola meta-bug tracking their general stance on chromium and affected packages: https://labs.parabola.nu/issues/1167 What Qt developers think about this: https://bugs.kde.org/show_bug.cgi?id=374808#c4 https://lists.qt-project.org/pipermail/qtwebengine/2017-January/000409.html -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
On 8/13/19 12:05 PM, Eli Schwartz wrote: > On August 13, 2019 3:22:39 AM EDT, Jan Alexander Steffens wrote: >> Assuming that WebEngine will not be the only consumer of .bdic >> dictionaries, how about putting them in /usr/share/bdic, and then >> either patching sources to use that dir or linking whatever >> engine-specific dictionaries there? > > I doubt much of anything uses this other than chromium derivatives. I > have no idea how chromium handles this and couldn't find a packaged > .bdic file to base assumptions on. > > I similarly have no clue what electron's story is. > > The grammalecte package does have _dictionaries/*.bdic in its python > site-packages datadir. I think that probably somehow ties into kde > things that use qt5-webengine. > >> We could also put them with the other dictionaries into >> /usr/share/hunspell, assuming that won't cause problems. > > I don't think it will cause problems but I also don't think it will > help. Things that expect hunspell dicts won't expect chromium bdics > to be there and won't use them. And qt5-webengine won't look there. > Maybe if they added support for that, it would make sense. Status update: after discussion on IRC, I was able to convince heftig that this is indeed unnecessary (to try to reorganize the final installation locations of these dictionaries). ... I've gotten several positive responses and no negative ones so far. Although it's been noted that it might be nice to have a more lightweight convert tool packaged, I think for now we can stick with the one in qt5-webengine. Anyone else have any last-minute objections? Should I create a TODO list for all our dictionary packages? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
On August 13, 2019 3:22:39 AM EDT, Jan Alexander Steffens via arch-dev-public wrote: > On Tue, Aug 13, 2019 at 9:04 AM Bartłomiej Piotrowski via > arch-dev-public < > arch-dev-public@archlinux.org> wrote: > > I'd go with updating all packages to ship the converted files. > > Cluttering /usr with untracked files doesn't sound good. > > Yeah, I agree. I think we should package convert_dict from the > Chromium > sources as a new package to makedepend on. Do we need that, really? We could just splitpkg the one in qt5-webengine as it only links to QtCore, and that would at least save on webengine in a build chroot. But no users actually suffer because of large makedeps. > Assuming that WebEngine will not be the only consumer of .bdic > dictionaries, how about putting them in /usr/share/bdic, and then > either > patching sources to use that dir or linking whatever engine-specific > dictionaries there? I doubt much of anything uses this other than chromium derivatives. I have no idea how chromium handles this and couldn't find a packaged .bdic file to base assumptions on. I similarly have no clue what electron's story is. The grammalecte package does have _dictionaries/*.bdic in its python site-packages datadir. I think that probably somehow ties into kde things that use qt5-webengine. > We could also put them with the other dictionaries into > /usr/share/hunspell, assuming that won't cause problems. I don't think it will cause problems but I also don't think it will help. Things that expect hunspell dicts won't expect chromium bdics to be there and won't use them. And qt5-webengine won't look there. Maybe if they added support for that, it would make sense. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: PGP signature
Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
On August 13, 2019 3:03:59 AM EDT, "Bartłomiej Piotrowski via arch-dev-public" wrote: > I'd go with updating all packages to ship the converted files. > Cluttering /usr with untracked files doesn't sound good. I agree, that's my preferred option too -- but I need buy-in from all hunspell-* maintainers, hence the mail. :D Failing that I'd go with the hook since it's the simplest way to efficiently do this without requiring me to maintain 34 new packages containing trivial modifications of other packages, something I do *not* want to do. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: PGP signature
Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
On August 13, 2019 5:17:27 AM EDT, Florian Bruhin wrote: > Hey, > > My $0.02 as qutebrowser maintainer (off-list because I can't send to > arch-dev-public): Forwarded back to a-d-p with inline comments. :) > On Mon, Aug 12, 2019 at 07:50:44PM -0400, Eli Schwartz via > arch-dev-public wrote: > > QtWebEngine supports spellchecking: > > https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker > > > > However, they have helpfully decided (steered by upstream chromium) > to > > *not* use hunspell dictionaries, and instead to use... hunspell > > dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as > > ".bdic" files, because this is supposedly "more efficiently read by > > chromium". > > The actual spell checking is implemented inside Chromium, all > QtWebEngine does > with the dictionaries is passing them to Chromium. I don't think > they're happy > with bdic files either, but the alternatives aren't really an option > (completely reimplementing spell checking support by patching their > copy of > Chromium, with a lot of added friction each time they want to update > their > Chromium snapshot). > > So it pretty much boils down to "blame Google/Chromium" ;) Yeah, but I still wanna blame them for npt patching it for the purpose of integrating well. :p > > (Actually QtWebEngine's spell-checking infrastructure is entirely > > willing to read dictionaries in /usr/bin/qtwebengine_dictionaries > before > > looking in /usr/share because clearly they've put great thought into > how > > this is all supposed to work on a conceptual design level especially > for > > distro packaging.) > > Agreed this doesn't make much sense for Linux distributions. It > happens because > it looks next to the executable, which probably *does* make a lot of > sense for > Windows, macOS, embedded scenarios, bundled apps, etc. It doesn't help > much for > distributions, but it also doesn't hurt. > > > So I have a program -- pageedit -- which just added spellchecking > > support via qtwebengine in the latest release, and I would like to > > support that. And I don't want to see people being personally > > responsible for installing their own stuff in /usr/share. While I'm > at > > it, Morten (Foxboron) pointed out to me that qutebrowser also > supports > > spellchecking, and it currently provides a user script which > downloads > > preconverted dictionaries from chromium's git repository into > > $HOME/.local/share/qutebrowser/ ... because there's apparently no > > guidance or precedent for actually distributing these dictionaries. > (In > > fact, currently only Fedora seems to make these dictionaries > available > > to users.) > > Oh, I didn't know Fedora packages them! I opened a qutebrowser issue > too: > https://github.com/qutebrowser/qutebrowser/issues/4966 > > > It's possible to convert them yourself, using the > > qwebengine_convert_dict tool shipped in the qt5-webengine package. I > > think it would be nice if users were able to obtain these > dictionaries > > properly, but I'm not positive what the best way would be. Ideas: > > > > - Ship a pacman hook to convert whatever the user has installed, > > implemented via the following libalpm script and hooks: > > https://paste.xinu.at/m-ydTjU/ > > - make every hunspell-* package makedepend on qt5-webengine and > produce > > those dictionaries > > - same thing but also make split packages for basically a tiny data > file > > - force users to install an out of date AUR package not kept in sync > > with hunspell-* (this one is just a joke) > > > > The advantage of a hook is that users with webengine installed > > automatically get magic google-approved dictionaries corresponding > to > > the hunspell dictionaries they have installed. > > > > The advantage of modifying each hunspell-* package is saving about > 0.38 > > seconds per file at installation time, plus users don't have weird > > untracked files in some cloistered dir in /usr/ > > > > The advantage of doing anything other than possibility #3 is "avoid > > adding another 34 packages to the repositories, which users need to > > manually install in addition to the other dictionaries they > explicitly > > installed". > > Depending on how big those dictionaries are, they all could be in a > single > qt5-webengine-dicts package? Though I guess they aren't much smaller > than the > hunspell ones, and there probably was a reason those were split. Well, they are different source code with different version
Re: [arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
On 8/6/19 3:22 PM, Eli Schwartz wrote: > BTW in addition to haxe and lablgtk2, there is also lablgl, which I need > for llpp -- but I don't really know ocaml as a programming language so I > don't know if that can be easily migrated to something new; also, it > seems to be kind of "feature frozen" (read: dead). > > llpp also has a makedepends on camlp4 but that's an accident, so I fixed > it in svn trunk. [...] > So the only blocker would seem to be lablgl, which is my package used as > a makedepends for one other package. Again, I don't really know much > about ocaml, but it *seems* like changing the makedepends to camlp5 and > using the following sed line in prepare() lets it successfully build: > > sed -i 's/camlp4/camlp5/g' \ > LablGlut/src/Makefile \ > Togl/src/Makefile \ > src/Makefile > > > Would love some confirmation if this is right. Update: upstream moved to github and released lablgl 1.06 with support for camlp5 and architected so that even that is only necessary when changing the source code (so neither one is needed in the PKGBUILD). As such, I've dropped the dependency and updated the package. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
QtWebEngine supports spellchecking: https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker However, they have helpfully decided (steered by upstream chromium) to *not* use hunspell dictionaries, and instead to use... hunspell dictionaries stored in /usr/share/qt/qtwebengine_dictionaries/ as ".bdic" files, because this is supposedly "more efficiently read by chromium". (Actually QtWebEngine's spell-checking infrastructure is entirely willing to read dictionaries in /usr/bin/qtwebengine_dictionaries before looking in /usr/share because clearly they've put great thought into how this is all supposed to work on a conceptual design level especially for distro packaging.) So I have a program -- pageedit -- which just added spellchecking support via qtwebengine in the latest release, and I would like to support that. And I don't want to see people being personally responsible for installing their own stuff in /usr/share. While I'm at it, Morten (Foxboron) pointed out to me that qutebrowser also supports spellchecking, and it currently provides a user script which downloads preconverted dictionaries from chromium's git repository into $HOME/.local/share/qutebrowser/ ... because there's apparently no guidance or precedent for actually distributing these dictionaries. (In fact, currently only Fedora seems to make these dictionaries available to users.) It's possible to convert them yourself, using the qwebengine_convert_dict tool shipped in the qt5-webengine package. I think it would be nice if users were able to obtain these dictionaries properly, but I'm not positive what the best way would be. Ideas: - Ship a pacman hook to convert whatever the user has installed, implemented via the following libalpm script and hooks: https://paste.xinu.at/m-ydTjU/ - make every hunspell-* package makedepend on qt5-webengine and produce those dictionaries - same thing but also make split packages for basically a tiny data file - force users to install an out of date AUR package not kept in sync with hunspell-* (this one is just a joke) The advantage of a hook is that users with webengine installed automatically get magic google-approved dictionaries corresponding to the hunspell dictionaries they have installed. The advantage of modifying each hunspell-* package is saving about 0.38 seconds per file at installation time, plus users don't have weird untracked files in some cloistered dir in /usr/ The advantage of doing anything other than possibility #3 is "avoid adding another 34 packages to the repositories, which users need to manually install in addition to the other dictionaries they explicitly installed". ... Prior art: Fedora uses rpm post-install filetriggers: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/master/f/qt5-qtwebengine.spec#_489 Gentoo has a proposal for a package that runs the conversion tool on each file the user has installed in /usr/share/hunspell/ and packages the results. ... Thoughts on the best way forward to make these dictionaries available on Arch Linux? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [arch-dev] State of OCaml-Update (stuck by deprecation of camlp4)
On 8/6/19 1:21 PM, Jürgen Hötzel wrote: > Hi, > > Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08. > > But some well known packages depend on this preprocessor. E.g. :Haxe, > lablgtk2 (therefore also: Unison and Coq). > > I don't see that these projects will be migrated to camlp5 or ppx in the > near future. Therefore there are only 2 options from my point of view: > > 1. OCaml-4.07 and Ocaml >= 4.08 in [EXTRA]. > 2. removal of Haxe, lablgtk2, Unison and Coq. > > I prefer 1. What do you think? > > Same issue discussed on Debian Bug Tracker: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933722 According to https://github.com/garrigue/lablgtk/pull/67 lablgtk2 only needs camlp4 to generate some source distribution files which upstream indicates they distribute, so hopefully it can be built without that makedepends and against newer ocaml? According to https://github.com/HaxeFoundation/haxe, haxe alreeady migrated to camlp5 in git master. BTW in addition to haxe and lablgtk2, there is also lablgl, which I need for llpp -- but I don't really know ocaml as a programming language so I don't know if that can be easily migrated to something new; also, it seems to be kind of "feature frozen" (read: dead). llpp also has a makedepends on camlp4 but that's an accident, so I fixed it in svn trunk. If swig really needs camlp4 for its check function, we can probably just disable that testsuite component instead of holding back the whole repo. ... So the only blocker would seem to be lablgl, which is my package used as a makedepends for one other package. Again, I don't really know much about ocaml, but it *seems* like changing the makedepends to camlp5 and using the following sed line in prepare() lets it successfully build: sed -i 's/camlp4/camlp5/g' \ LablGlut/src/Makefile \ Togl/src/Makefile \ src/Makefile Would love some confirmation if this is right. Given all these facts, it seems quite feasible to update ocaml, if not today then soon. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] New ideas for notifying users about (minor) changes
On 7/29/19 6:47 PM, Christian Rebischke via arch-dev-public wrote: > Hello everybody, > I got assigned to this issue here: > > https://bugs.archlinux.org/task/62823 > > The users would like to have a notice in pre/post install/upgrade > notifications via pacman .install files. > > I am not a fan of spamming such news via pacman and I think the > installation/upgrade process should be clean of such messages, but I > don't have access to the news tool on our website as well. It's not unreasonable to add such post_upgrade messages in cases where you want to ensure the user sees the message. > So what can we do here? I am a big fan of Gentoos Newsletter feature[1]. > It would be super awesome if we would have a tool such like `archnews > ` to retrieve NEWS about a certain package from an > endpoint. This endpoint should be controllable by every maintainer (devs > and TUs included). I discussed this with coderobe a bit and we came to > different solutions: > > > Solution 1: a NEWS file inside of the package repository: > > > A maintainer could upload a `NEWS` file into the package repository and > then a client could grab this information directly via downloading the > file from: > > https://git.archlinux.org/svntogit/community.git/plain/trunk/NEWS?h=packages/0ad > > Pro: > + every maintainer could control this NEWS file easily via our current > tools. > + It's easy to download the NEWS files (we can expect new tools from the > community) > > Con: > - We bloat our repository We already have this feature. Add the following to the PKGBUILD, and rebuild it: changelog=NEWS Now, the user may at any time run the following command for an installed package: $ pacman -Qc pkgname Changelog for pkgname: [contents of NEWS file] Changelogs are pacman's #1 unused feature. Do note, however, that these messages are opt-in and thus users won't see them unless they know they need to. As such, it makes sense for a "changelog", but its utility as a news bulletin may be in doubt. > Solution 2: commit messages as NEWS > > > The maintainer could/should put such news into the latest commit > message. > > Pro: > + no extra file > + using existing infrastructure > + one workflow > > Con: > - I need an actual change in the repository to create a new NEWS object > (If we have a look on my example with strongswan, I would need to add > something in the PKGBUILD to make a new commit to make a new NEWS > object) > - It's more difficult to get with tools. The user needs to checkout the > repository (in solution 1 it can be just a curl call) People should already use decent commit messages. But we should *not* abuse them to contain information that is not about what the commit did, but instead about how users should respond to the new package release. That duplicates the functionality of a changelog without offering a compelling use case that it would be better at. It additionally makes commit messages *worse* at effectively doing the job of a commit message. > Solution 3: A webapp on news.archlinux.org with a fancy UI > --- > > This solution would be the most work. We could have a new webapp (such > like our security tracker) just for NEWS objects. Every maintainer > should have access to their assigned packages. > > Pro: > + Fancy > + Easy to use > + API endpoints > > Con: > - A lot of work > - That duplicates the functionality of a changelog without offering a compelling use case that it would be better at. The only thing that would be possible with this, that a changelog cannot do, is tell you about the news for a package you don't have installed, but I assume you don't actually care about that. > I would go for solution 1. What would be interesting to know for me: > > 1. Do you think that we actually *need* such a tool? > 2. Would you use such a tool/workflow? > 3. Do you have other/better ideas? I do not thing we need such a tool, and if we had one, I would refuse to use it -- instead opting to use the changelog feature. I would still use post_upgrade messages that use vercmp to make sure they run exactly once, to alert users to important issues surrounding a new release that I do not want them to accidentally miss. See community/sigil for an example of using post_upgrade for warnings that I want all users to see. See community/fanficfare for an example of using changelogs to make the list of changes in the package, more accessible. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] bringing vivaldi browser to community
On 6/2/19 2:59 AM, Ike Devolder wrote:
> On Sat, 2019-06-01 at 22:11 -0400, Eli Schwartz via arch-dev-public
> wrote:
>> On 6/1/19 5:43 PM, Allan McRae via arch-dev-public wrote:
>>> On 2/6/19 1:53 am, Ike Devolder via arch-dev-public wrote:
>>>> On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
>>>>> You don't seem to
>>>>> explain why you need to ask in your email.
>>>>
>>>> Because it is proprietary and I explain that now there is a valid
>>>> reason compared to 3 years ago where there was practically no
>>>> difference between vivaldi, chromium and opera.
>>>>
>>>
>>> Does the license allow us to have it in the repos? After a quick
>>> look,
>>> I'd say no.
>>
>> The license for the AUR package appears to be somehow extracted using
>> /usr/bin/strings from one of the binary files in the software
>> download.
>>
>> Assuming it's the same as the one here:
>> https://vivaldi.com/privacy/vivaldi-end-user-license-agreement/
>>
>> It's absolutely illegal to redistribute it. As per the pinned comment
>> on
>> the AUR package, it is also available and illegally redistributed as
>> a
>> repackaged pacman package here: https://repo.herecura.eu/
>> This should probably be removed too.
>>
>> Note: there are other proprietary packages shipped in the Arch repos,
>> but on the unusual occasion where we deem it fitting to provide such
>> software, we have written authorization from the rights-holders to do
>> so.
>> As far as I can tell, that is not the case here. If and when it is
>> the
>> case here, that permission can be added to the
>> /usr/share/licenses/${pkgname}/ directory of the vivaldi package in
>> the
>> AUR, to signify that the prebuilt packages are legally
>> redistributable,
>> either in personally hosted repos or [community].
>>
>> See the teamspeak3 package for an example implementation.
>> https://git.archlinux.org/svntogit/community.git/tree/trunk/PERMISSION.eml?h=packages/teamspeak3
>>
>> ...
>>
>> Just because we are not an FSDG distribution which prays at the altar
>> of
>> Richard Stallman doesn't mean licensing is some sort of silly joke
>> that
>> no one cares about.
>>
>> And I don't think it makes sense to say this matters less, if it's
>> being
>> distributed from someone's personal repo instead of from a multi-
>> member
>> organization.
>>
>
> If that's what it requires, I can get a written consent we can re-
> distribute vivaldi. I asked them before putting it in my personal repo,
> if I was allowed to do that.
Cool -- if you have that permission, then there's no reason not to put
it in the AUR package too, though. :)
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Proposal for a new organisation structure
On 6/1/19 7:08 PM, Christian Rebischke via arch-dev-public wrote: > Hello everybody, > > > DISCLAIMER: > Sorry for the huge mail, I didn't thought it would get so long. If you > feel attacked/angry or whatever about it, take a deep breath before you > answer. I hope for a constructive discussion without personal attacks. > > > inspired by the last thread about moving proprietary software to > community, our general problem of getting more people involved in Arch > Linux and the (for me) chaotic organisation structure and hierarchy I > would like to propose a discussion about changes. > > Please don't see this thread as an attack on your current position or > whatever. > > I would like to propose a more democratic, simplified and more > contribution friendly approach for our current hierarchy and > organisation structure. > > At the moment we have the following three Groups (If I miss something feel > free to correct me): > > - Devs > - Trusted Users > - Support Staff > > These three groups have the following 'features' and tasks: > > - Devs: > - Tasks: > The developers care about [core] and [extra] repositories, they form > a direction for the whole project 'arch linux' and they seem to have a > veto-permission for TU decisions. Furthermore they have access on most > infrastructure and they are maintaining/developing the core software > like pacman. Some devs also care about trademarks, legal requests > and finance or community events. Core software like pacman... no one maintains pacman except for Dave, Allan, and Andrew. Being a dev does not give you authority to maintain or develop core software, being the appointed caretaker of core software gives you that authority. I'm a frequent contributor to pacman, despite being only a TU. I, a TU, am also the maintainer and developer of a different core infrastructure -- dbscripts. This is mainly because I volunteered to do so. Jouke Witteveen is the maintainer and developer of netctl, which is apparently our blessed networking utility and even distributed in [core] and as part of the official installation media and install process (not to knock his great work, but I still don't understand this choice :p as my attempted bug report to add networkmanager to the archiso should prove). Jouke is neither a TU nor a Dev, his only responsibility to the Arch Linux project is as the netctl project lead. On the topic of infrastructure, there are currently 37 Developers, and a mere 9 of them have access to the infrastructure. I'm not positive about this, but think one or more of these 9 may have been there since before being accepted as a Dev. The 10th person with infrastructure access does happen to be a forum moderator, but is not a Dev or a TU, and seems to be happy with his current level of contribution (which is admittedly mighty). > Therefore I would like to propose a discussion around the following > things: > > > 1. Simplified repositories > > Currently we have [core], [extra] and [community]. These three > repositories are there, because they have grown to this structure over > time. At the moment I don't see any real meaning for the split of [core] > and [extra]. So one suggestion would be to either: > - merge [extra] and [core] > - or use [extra] for a new purpose, like for example a proprietary > repository, for all proprietary software. (I know that this is not > possible for all packages, because we have binary blobs in device > drivers and kernel modules). Nope nope nope. The division between [core] on the one hand and [extra]/[community] on the other, is described here: https://wiki.archlinux.org/index.php/Official_repositories#core And there's pretty good and inviolable reasons for the split -- it makes no sense to try merging it with anything else. It's unrelated to who has access to package there -- but it does make some sense to restrict packaging for [core] to the core project Devs. Whether the split between [extra] and [community] makes sense is another topic, one which could, I guess, be argued. In that case, it's a lot more accurate to describe it as "two repos that are mostly similar in terms of what software goes there, with nebulously defined boundaries except for the former being restricted to only Devs". > 2. Repository access > > At the moment a TU can access all packages inside of the [community] > repository. Therefore they are able to modify packages in a good or bad > manner. This can have nice effects and bad effects, how the past has > shown to use, such as: > - rapid updates in case of security vulnerabilities (good effect) > - updates of packages, because somebody thought it needs an update, > but the real reason for the delay was a bug inside of the new > version of a software (bad effect) I'd *probably* argue that "somebody thought it needs an update" is not really a wonderful reason to bump someone
Re: [arch-dev-public] bringing vivaldi browser to community
On 6/1/19 5:43 PM, Allan McRae via arch-dev-public wrote:
> On 2/6/19 1:53 am, Ike Devolder via arch-dev-public wrote:
>> On Sat, 2019-06-01 at 21:30 +1000, Allan McRae wrote:
>>> You don't seem to
>>> explain why you need to ask in your email.
>>
>> Because it is proprietary and I explain that now there is a valid
>> reason compared to 3 years ago where there was practically no
>> difference between vivaldi, chromium and opera.
>>
>
> Does the license allow us to have it in the repos? After a quick look,
> I'd say no.
The license for the AUR package appears to be somehow extracted using
/usr/bin/strings from one of the binary files in the software download.
Assuming it's the same as the one here:
https://vivaldi.com/privacy/vivaldi-end-user-license-agreement/
It's absolutely illegal to redistribute it. As per the pinned comment on
the AUR package, it is also available and illegally redistributed as a
repackaged pacman package here: https://repo.herecura.eu/
This should probably be removed too.
Note: there are other proprietary packages shipped in the Arch repos,
but on the unusual occasion where we deem it fitting to provide such
software, we have written authorization from the rights-holders to do so.
As far as I can tell, that is not the case here. If and when it is the
case here, that permission can be added to the
/usr/share/licenses/${pkgname}/ directory of the vivaldi package in the
AUR, to signify that the prebuilt packages are legally redistributable,
either in personally hosted repos or [community].
See the teamspeak3 package for an example implementation.
https://git.archlinux.org/svntogit/community.git/tree/trunk/PERMISSION.eml?h=packages/teamspeak3
...
Just because we are not an FSDG distribution which prays at the altar of
Richard Stallman doesn't mean licensing is some sort of silly joke that
no one cares about.
And I don't think it makes sense to say this matters less, if it's being
distributed from someone's personal repo instead of from a multi-member
organization.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] GCC 9 removed from [testing]
On 5/26/19 12:51 PM, Bartłomiej Piotrowski via arch-dev-public wrote: > Hi all, > > I just deleted GCC 9 and related packages from [testing] due to the > filesystem corruption bug when bcache is used[1]. You will have to -Syuu > your systems. > > People hungry for breakage can install it from [gcc9] repo I uploaded to > pkgbuild.com: > > [gcc9] > Server = https://pkgbuild.com/~bpiotrowski/gcc9/ Question: are you going to set up an archbuild alias on soyuz/dragon for this, the way you did for gcc8? (Which reminds me, those archbuild aliases still exist and could be deleted). Also please bump the pkgrel for these packages as they were currently just cp'ed from testing. dbscripts knows how to auto-reject uploaded packages built with your repo, as long as the gcc/binutils/etc. pkgver-pkgrel are new and thus do not appear in the archives. (This will not help for someone who is building against an outdated [testing] chroot, so yeah, those need to be refreshed.) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Dropping Qt4
On 4/28/19 6:44 AM, Antonio Rojas via arch-dev-public wrote:
> Hi all,
>
> Now that mumble has been ported to Qt5, I think it's time to finally
> drop Qt4, which has been EOL for 4 years. Most stuff that still depends
> on it has been dead upstream for many years. Here is a full list of
> applications (not libraries or plugins, which can be dropped once
> applications are gone):
>
> clementine - Qt5 port exists in git for years but no release - some
> distros ship a git snapshot, there's also the strawberry Qt5 fork
> fbreader - There's a patch to port to Qt5 in AUR
> https://aur.archlinux.org/packages/fbreader-qt5/
> freemat - Last released 6 years ago, there seems to be a Qt-free version
> at https://sourceforge.net/p/freemat/code/HEAD/tree/branches/FreeMat5/
> but with no activity for 2 years
> gebabbel - Last released >10 years ago, gpsbabel already provides a Qt5 UI
> gnuradio - Qt UI can be disabled until it is ported
> hydrogen - Qt5 beta version (>1 year old) available
> keepassx{,2} - We have keepass and keepassxc already
> launchy - Qt5 fork available at https://github.com/Slesa/launchy/
> openssh-askpass - can actually be compiled with Qt5
> qmpdclient - Last released 8 years ago, many alternatives available
> tipp10 - Qt5 fork available at https://gitlab.com/a_a/tipp10/
> tuxcards - Last released 9 years ago, many alternatives available
https://github.com/eli-schwartz/tuxcards port seems to be simple, ISTR
trying to ping jlichtblau and ask if this works for him.
> v4l2ucp - Last released 9 years ago
>
> I propose to move those who can to Qt5 forks, and disable the Qt5 bits
> (if possible) or completely drop the other ones. Any objections?
On the optdepends front:
i7z: Submitted PR at https://github.com/afontenot/i7z/pull/2
graphviz has the optional gvedit program, which looks like it is ported
to qt5 on master.
https://gitlab.com/graphviz/graphviz/commit/dd4ca75c2d074672b1a4967a5fc37d14ade5c6d6
Its last release is years old though.
Most other things seem to be "qt4 bindings for X", which only exist
because we build --with-kitchen-sink. I cannot fathom objections to
disabling those bits.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
On 3/25/19 12:13 AM, Robin Broda via arch-dev-public wrote: > Given that low-end systems can simply change the thread allocation to 1 or 2 > to slash the compressor memory usage as a trade-off on speed, > i don't think that is a problem. > > New changeset: > PKGEXT='.pkg.tar.zst' > COMPRESSZST=(zstd -c -T0 -20 -) Wouldn't this require allowing COMPRESSZST to be set in /etc/makepkg.conf and read by makechrootpkg? Currently makechrootpkg accepts MAKEFLAGS for the same general purpose except for the build stage. Given that zstd -T is reproducible at any level, but -20 is not, it would need to check for and reject settings that contain an invalid compression level. Alternatively, I had proposed a patch to pacman-dev which would save more information like this, and could, I suppose, be extended to cover the compression flags as well. This would allow packagers to set whatever they wanted and be fully reproducible-builds.org, even, which seems like it would solve everyone's problems. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
On 3/24/19 8:38 PM, Evangelos Foutras via arch-dev-public wrote: > On Mon, 25 Mar 2019 at 01:22, Jan Alexander Steffens via > arch-dev-public wrote: >> >> On Sun, Mar 24, 2019 at 7:35 PM Robin Broda via arch-dev-public >> wrote: >>> The required changeset is, i think: >>> PKGEXT='.pkg.tar.zst' >>> COMPRESSZST=(zstd -c -T0 -18 -) >> >> When we implement this, I would say we go with "zstd -c -T0 -" in >> pacman's makepkg.conf and "zstd -C -T0 -18 -" in the configs shipped >> with devtools. >> >> I think users that build their own local packages are more likely to >> benefit from fast compression. Anyone building with makechrootpkg for >> distribution gets the high compression level. > > That's actually really smart! We can also leave out "-T0" since the > default compression level is very fast anyway. Plus, it's already > implemented in this way in pacman git so we don't have to touch > anything there. (But, if it were to be multithreaded there as well, I > would replace zstd with zstdmt; same for devtools.) > > As far as compression level goes, I believe we should select the > highest one that doesn't have increased memory requirements during > decompression. So that would be -19. Robin makes a good case about > -18; looking at upstream's "Compression Speed vs Ratio" graph [1] I > would say -18 is preferable to -19 if we are concerned about > compression speed and memory usage (my totally unscientific > measurements show a 25% memory increase and 20% speed decrease going > from -18 to -19 when using -T4). That said, I might still opt for -19 > due to the slightly higher compression ratio; memory usage isn't too > big of an issue and the slower speed is mitigated by multithreading > (i.e.: it will still be much faster than xz). > > Assuming .zst packages have been installable as far back as September > 2018 when libarchive 3.3.3 was released, it seems to me that the > following steps can be taken: > > 1) Check if repo-add and dbscripts recognize .zst packages. repo-add checks to see if bsdtar/libarchive recognizes the file as a compressed archive containing a .PKGINFO file, and therefore, repo-add will work whenever pacman works. dbscripts whitelists the known package extensions, and I will be adding new extensions to dbscripts in tandem with a stable pacman release that contains makepkg support, so that should not be a problem either. > 2) Add "COMPRESSZST=(zstdmt -19 -c -z -q -)" to devtools' makepkg-x86_64.conf. Or just sync it with the pacman package. :p > 3) Release a test package and confirm that it's installable. (Possibly > also test with an old installation from September 2018.) You can confirm that today if you build using makepkg from pacman-git. Alternatively, try this test package I built: https://pkgbuild.com/~eschwartz/repo/x86_64/testpkg-foobar-1-1-any.pkg.tar.zst > 4) Announce the transition to the new compression algorithm and > provide a date-stamped mirror URL [2] for really old installations > without libarchive 3.3.3. We've had such transitions before, e.g. when adding hook support. IMO the transition does not need to be longer than a month, as we are substantially saying "your libarchive must be from the last six months". Arch Linux does not, AFAIK, have a general policy to support systems that have failed to update in 6 months. If anyone manages to break their system by having a very old libarchive version after a warning period provided as a news entry, we do not need to officially support anything... but I provide fully static recovery binaries for pacman, here: https://aur.archlinux.org/packages/pacman-static This should be sufficient without recourse to legacy compat packages for libarchive, or requiring users to reset their system to any give ALA date. (Notwithstanding this, many things might break in that time frame, and general advice usually seems to be to upgrade in stages using the ALA anyway.) They are available both as the (prebuilt custom repo) package "pacman-static", and as extracted binaries that can be downloaded and run directly without the need to run pacman or even decompress the file. They are verified with my PGP key. These binaries are based on a libarchive.a which is compiled with libzstd.a support, so that works too. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Python 2 modules
On 2/17/19 4:23 AM, Allan McRae wrote: > On 17/2/19 10:37 am, Eli Schwartz via arch-dev-public wrote: >> On 2/16/19 4:36 PM, Christian Hesse wrote: >>> Allan McRae via arch-dev-public on Sat, >>> 2019/02/16 11:19: >>>> Below is a list of python2 modules that are a dependency for any other >>>> package. I did not check makedepends and I did not check recursively to >>>> build this list. >>> >>> The list contains optional dependencies. How to handle these? >> >> I see no conceptual difference between optional dependencies and hard >> dependencies. Both are equally deserving of being in the repos for the >> sake of providing dependent functionality to other packages. >> > > Yes - this was a quick pass list. There is probably a bunch that should > not be removed and a lot more that could be removed... Here's the list, filtered for optdeps $ comm -23 <(curl https://www.archlinux.org/todo/die-python2-die/json | jq -r ".packages | .[] | .pkgname" | sort -u) <(expac -l '\n' -S '%o' | grep ^python2 | sort -u) > py2-leaf-no-optdeps https://paste.xinu.at/3ICChC/ I haven't checked makedepends or checkdepends as there's no convenient way to get this information from the db. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Python 2 modules
On 2/16/19 4:36 PM, Christian Hesse wrote: > Allan McRae via arch-dev-public on Sat, > 2019/02/16 11:19: >> Below is a list of python2 modules that are a dependency for any other >> package. I did not check makedepends and I did not check recursively to >> build this list. > > The list contains optional dependencies. How to handle these? I see no conceptual difference between optional dependencies and hard dependencies. Both are equally deserving of being in the repos for the sake of providing dependent functionality to other packages. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Edit /etc/php/php.ini config file in chroot
On 2/11/19 1:17 PM, NicoHood wrote: > Hi, > I am using devtools to create a package with php scripts. It uses > composer to build the package. I get the error: > > The requested PHP extension ext-iconv * is missing from your system. > Install or enable PHP's iconv extension. > > This can be solved by editing the config file and add: > extension=iconv > > The config file is only accessible by root. How do I edit this config > file within the PKGBUILD if its build by devtools? Any idea? Hmm, I didn't realize this was the VIP support channel for packaging issues, would likely expect that on aur-general. :/ I'm anyways not sure why you'd wish to exclude 99% of all arch users from answering your question. ... Like any other package, this PKGBUILD cannot invoke things as sudo or try to mess with the system. Whether it is used via devtools or not, is not the point. The standard solution is to investigate language-specific mechanisms for running with a different config file... php --help lists two likely options. Pierre has already mentioned one of them. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Improving overall experience for contributors follow up
On 2/6/19 4:16 PM, Jelle van der Waa wrote: > Hi, > > I still believe we should take some initiative on thse issues. What we > have so far is: > > - Getting involved page, not sure where it's linked from? Only findable > on the wiki. [1] Which links to a nice list of projects with an > already dedicated irc channel and mailing lists. (I was not even aware > of #archlinux-projects). > But does anyone ever find this page? I think we should at least link > it from archlinux.org. We should definitely link it from archlinux.org, maybe under "Community" in the sidebar. However, other than that I think the wiki is a good place to keep the list, as it is is more easily maintained as a wiki. > - The mozilla idea, I'm up for it? Should we host it under > whatcanidofor.archlinux.org? Note that this also requires some effort > from the team's side. We should however keep our bugtracker tidy and > maybe label "new contributor" tickets since this is quite crucial to > get new people in. I however have also some thoughts on things which > these days have no tickets, but could be worked on for example: Well, perhaps moving to bugzilla would make it easier to assign extra labels like that. :D > - revamping the Ruby guidelines. They should be as nice as the Python > ones > - Hardening our custom systemd services and creating bugs with > patches, for example grafana has hardening applied now. [5] > - Man pages for more devtools binaries. > > I'm quite sure others others have such projects on their mind which > are not publicly findable yet. (sogrep to devtools for example) sogrep as it currently exists on the soyuz build server depends on private paths to /srv/ftp I've reimplemented it here, FWIW: https://github.com/eli-schwartz/dotfiles/blob/master/bin/sogrep To go with: https://github.com/eli-schwartz/dotfiles/blob/master/bin/pkg-list-linked-libraries Problem is I'm not sure either one strictly belongs in devtools. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Proposal: minimal base system
On 2/5/19 4:31 PM, Gaetan Bisson via arch-dev-public wrote: > Bruno, > > We all seem to agree that [base] plays no satisfactory role in its > current state, so I think Allan definitely has a point: let us first > turn [base] into something useful, and only then wonder if we need > something more. > > > [2019-02-05 14:38:26 +0100] Bruno Pagani via arch-dev-public: >> Le 05/02/2019 à 12:54, Allan McRae a écrit : >>> If someone knows they want to set up logical volumes and drive >>> encryption, then they know enough to install lvm and cryptsetup. Same >>> with jfsutils, xfsutils. So I don't think they should be in the base >>> group (e.g. I would not call jfsutils a standard tool). >> >> Maybe. As I said in my answer to Bartłomiej, I don’t know if beginners >> know enough things to install what they need beyond the minimum system, >> or if they just read the wiki about doing this or that, which might >> assume they have the current base group installed. > > Then the wiki should just be updated to say: "first, install jfsutils." > It's up to the wiki to document the project, not up to the project to > follow the wiki's rule. > >>> If we remove the excess from base, then we are down to a very small >>> difference between that and archlinux-system. Only e2fsprogs, man, and >>> an editor different? >>> >>> So I see the proposed archlinux-system group being essentially what base >>> should be. >> >> That is because you see base as the minimal system. > >> So I’ll turn this >> differently: do you have objections against having, outside of the >> minimal meta-package described in our proposal, a packages group of >> “relatively standard” tools, that is purposed at beginner wanting to >> have only one simple pacstrap command to issue in order to get started? > > Yes because those two things seem the same to me. Or at any rate their > difference is too small to be worth the distinction. Perhaps I'm not > understanding what exact roles you envision for [base] and [minimal- > system]; it would help to know exactly what packages you would put in > the former and not the latter. Allan suggested e2fsprogs, man, and vim. > We can certainly agree that three is too few to warrant creating two > distinct groups. less, because I cannot imagine an interactive console without a pager texinfo, for the same reason one would want man-db. (Also, GNU tools tend to have terrible manpages, so you kind of need texinfo even if you just pipe it to less). man-pages, to get a good starting collection of things to use man-db to read (section 3, 4, 5, 7, and 1p will be quite bare otherwise). systemd-sysvcompat to simplify the kernel command line. s-nail, because some people apparently assume a complete system should include the "mail" binary for completeness' sake. dhcpcd and netctl, commonly used for networking by people who don't understand the glories of NetworkManager. (Also the archiso.) which, because too many things on the internet recommend using it to find out whether/where a program is installed, and muscle memory therefore means people will instinctively try that instead of using command -v/type -a ... In fact, most of the base group, with the grievous exception of: - jfsutils/reiserfsprogs/xfsprogs which assume quite odd things about non-default and usually exotic filesystems, and - lvm2/mdadm which offend my soul due to things like https://bugs.archlinux.org/task/61040 screwing up the system even for people who will never touch lvm are reasonable things to suggest to people by default. It is simply that there is also a lot of those, which people rightly don't want to be *forced* to install. I don't want or use which, nano, vi, or mailx for example. Does that mean most people won't? I venture to say more users than not, will feel grateful for a group that recommends at least the first three to them. It is just that the utility of the base group as a recommendation is hindered by lack of something to define the minimum. ... We already have more than a few sets of packages that are defined by both a group and a metapackage for user convenience, e.g. https://wiki.archlinux.org/index.php/KDE#Installation So if it was really super inefficient to have both base and base-system then we could clean up lots of other stuff in the repos too... ... On a slightly less serious note, it's almost amusing to see base being considered for the scrapyard at all. Given how impossible it was to even get jfsutils and reiserfsprogs removed from base, even though, one of the only things that previous discussions ever had so much as two people agree on is how useless these are, I was sort of expecting base to continue to exist merely in order to exist. Those two are so not base that I'm genuinely bewildered why they are or would or could be in either base or base-system. At least xfs is common due to being both well-known and stable. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP
Re: [arch-dev-public] Proposal: minimal base system
On 1/21/19 6:53 PM, Giancarlo Razzolini via arch-dev-public wrote:
> I agree with this package list. It's missing mkinitcpio though.
No it is not, mkinitcpio is definitively not needed.
It's only required in order to execute the pacman hooks for a linux
kernel package (or do so manually). And core/linux is not required to
use archlinux, although it is required to boot it on bare metal.
The most recent version of my PKGBUILD draft for this "base-system"
PKGBUILD (which I shared with Levente during the planning stages of this
proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/
I've actually listed
optdepends=('linux: bare metal support')
And IMO that is exactly where mkinitcpio belongs -- as a hard dependency
for any package which intends to implement a kernel for booting to bare
metal.
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Re: [arch-dev-public] Proposal: minimal base system
On 1/21/19 5:03 PM, Levente Polyak via arch-dev-public wrote: > # Proposal > > There is no strict definition of what a minimal Arch Linux system > installation must contain. However in reality we mostly don’t add any > packages that are in the base group as a dependency to other packages, > which basically makes it a hard requirement. > > The current way of defining a minimal system via a group is non-optimal > for the following reasons: > > - A group can’t enforce installation of packages when being extended or > modified > - The current base group contains lots of unneeded packages > - Manually getting rid of some of the packages may result in broken deps > > To overcome the disadvantages, a better way to handle a strictly defined > set would be a simple virtual base-system package that depends on the > bare minimum of what we define as given and required. This virtual > package can be changed/extended and every installation will pull it in > during the next system upgrade. > > Everything that won’t be part of base-system needs to be added as a > dependency to all requiring packages; alternatively don't omit any first > level runtime dependencies at all. > > This package should only depend on strictly required explicit packages > to get a working minimal Arch Linux system. > > The proposed end result is: > - base: convenient helper group for quickly getting a working system > when installing, must include the new base-system package > - base-system: package defining the minimum dependencies for a working > base runtime \o/ finally proposing something which may in practice clear up our horrible confusion. > Possible candidates for the virtual package: > > Base requirements: > - filesystem > - gcc-libs > - glibc > - bash > - coreutils > > Distro requirements: > - licenses > - pacman > - systemd > > Some POSIX tools > - coreutils > - file > - findutils > - gawk > - grep > - procps-ng > - sed > - tar > - gettext > - pciutils > - psmisc > - shadow > - util-linux > - bzip2 > - gzip > - xz > > Some networking tools > - iputils > - iproute2 > > > ## Alternative > > Another approach would be, assuming we want to properly support tiny > containers, to reduce the above list even further to a bare minimum of > running pacman and not omit any further 1st level runtime dependencies > in our packages. For the record: if containers really want to do strange things and possibly break any script that is being run, I'm of the opinion that they are free to do their own by manually scripting pacstrap to only install the packages they want, but I don't expect the users to call that Arch and expect support if the sky falls because their system users and script dependencies disappear. (systemd is needed for sysusers/tmpfiles at minimum, and mostly other than that we're targeting a basically POSIX scripting environment plus the package manager) > ## Short summary > > Required: > - Use a virtual package instead of a group for the bare minimum > > Option 1: > - Define a base-system virtual package as a required set of packages > containing something like a POSIX interactive runtime environment > > Option 2: > - Reduce the set even further to aid tiny containers and don't omit any > other 1st level runtime dependency in packages > - We could additionally still have a smaller set for a POSIX interactive > runtime environment for convenience > > > > PS: Please focus on the abstract before bikeshedding whether single > packages should or should not be added > > cheers, > Levente > -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] [rb-general] Arch Linux reproducible package archives
In the effort to have reproducible builds, it is important to have availability of all dependent packages listed in the .BUILDINFO description of a built package. Due to previous efforts within Arch Linux, we do have a daily snapshot of the repos, but this could potentially result in missing packages if they were added and then removed during the course of a single day, and thus never showed up in a snapshot. I'm happy to say that this past Friday, I have upgraded the dbscripts to automatically archive every built package as a core part of our repository release scripts. Additionally, the dbscripts will now check each package before allowing it to be uploaded, to ensure that all installed packages in the .BUILDINFO are actually available. If a package is not available then the update will be rejected. For more details, see https://git.archlinux.org/dbscripts.git/commit/?id=f11a038c43270a70eafdba34ff33e134b6726a04 Of course, none of this guarantees that a package can be reproducibly built. However, it does ensure that we know exactly what input went into building the package, and paves the way for tools which utilize these dependent packages to test a package for reproducibility. Happy packaging! :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Looking for maintainer for mkinitcpio/a-i-s
On 12/16/18 3:52 PM, Dave Reisner wrote: > Hi, > > I'm finding myself lacking these days in both time and motivation to > continue maintenance of both mkinitcpio and arch-install-scripts. Is > anyone interested in taking these over? Both projects are fairly stable, > but bugs do crop up as the rest of the OS evolves. Haven't really looked at mkinitcpio before, but I guess I could take over arch-install-scripts. I do have some patches I've been polishing for submission already. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Rebuilding old packages (2016)
On 11/9/18 5:29 PM, Jelle van der Waa wrote: > On 11/09/18 at 10:54pm, Jelle van der Waa wrote: >> Hi all, >> >> There are rebuilds ongoing for packages build before 2017-01-01, this >> *should* add PIE and the newer BUILDINFO format to these old packages. >> And uncovers some build failures, which should be fixed and I will make >> a todolist for. > > Fake news, we are rebuilding everything before 2017-08-01! We more or less need to rebuild everything since 2018-09-11 because svn propsets aren't reproducible no matter what BUILDINFO format you use. :p -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] TU application process
On 11/6/18 7:32 AM, Bartłomiej Piotrowski via arch-dev-public wrote: >> Here again I would argue that they are devs that have [core] pushing >> rights, as well as devs that are Master Key holders. So even if you >> don’t want to write this black on white, this actually means a small >> group of people have the real control over the distro (technically, >> Master Key holders could revoke everyone else). > > You can argue, but it's simply not true. Any developer has access to > [core]. Master key holders aren't considered any better than other > developers besides having more duties and no one has ever refused to > sign new TU; for every master key holder, there is someone else holding > revocation certificate. There is no hierarchy. I guess in addition it should be pointed out there's no technical measure stopping *any* Dev from pushing a new keyring package that deletes/revokes/disables all master keys and current packaging keys and replaces the entire keyring with their own key alone. It's just yet another package... -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] away for some time over the next month
It is High Holiday season, so I will be away at a minimum, tomorrow and Tuesday, then Wednesday the 19th and the week after that. (Plus, you know, general hecticness.) I'll be irregularly available until October 3rd, in other words. All the best. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Improving the package guidelines
On 8/29/18 6:35 PM, Gaetan Bisson via arch-dev-public wrote: > [2018-08-29 20:20:29 +0200] Morten Linderud via arch-dev-public: >> The rewrites have been up for a few months now and I intend to merge them >> soon. >> Feel free to still review them, either with a reply on the ML or on IRC. >> Whatever >> you prefer :) > > Sorry but I don't recall such a thing ever being discussed on this list. > What rewrites are we talking about? The email from May 22nd that began this email thread, specifically, the ArchWiki packaging guidelines for Python and Golang. You can see the work that has been done, by looking at Foxboron's User namespace on the wiki. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [RFC] Remove svn propset id's
On 8/29/18 4:23 PM, Jelle van der Waa wrote: > Most of our PKGBUILDs svn propset's break reproducible builds and the > pkgbuild_sha256sum in the BUILDINFO file. When building a package before > commiting the PKGBUILD the propset $Id will differ since the $Id is set on > commit. > > This has a few implications, pkgbuild_sha256sum is useless and we can't > reproduce packages due to the BUILDINFO not matching. Also the reproduce tool > uses ASP to retrieve the PKGBUILD and therefore can't verify that it got the > correct PKGBUILD (it relies on pkgbuild_sha256sum). > > To resolve this issue we could simply remove the propset id's, since for > me, although not sure about others they don't seem particulary useful. I've never been entirely clear on their motivating purpose, in fact. Also to expand on the general issue for people who aren't in #archlinux-reproducible: When you run extra-x86_64-build, you're using the PKGBUILD you're about to commit, which svn will set to the expanded propset of the previous commit... which matches no file ever seen by svn. If you svn commit, and *then* extra-x86_64-build, then svn will actually have the right file. What's the likelihood of people making sure to svn commit before making sure the package actually builds as expected... IIRC at least some packages seem to have been built by the svntogit exported PKGBUILD (e.g. via asp) since their pkgbuild_sha256sum can be obtained from asp. This results in far too many ways to maybe get the actual file used to build, and in the most likely scenario it requires deep forensics of the svn repository. ... svn propsets will die either way whenever we finally manage to migrate away from svn and onto git. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Dropping KDE4 libs
On 8/24/18 6:00 AM, David Runge wrote: >> lmms > This should already be Qt5 capable. Rebuild incoming. https://bugs.archlinux.org/task/47723 Available in the beta only, AFAIK. >> mixxx > I hope this is portable! It's the only cross-platform tool for DJing. Also builds with qt5 on master (so should be there in 2.2 release). -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] /r/linux AMA
On 8/9/18 12:41 PM, Morten Linderud via arch-dev-public wrote: > Yo! > > The subreddit /r/linux have started organizing AMA threads for relevant > projects. Gentoo had one of these a few months ago and is an interesting read. > > https://www.reddit.com/r/linux/comments/8nsdj0/we_are_gentoo_developers_ama/ > https://www.reddit.com/r/linux/comments/93qlow/established_project_developer_team_member_flairs/ > > I think it's a good idea Arch Linux does an AMA as it's might give users some > incentive to help contributing to the project. I have chatted with a subreddit > mod at /r/linux, and the AMA should preferably start on any Monday from 27th > and > onwards. It will also run for a few days, so there is no need to be present > all > the time, or when it starts. > > > If you are interested participating please reply to the list with the > following > information: > > * Reddit username. > * What you do. > * What Monday fits for you? > > I have also started handing out flairs on the /r/archlinux subreddit. It's not > an official forum, but if developers and team members want flairs for their > reddit accounts you can also reply to this mail or poke me on IRC :) /u/eli-schwartz I'm a Bug Wrangler and Trusted user. I like poking things to make them work, I also contribute frequently to various Arch projects, e.g. pacman, and maintain dbscripts. I can probably find time most Mondays. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] [arch-general] proposal to add "aurpublish" to community
On 07/22/2018 12:55 PM, Eli Schwartz wrote: > On 07/20/2018 04:23 AM, WorMzy Tykashi via arch-general wrote: >> On 20 July 2018 at 08:38, Jelle van der Waa wrote: >> >>> On 07/20/18 at 09:05am, Jelle van der Waa wrote: >>>> On 07/19/18 at 07:23pm, Florian Pritz via arch-dev-public wrote: >>>>> On Wed 18.07.18 - 15:28, Eli Schwartz via arch-dev-public wrote: >>>>>> I would like to add this to [community], but I'm unsure what people >>>>>> think about this; specifically, whether this might come too close to >>>>>> "supporting the AUR via [community] packages". Note that this is >>> *not* >>>>>> an AUR helper and is strictly a tool for package *maintainers* to use >>>>>> during the process of uploading. >>>>> >>>>> Uploaders are fine by me and I think we had one in previously. >>>> >>>> From what I can recall, we had one in, some discussion and it was gone >>>> again. I'll try to find the post in the archives. >>>> >>> >>> Gotcha, it was cower. [1] >>> >>> [1] https://lists.archlinux.org/pipermail/aur-general/2010- >>> December/012763.html >>> >>> -- >>> Jelle van der Waa >>> >> >> (apologies for crosslist posting) >> >> For uploaders, there was 'burp' in [extra] which which was added without >> any serious opposition, and remained in the repos until shortly after AUR4 >> was launched (which made it redundant). See >> https://lists.archlinux.org/pipermail/arch-dev-public/2012-April/022787.html >> and https://bugs.archlinux.org/task/46210 >> >> Cheers, >> >> >> WorMzy > > So yeah, it seems like at least in the past there's been a distinction > made between uploaders (burp, aurpublish) and downloaders (cower). > > Anyway if no one has a serious objection by the end of the week I guess > I will add it. :) I've just added it to [community]. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] [arch-general] proposal to add "aurpublish" to community
On 07/20/2018 04:23 AM, WorMzy Tykashi via arch-general wrote: > On 20 July 2018 at 08:38, Jelle van der Waa wrote: > >> On 07/20/18 at 09:05am, Jelle van der Waa wrote: >>> On 07/19/18 at 07:23pm, Florian Pritz via arch-dev-public wrote: >>>> On Wed 18.07.18 - 15:28, Eli Schwartz via arch-dev-public wrote: >>>>> I would like to add this to [community], but I'm unsure what people >>>>> think about this; specifically, whether this might come too close to >>>>> "supporting the AUR via [community] packages". Note that this is >> *not* >>>>> an AUR helper and is strictly a tool for package *maintainers* to use >>>>> during the process of uploading. >>>> >>>> Uploaders are fine by me and I think we had one in previously. >>> >>> From what I can recall, we had one in, some discussion and it was gone >>> again. I'll try to find the post in the archives. >>> >> >> Gotcha, it was cower. [1] >> >> [1] https://lists.archlinux.org/pipermail/aur-general/2010- >> December/012763.html >> >> -- >> Jelle van der Waa >> > > (apologies for crosslist posting) > > For uploaders, there was 'burp' in [extra] which which was added without > any serious opposition, and remained in the repos until shortly after AUR4 > was launched (which made it redundant). See > https://lists.archlinux.org/pipermail/arch-dev-public/2012-April/022787.html > and https://bugs.archlinux.org/task/46210 > > Cheers, > > > WorMzy So yeah, it seems like at least in the past there's been a distinction made between uploaders (burp, aurpublish) and downloaders (cower). Anyway if no one has a serious objection by the end of the week I guess I will add it. :) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] proposal to add "aurpublish" to community
Hi, so for a while now I've been using a tool I wrote at https://github.com/eli-schwartz/aurpublish -- recently split out from a vendored script in https://github.com/eli-schwartz/pkgbuilds -- to maintain my AUR packages. Some of you will probably have heard about it before. :) I certainly think it's a nifty tool :D and apparently a number of other people do too. It makes things faster and simpler, and especially prevents people from accidentally uploading PKGBUILDs with out of date .SRCINFO which is obviously a huge plus... I would like to add this to [community], but I'm unsure what people think about this; specifically, whether this might come too close to "supporting the AUR via [community] packages". Note that this is *not* an AUR helper and is strictly a tool for package *maintainers* to use during the process of uploading. What do you all think? -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Improving the package guidelines
On 06/28/2018 05:06 PM, Eli Schwartz wrote: > The one case where this would make a difference is where 2to3 is being > used, so depending on which version of python you use the actual source > code is modified. I think the guidelines should only mention that "if > 2to3 is used, you'll need to make copies of the source [...]". Honestly > I consider this copying around when unnecessary to be the equivalent of > inserting "sleep 5" everywhere. > > 2to3 being run as part of setup.py build is hardly the common case, it's > not even recommended at all, really. Latest revision to these guidelines clarifying the 2to3 case specifically: https://wiki.archlinux.org/index.php?title=User:Foxboron/Python_packaging_guidelines=529424=528011 So far the page seems pretty good, time to consider merging it I guess. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Improving the package guidelines
On 06/28/2018 05:59 PM, Felix Yan wrote: > The main reason behind this (or why I started doing this) was sometimes > the tests run inside the sources tree made both versions' .pyc files > into the tree itself, and finally end up in the package. I had this > problem for several times and end up having the separated build > directories as template for new packages. > > This seems not the case for most packages now, so I agree that it should > be avoided. Hmm, that's quite interesting. From what I've seen, both pytest and `python setup.py test` (at least today) use the copy of the code from outside of build/ when running unittests, which I suppose probably makes sense as it is running right alongside the unittests themselves. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Improving the package guidelines
On 05/22/2018 04:25 PM, Morten Linderud via arch-dev-public wrote: > Yo! > > In April there was some discussion regarding how to properly do unit testing > in > Python PKGBUILDs[1]. Felix had some amazing notes that was super useful. But > as > pointed out we don't really strive to document these things[2]. To try help > and > spark some interest in improving the current package guidelines, I have spent > a > some time restructuring and rewriting parts of the Python and Golang package > guidelines. I'd appreciate reviews on them! > > https://wiki.archlinux.org/index.php/User:Foxboron/Python_packaging_guidelines > https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines So there's been some recent activity on the wiki pages in question. Primarily, golang seemingly needs to be copied entirely due to not supporting symlinks or some such. Also I'd like to discuss what seems to me a common misconception in python packaging -- specifically, the use of cp -r source source-py2 and building both separately. Best I can tell, this is primarily motivated by fear of py2/py3 specific bytecode being generated, but the thing is, this bytecode is all generated during package() inside of "$pkgdir" during the install step. You can check the contents of the build/ directory... it just copies the .py files and builds any ext_modules. The one case where this would make a difference is where 2to3 is being used, so depending on which version of python you use the actual source code is modified. I think the guidelines should only mention that "if 2to3 is used, you'll need to make copies of the source [...]". Honestly I consider this copying around when unnecessary to be the equivalent of inserting "sleep 5" everywhere. 2to3 being run as part of setup.py build is hardly the common case, it's not even recommended at all, really. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Moving gcc7 into [community] for CUDA
On 05/29/2018 03:56 PM, Anatol Pomozov wrote: > gcc-cuda will probably introduce a lot of confusion. Let's use > standard naming practice for the old versioned packages (i.e. gcc7 or > gcc-7). Sorry, that was a joke. :D I think gcc7 is fine, if anyone complains tell them it's really gcc-cuda in disguise. It's not like we've never provided old things for packages which need them before, so it's just a cuda thing which is fine to have. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Moving gcc7 into [community] for CUDA
On 05/28/2018 09:09 PM, Allan McRae via arch-dev-public wrote: > On 29/05/18 11:00, Sven-Hendrik Haase wrote: >> Hey, >> >> I would like to move gcc7 (based on the latest version 7 commit of gcc [0]) >> into [community] because of cuda 9.2 and in return drop gcc54. >> >> I tried to make it work with current gcc but to no avail. In earlier >> releases of cuda the incompatibilities could be patched with header hacks >> but not this time. I tested the whole setup with cuda 9.2 locally and it >> seems to work fine. >> >> I just want to get somebody's ok on this as apparently not everyone is >> stoked about having yet another old version of gcc in there for some time. >> >> Sven >> >> [0] >> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gcc=44e0a03db1b5cabf6135f194e540d513cf959245 >> . >> > > OK to add gcc7 given it will drop gcc54. Agreed, we're moving in a net positive direction. We still have two versions of gcc, but at least the old version is a *newer* old version. (We could name it gcc-cuda if that makes people happier?) -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
[arch-dev-public] dropping js38
The last package to depend on js38 was cjs, and with the completion of the cinnamon 3.8 rollout this too is ported to js52. There's no reason to continue to keep this in the repos AFAICT. ... On the topic of the various js* packages, we've had to rebuild some packages which used the /usr/bin/js tool when moving to js52. Having to patch the package to hardcode a specific version of js seems a bit awkward, perhaps we should move the js command from the js185 package (while we wait for *its* last user to be fixed) to a renamed js52 ==> js package, which would provide js52 for packages which link against a specific version instead of using the CLI? This would more closely match how we handle things like python, ruby, nodejs. -- Eli Schwartz -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] New build server in the US?
On 04/19/2018 03:19 PM, Florian Pritz via arch-dev-public wrote: > We already have a second build server (sgp.pkgbuild.com) which is hardly > used. Souyz is really used quite a bit, but in general it has quite some > resources left to spare. I guess it depends on what you want and when. > Do you want to get builds done quickly (like on a local machine) or are > you happy with waiting until the machine is free? Maybe someone wants to > work on a system that allows to pause builds if people don't care when > they finish so that those that want them done quickly get priority? That > way we could possibly use our available resources better. Maybe it's > even as simple as queuing builds, but I don't know how long the builds > that people run on soyuz take. If a single build takes an hour, queuing > won't really work. > > Some feedback on how people use soyuz would probably help a lot here. > What are your build times, how quickly do you want the result, do you > need to see live output, does the latency to the machine matter > (interactive usage?), ...? I usually only use soyuz for annoyingly long builds like my custom repo with glibc-git, thunderbird-gtk2, etc. which can take as long as it needs to (assuming I remember to run it in tmux so it doesn't die when I lose internet). > Is anyone interested in taking on this project and maybe also setting > up/maintaining some build service if that turns out to be a good idea? We could probably do something dead simple with a wrapper script that checks pgrep makechrootpkg || sleep 1m in a loop, before running a build. Anyone with a build they just want to run as soon as no one else is doing one, could use that. Just run it in tmux in case of latency/disconnection. > Regarding the OSUOSL idea: I'm slightly against getting machines from > yet another organisation. While it doesn't matter much during normal > operation, fixing problems is usually more difficult because things like > getting a live system booted, getting serial console access or even just > getting support are often not easily possible when servers are hosted at > companies that don't see hosting as a core goal. We've had this happen > before and it's not great. I don't know what the situation is for this > offer, but let's not rush into creating even more work for us. > >> I honestly have no idea about Arch's financial situation, or how soyuz is >> paid for in practice. > > Soyuz is a rented server at hetzner.de (like all our other important > servers) and payed for with donation funds. > > Looking at a recent treasury report from SPI[1] we have around $47k > right now and looking back a few months, it seems to be growing. > > [1] http://lists.spi-inc.org/pipermail/spi-general/2018-April/003845.html I guess we could afford to rent another server if we really needed one! But I guess it is probably more used by people with large packages, in which case faster builds was the reason they decided to use soyuz in the first place. We could just upgrade soyuz. I think that might double what we're currently paying, but OTOH so would buying a second server. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Deprecation of pam_unix2
On 04/16/2018 07:24 AM, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 2018-04-16 13:02, Bartłomiej Piotrowski via arch-dev-public wrote:
>> Hi team,
>>
>> During libnsl rebuild heftig pointed out that we are shipping
>> pam_unix2 that has been dead upstream for a long time (to the point
>> that it's being built from our own mirror now). I'm also unwilling to
>> spend time to fix its configure.ac to make it build with libnsl and
>> libtirpc correctly.
>>
>> Unless someone's life depends on it, I'd like to drop it from
>> repositories.
>>
>> Bartłomiej
>
> (Note it's not packaged separately and ships as part of core/pam.)
>
> While on it, I'm dropping pam_unix_{acct,auth_passwd,session}.so
> symlinks from pam package that are also relics of the distant past.
>
> Bartłomiej
This reminds me we also have a request to drop pam_tally in our default
config, in favor of pam_tally2.
https://bugs.archlinux.org/task/42120
--
Eli Schwartz
Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
