On Sat, 17 Jun 2023 at 12:44, Antonio Rojas wrote:
>
> Starting from version 2023.66594-9, TeX Live packages have been reorganized
> to mirror upstream collections.
Announcement seems well-written and packages seem to work for my
resume. Cheers for adopting and transforming them.
On Sat, 14 Jan 2023 at 23:25, Morten Linderud wrote:
>
> devtools version 20230105-1 has been released into [core]!
>
> This enable the debug option for all our packages :)
Much nice! Went ahead and purged the debug option from */trunk/PKGBUILD.
(If someone thinks the option should stay for a bi
On Sun, 13 Nov 2022 at 18:43, Jelle van der Waa wrote:
>
> * Do we have enough disk space for archiving?
You have to take gemini's daily backups into consideration as well.
They already take up a lot of backup space [1] and several hours to
finish every day. I can see gemini falling over if we st
On Tue, 25 Oct 2022 at 20:03, Levente Polyak wrote:
> https://mta.openssl.org/pipermail/openssl-announce/2022-October/000238.html
Started the rebuilds with 3.0.5, let's not forget to bump to 3.0.7
before moving to testing!
On Tue, 25 Oct 2022 at 12:15, Evangelos Foutras wrote:
> If the above approach seems good, please commit the updated PKGBUILD
> to svn. We'll then start the rebuilds on [1] and see how they go.
Slight change of plans, Jan is going to push GNOME 43 first. We should
be able to do Open
Hi Pierre,
We were discussing on IRC about starting the OpenSSL 3.0 rebuild. For
bootstrapping, we could make the openssl package depend on openssl-1.1
while building the following:
- coreutils
- curl
- kmod
- krb5
- libarchive
- libevent
- libssh2
- pacman
- sudo
- systemd
After these are linke
On Mon, 12 Sept 2022 at 11:47, Felix Yan wrote:
> This reminds me that we should probably make the port more visible to
> get more hands on it. Would you consider adding a subdomain at
> pkgbuild.com or archlinux.org?
Created a GeoIP-based mirror at https://riscv.mirror.pkgbuild.com/.
On Thu, 4 Aug 2022 at 19:13, Pierre Schmitz wrote:
>
> Thanks. I'll build a new release tomorrow
For what it's worth, there's one report that the new kernel doesn't
fix the boot issue for AMD A6-1450. [1] I still think we should have a
new ISO as most reports say that the issue is fixed. For the
On Mon, 1 Aug 2022 at 21:44, Pierre Schmitz wrote:
> I'll wait for a fixed linux package
Fixed kernel is in [core], please go ahead with the new ISO if possible.
On Sat, 23 Jul 2022 at 19:39, David Runge wrote:
> Packages that are signed with a key that still had marginal trust in
> release A (and therefore already existed on the user system since
> release A) and gained full trust in release B will not be updated before
> the user does a system upgrade. T
On Tue, 12 Jul 2022 at 09:41, Antonio Rojas wrote:
> # pacman -Rc wxgtk2
I would avoid including --cascade here so as not to promote its use.
On Mon, 31 Jan 2022 at 22:27, Jelle van der Waa via arch-dev-public
wrote:
>
> The question is if anyone object to checking these small .NVCHECKER
> files into our svn repository. If there are no real objections, I'll
> start implementing this functionality into archweb in two weeks.
I'm not fond
On Fri, 24 Dec 2021 at 10:01, Allan McRae via arch-dev-public
wrote:
> This fix for the strip issue is for people to add CFLAGS+="
> -ffat-lto-objects" to their PKGBUILDs if they use LTO and contain a .a
> or .o archive. This affects ~300 packages in our repos (~2.5%). I will
> create a TODO lis
🐍 🎉 Python 3.10 is now in the stable repos! 🐍 🎉
(Some issues are to be expected but hopefully nothing too bad.)
Quick reminder that the Python 3.10 rebuilds have not been merged into
stable yet and care must be taken when updating them. I just had to
correct a package that was moved to stable from testing but was built
against Python 3.10.
I created a todo for the remaining ~150 packages. Just to emphasize
that if a package appears as incomplete on the todo but exists in
staging, that's most likely the first package built with --nocheck in
order to satisfy other packages' checkdeps. Therefore, it still needs
its tests to be fixed pro
For the next few days we'll be doing (semi-automated) rebuilds for Python
3.10. Please avoid adding new Python packages and starting other rebuilds
during this time. *This is a strong suggestion in order to minimize the
pain of this huge rebuild.*
Some PKGBUILDs were modified in /trunk to use the
"Fixed" by repo-adding ipguard to community. I have kept a copy of the
broken files db if anyone wants it, but it seems that
"ipguard-1.04-6/desc" had 1230 NUL bytes instead of 1230 bytes of
package details.
On Mon, 30 Aug 2021 at 13:58, Pierre Schmitz via arch-dev-public
wrote:
>
> Hi all,
>
> S
On Wed, 3 Mar 2021 at 23:34, Allan McRae via arch-dev-public
wrote:
> Options realistically are:
>
> 1) bump the baseline
> 2) provide a second more optimized port.
3) defer this until better tooling is available to implement (2)
Since the RFC is about bumping -march to x86_64-v2, it either gets
I would like to post this in ~48 hours from now. Review and
corrections are welcome. :)
Google has
[announced](https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html)
that they are going to block everything but Chrome from accessing
Google features (like Chrome sync) sta
On Tue, 26 Jan 2021 at 22:53, Morten Linderud via arch-dev-public
wrote:
>
> Frankly, I'd love to "stick it to the Man" and bundle the chrome keys. It
> would
> place Google in an interesting position.
Same. :)
> With that said... looking at the mailing list this feels like doing Google a
> fav
On Fri, 22 Jan 2021 at 10:05, Evangelos Foutras wrote:
>
> On Wed, 20 Jan 2021 at 19:28, Giancarlo Razzolini via arch-dev-public
> wrote:
> > After reading this thread [0], I think that, if we keep using their keys,
> > or even
> > start using the chrome keys, thi
On Tue, 26 Jan 2021 at 20:20, Sven-Hendrik Haase via arch-dev-public
wrote:
> The new box, as previously mentioned, is roughly twice as fast as dragon
> and has enough memory and storage to handle some load.
Thanks for making it happen, Sven. :)
On Wed, 20 Jan 2021 at 19:28, Giancarlo Razzolini via arch-dev-public
wrote:
> After reading this thread [0], I think that, if we keep using their keys, or
> even
> start using the chrome keys, this might put Arch into muddy legal waters and
> I don't
> think that's a good idea.
It seems others
Jochen Eisinger (Director of Engineering, Chrome) has confirmed that the
killing of our API keys is a done deal. He also does not seem interested
in the slightest bit to explore possible remedies for Chromium packages.
If Chrome's keys are still public in March, I would want to try and use
the
It looks like Sync will only work with official Chrome starting two
months from now. [1] It is understandable to some extend, perhaps to
guard against malicious applications using unofficial (non-Chrome) API
keys and tricking users to log into their account. This argument
doesn't hold much ground i
26 matches
Mail list logo
