On Thu, Feb 23, 2017 at 10:29:17PM +0100, Christian Hesse wrote:
> > I will push the first set of packages to [staging]. Please avoid doing
> > other rebuilds until this one is done.
>
> Are you interested in details?
FWIW, Debian stretch has openssl 1.1.0, so I guess they had to adapt lots
of
Hi Gaetan,
On Wed, Jun 07, 2017 at 08:55:15AM -1000, Gaetan Bisson wrote:
> [2017-06-06 22:58:01 +0200] Baptiste Jonglez:
> > Since a few years, I maintain a variant of the linux kernel in the AUR [1]
> > that adds support for Multipath TCP [2]. The most recent version is based
&
On Tue, Jun 06, 2017 at 10:49:29PM +0200, Baptiste Jonglez wrote:
> dbus-c++ [1] is orphaned, but needs some love to work with GCC 7.
> Currently, it does not build, and also prevents its reverse dependencies
> [2,3,4] from building. Apparently, Fedora has patches to fix this [5].
>
Hi,
dbus-c++ [1] is orphaned, but needs some love to work with GCC 7.
Currently, it does not build, and also prevents its reverse dependencies
[2,3,4] from building. Apparently, Fedora has patches to fix this [5].
I would be happy to maintain dbus-c++, however it would first need to be
moved to
Hi again,
Since a few years, I maintain a variant of the linux kernel in the AUR [1]
that adds support for Multipath TCP [2]. The most recent version is based
on linux 4.4, and the package I maintain tries to follow the "linux"
package from [core] as much as possible.
There is no short- or
On 18-12-17, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 2017-12-18 10:54, Bartłomiej Piotrowski via arch-dev-public wrote:
> > Please look at both lists and adopt what your packages are using or
> > you're personally interested in. I will drop whatever makes sense in
> > January.
>
>
Hi,
Archival of all packages between September 2013 and December 2016 is finished:
https://archive.org/details/archlinuxarchive
Here is some documentation on this "Historical Archive" hosted on archive.org:
https://wiki.archlinux.org/index.php/Arch_Linux_Archive#Historical_Archive
Hi,
There is some good news about the retirement of Alioth [1]: the Debian
people have finally decided to keep an archive of all the tarballs! They
are available at [2].
I've updated the TODO description: with this archive and the new gitlab
for -git projects, it should cover all of our
Hi,
On 30-05-18, Florian Pritz via arch-dev-public wrote:
> So far we haven't ever cleaned up the archive
> (https://archive.archlinux.org/), but it's getting too big and I don't
> think we have any use for packages from years ago.
You never know what useful things people could do with this
On 30-05-18, Florian Pritz wrote:
> On 30.05.2018 17:49, Baptiste Jonglez wrote:
> > What about sending previous years to the Internet Archive before deleting
> > them locally?
>
> I myself am not interested enough in keeping the old packages to figure
> out what rules
Hi,
Here is the progress on the upload of old packages to archive.org.
I uploaded a few packages to test if my script works:
https://archive.org/details/archlinux_pkg_babeld
https://archive.org/details/archlinux_pkg_kde-l10n-ca_valencia
https://archive.org/details/archlinux_pkg_lucene__
On 14-01-18, Eli Schwartz via arch-dev-public wrote:
> Try logging out and in again, and you should be able to use nspawn again
> once your user session is using the updated systemd version.
Thanks, it does work again after logging out! But unfortunately, only
for one build, the second one still
Hi,
Today I am experiencing build failures of several packages when using the
devtools:
$ extra-x86_64-build -- -I ../../another-package/trunk/foo.pkg.tar.xz
(...)
==> Making package: ring-gnome 3:20180112.2.d0bda53-1 (Sun Jan 14 16:06:22
CET 2018)
==> Retrieving sources...
Hi,
Eli and I disagree about how dependency conflicts should be handled when
packaging. This was prompted by the libxfont dependency conflict arising
from recent xorgproto changes [1].
My position in this case: it would be really easy to avoid this conflict,
by adding libxfont to the Replaces()
On 13-02-18, Eli Schwartz via arch-dev-public wrote:
> On 02/13/2018 06:56 PM, Baptiste Jonglez wrote:
> > Hi,
> >
> > Eli and I disagree about how dependency conflicts should be handled when
> > packaging. This was prompted by the libxfont dependency conflict arisin
On 14-02-18, Allan McRae via arch-dev-public wrote:
> Just because I had to look up the details of this
>
>
> - xorgproto replaces a lot of packages, including fontsproto:
> :: Replace fontsproto with extra/xorgproto? [Y/n]
>
> - libxfont requires fontsproto, so this causes the following:
Hi,
Kea [1] fails to build with boost 1.66.0, so please keep the rebuild in
staging for a few more days.
It does not seem like a big issue, but I won't be able to look into it
before January.
Thanks,
Baptiste
[1] https://www.archlinux.org/packages/community/x86_64/kea/
signature.asc
Hi,
On 10-03-18, Antonio Rojas via arch-dev-public wrote:
> Currently most of our packages which use the cmake build system are built
> with -DCMAKE_BUILD_TYPE=Release. This provides a reasonable (according to
> upstream) set of C(XX)FLAGS defaults which are appended to and override our
>
Hi,
OSUOSL [1] in the US has several "new" refurb servers with dual Xeon E5-2660.
Each machine has a total of 16 cores / 32 threads and 140 GB RAM, so that
would make nice build machines.
Would this be useful to the dev community? Soyuz is a bit overloaded at
times, and people in the US/Canada
On 18-04-18, Levente Polyak wrote:
> On April 18, 2018 11:53:01 AM GMT+02:00, Baptiste Jonglez
> <bapti...@bitsofnetworks.org> wrote:
> >So far, the only working solution I found is playing with PYTHONPATH:
> >
> >cd "$srcdir/$pkgname-$pkgver/tests"
&g
Hi,
Does anyone have experience with unit tests for python packages? It's
really useful to spot missing runtime dependencies, but it's a pain to get
to work.
Here is what I saw:
1) just running "python -m unittest discover" or "nosetests" or equivalent
in the check() function does not work,
Hi,
My proposal was basically « here is a possibly cheap opportunity for a
nice new build server ». If it turns out that it requires more work to
support and that we can afford renting a commercial server, or that we
actually don't need a new build server, it's fine.
On 19-04-18, Florian Pritz
Hi,
On 24-03-19, Robin Broda via arch-dev-public wrote:
> So, TL;DR, the benefits of `zstd -c -T0 -18 -` over `xz -c -z -` are:
> - Massive speed gain in compression
> - Massive speed gain in decompression
> - Stable, reproducible multithreading
> The speed gain in decompression substantially
Hi,
On 06-08-19, Jürgen Hötzel wrote:
> Hi,
>
> Unfortunately it is not possible to compile camlp4 with OCaml >= 4.08.
In the meantime, camlp4 got a (last) update to build with OCaml 4.08:
https://github.com/ocaml/camlp4/issues/151#issuecomment-519074190
Hi,
On 06-12-19, Maxime Gauduin via arch-dev-public wrote:
> Hi Baptiste,
>
> Since I have 2 packages depending on it, I may have to take it off your
> hands.
Thanks for the proposal, having a maintainer that actually uses the
package will be a real improvement over the current situation!
>
Hi,
I plan to orphan crypto++ [1] soon: I don't maintain any package that
depends on it anymore, and it's becoming annoying to maintain.
For instance, there was a significant security issue on July 2019 [2], and
5 months later there is still no upstream release even though a patch is
available
Hi,
On 29-06-20, Andreas Radke via arch-dev-public wrote:
> I'm going to remove the unneeded dependency on xorg-fonts-alias package
> from various font packages where it doesn't belong.
FYI, I had old font packages on my system that (obviously) still have this
dependency, causing upgrade to
On 05-06-20, Baptiste Jonglez wrote:
> Hi,
>
> I don't use Kea on Arch anymore, and I don't have the time and energy to
> maintain it in [community].
>
> It's currently stuck at 1.5.0. Kea 1.6 came out 9 months ago, but it
> moved some files around and would require exte
Hi,
I don't use Kea on Arch anymore, and I don't have the time and energy to
maintain it in [community].
It's currently stuck at 1.5.0. Kea 1.6 came out 9 months ago, but it
moved some files around and would require extensive testing to make sure
everything still works as expected.
If somebody
Hi,
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:
On 27-07-20, Giancarlo Razzolini via aur-general wrote:
> Em julho 27, 2020 21:03 Gaetan Bisson escreveu:
> >
> > It's quite unsettling that we seem to be rushing to write a news post
> > while this very reasonable suggestion remains completely ignored.
> >
>
> It wasn't ignored. They keys were
31 matches
Mail list logo
