Yo!
With the release of pacman 6.0.2 we have now support for debug packages through
`debugedit` as opposed to the awk hack used previously.
https://gitlab.archlinux.org/pacman/pacman/-/commit/ae2f506ddfd1
This should resolve several issues we have had with the existing debug packages
and I want people to test this support.
Please recreate your build chroots and/or reinstall base-devel locally. Enable
debug in a diverse set of packages you maintain. And help validate the current
assumptions:
* Debug packages for Rust, Go* and Julia should work
* Weird /build directories should not exist
* We should have header files
* The source files should be located in `/usr/src/debug/${pkgbase}-${pkgver}`
You can list them easily with `bsdtar -tf *.pkg.tar.zst`
Note pacman is currently in [testing].
In the case for Go we need to disable compressed dwarf headers with `-ldflags=-compressdwarf=false`.
It should be the case for any binaries with these headers as well. They can be
recognized with the weird "DWARF version 0 unhandled" error string during
stripping.
Please report back if things look good, or you are looking at weird debug
package structures :)
If everything looks fine I intend to write an RFC for blanket enabling debug
packages in devtools!
--
Morten Linderud
PGP: 9C02FF419FECBE16
Hi Jelle, (also forwarding to dev-public)
definitely yes, OpenSSL 3.0 is on my wish list! :-)
I did not want to jump on it at day one though. Even the last minor
updates were quite painful and we still have packages requiring
version 1.0 and are still not compatible with 1.1.
While they claim that most packages should work with a recompile, it
would be nice to actually know which packages are not compatible. This
should help whether we need another compatibility package are would be
able to just replace openssl 1.1 with version 3.
I know about foutrelis' awesome rebuilder script, but I wonder if we
have something similar that I just could run for half a day to get an
idea which package would break and which wont? Like a dry run that
wont commit anything. If no such thing exists yet, I might have a look
myself.
Greetings,
Pierre
On Wed, Nov 3, 2021 at 9:14 PM Jelle van der Waa <jelle(a)vdwaa.nl> wrote:
>
> Hi Pierre,
>
> Shall we start an openssl 3.0 rebuild soon? Fedora/Debian/Alpine seens
> to have already started.
>
> https://fedoraproject.org/wiki/Changes/OpenSSL3.0
>
> Greetings,
>
> Jelle
--
Pierre Schmitz, https://pierre-schmitz.com
Hey!
As of git 2.38.1 [0], the handling of submodules in PKGBUILDS is broken due
to CVE-2022-39253 [1]. This situation affects the packages that use the
following command for updating the submodules:
> git submodule update
This will result in "fatal: transport 'file' not allowed" error since
the value of `protocol.file.allow` is changed to be "user" by default.
It means that `file://` clones are considered unsafe by default.
Currently, there are two possible fixes available:
1. git -c protocol.file.allow=always submodule update
2. git submodule--helper update
The latter seems to be an internal command which does not have any
public facing documentation whereas the former option is more
explicit.
There is a related bug report [2] and a TODO list draft [3] for updating
the affected packages.
I will be updating the VCS guidelines [4] to use the first proposed
solution if it all looks good.
[0] https://lore.kernel.org/lkml/xmqq4jw1uku5.fsf@gitster.g/
[1] https://www.cve.org/CVERecord?id=CVE-2022-39253
[2] https://bugs.archlinux.org/task/76255
[3] https://md.archlinux.org/YVwV_wIKQfG5obcNLNlCjg
[4] https://wiki.archlinux.org/title/VCS_package_guidelines#Git_submodules
Let's make some gains,
Orhun
Yo,
On the 22nd of October (tomorrow) there is going to be a small hackathon on
minitcpio and arch-install-scripts!
mkinitcpio needs some love before a new release can be made, the goal would also
be to work on the open pull-requests before moving the project too our Gitlab
instance.
https://github.com/archlinux/mkinitcpio/
The current ideas is to do scope out a bugfix release and then a larger release,
and we would love some help to do that. Beyond that we want to look at improving
the general status of the systemd hooks in mkinitcpio, there are several
projects that implements parts of this better than mkinitcpio and it would be
neat to figure out how we should work on that.
For ideas see issue 121 in the repo; https://github.com/archlinux/mkinitcpio/issues/121
I'm also maintaining arch-install-scripts but that is mostly out of necessity :)
I'd love to find a new maintainer for the project, so any ideas or issues can
also be worked on tomorrow!
https://github.com/archlinux/arch-install-scripts
This is a great opportunity for new people to get involved with some Arch
project development :) The only requirement is to not be afraid to dive into
bash/ash scripts.
Join `#archlinux-projects` on the libera.chat network or through matrix if you
are interested :)!
--
Morten Linderud
PGP: 9C02FF419FECBE16
hello,
multiple people in Arch Linux noticed the output of our `git archive`
command doesn't match the tarball served by github anymore.
First I suspected an update in our gzip package until I found this line
in the git 2.38.0 release notes:
> * Teach "git archive" to (optionally and then by default) avoid
> spawning an external "gzip" process when creating ".tar.gz" (and
> ".tgz") archives.
I've then found this commit that could be considered a breaking change
in `git archive`:
https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d4738bb525066c710
I don't know if there's some kind of gzip standard that could be used to
align the git internal gzip implementation with gnu gzip.
I'm not saying this is necessarily a bug or regression but it makes it
harder to reproduce github tar balls from a git repository. Just sharing
what I've debugged. :)
cheers,
kpcyrd
ohai!
I released a new tool called updlockfiles that attempts to help manage
dependency lockfiles like Cargo.lock, composer.lock, go.mod and friends.
Hopefully this helps with reproducible builds in Arch Linux, but also if
you want to manage your own downstream lockfile to override vulnerable
dependencies.
Announcement blog post:
https://vulns.xyz/2022/10/updlockfiles/
Repository:
https://github.com/kpcyrd/updlockfiles
cheers,
kpcyrd
Hi all,
we have recently cleaned up parts of the developer wiki a bit and moved
the list of internal projects to a more prominent location:
https://wiki.archlinux.org/title/Getting_involved#Software_projects
As you can see, we have quite a few projects and some of them would be
happy about more participation from members of the Arch Linux staff as
well as users.
Help in fixing and extending the software is much appreciated, but
testing and opening tickets that describe flaws or usability problems
are equally important!
If you are familiar with writing documentation, Ash, Bash, C,
JavaScript, Python, or Rust and always wanted to get involved with one
of the Arch Linux projects: Look no further! :)
As mentioned in the wiki, we have a central mailing list [1] and IRC
channel [2] for discussing most of the projects (unless they provide
other means of communication).
We hope to spark people's enthusiasm, as healthy projects ensure a
flexible distribution and allow us to tackle larger goals (e.g. move to
a git based workflow for packaging, effortlessly providing several
architectures, automating our infrastructure and releases, etc.).
Best,
David
[1] https://lists.archlinux.org/mailman3/lists/arch-projects.lists.archlinux.or…
[2] ircs://irc.libera.chat/archlinux-projects
--
https://sleepmap.de
Hi all,
we need to do a bit of [core] repository cleanup.
In this MD [1] (publicly visible readonly link [2]) we have a list of
packages that should leave [core], some maybes that need discussion
before moving them and some that should be moved to [core] from the
other repositories.
If you have more packages, that should not be in [core] anymore or
should be moved to it, please add them to the list(s).
The general rules for inclusion in [core] are, that we want to
- preserve base-devel as a group there
- preserve base as a meta-package there
- preserve makedepends and depends of a [core] package there
The checkdepends and also optdepends of a package may reside in other
repositories.
As we have a few removals of packages in the list that concern packages
only in [core] for historical (or other) reasons, please keep the
discussion about them focused on technical reasons as to why they should
potentially remain there.
Additionally, we have a few orphan packages in [core] that need
adoption. Please adopt packages (if you can)!
Best,
David
[1] https://md.archlinux.org/nrXL0ay5Tp6wP-f5M7N8bA#
[2] https://md.archlinux.org/s/MliseALTG#
--
https://sleepmap.de
## RFC
We entered the final discussion period for the RFC [0] to merge the
pacman repository `[community]` into `[extra]` as well as the packaging
VCS location `community` into `packages`. The `[core]` repository
remains limited to Developers. One the RFC is accepted, we will
implement the proposal during the migration to Git packaging.
## devtools
Changes were prepared to account for the repo merger RFC and its
resulting workflow. We are slowly approaching a state of Git packaging
that could be used productively. Once the final bits haven been
finalized, we will present the proposal and discuss the migration and
switch over.
## mailman3 migration
We have finished the full migration to mailman3 [1]. Rewriting of the
"From" header and subject (to prepend the list name) have been disabled
to keep the DKIM signature intact. This means "reply to mailing list"
must be used when replying to the list and you may need to update your
filters and rules matching the "From" header.
All existing subscriptions are migrated and you do not need to re-
subscribe.
## python2 removal
Python 2 went end of life January 2020. Since then we have been actively
cutting down the number of projects depending on python2 in our
repositories, and we have finally been able to drop it from our
distribution [2].
## RISC-V mirror
We started hosting [3] our latest efforts of the yet unofficial RISC-V
port. In the past year, we have a boost in progress and currently ~87.5%
of Arch x86_64 packages are available in the riscv64 repository [4].
[0] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/14
[1] https://archlinux.org/news/arch-linux-mailing-list-changes/
[2] https://archlinux.org/news/removing-python2-from-the-repositories/
[3] https://riscv.mirror.pkgbuild.com/
[4]
https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o…