El martes, 6 de octubre de 2020 20:34:08 (CEST), Morten Linderud via
arch-dev-public escribió:
So, Barth pointed out to me that I had actually taken his
cleanup-list script
and added it to contrib last year. Which I had forgotten. It generates a
complete list of suggested maintainers instead of
El lunes, 5 de octubre de 2020 7:16:14 (CEST), Sven-Hendrik Haase via
arch-dev-public escribió:
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
El miércoles, 3 de junio de 2020 0:23:38 (CEST), Konstantin Gizdov
escribió:
On 6/2/20 10:43 PM, Eli Schwartz via arch-dev-public wrote:
On 6/2/20 3:35 PM, Ike Devolder via arch-dev-public wrote: ...
According to the AUR page for qt5-styleplugins [1], OpenSUSE came up
with a patch [2]. It's
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
The latest (and last) Qt 5 release is now in [testing]. This is the usual
reminder that any package compiled against it must stay in [testing] until
Qt itself moves.
El miércoles, 22 de abril de 2020 11:35:44 (CEST) Antonio Rojas via
arch-dev-public escribió:
> El jueves, 27 de febrero de 2020 10:11:24 (CET), Alexander F Rødseth via
> arch-dev-public escribió:
> > Hello,
> >
> > It's time for the semi-yearly package cleanup
Is there any reason to keep dhcpcd in [core]? It's only an optional
dependency of netctl in [core], it currently lacks an active maintainer, it
doesn't seem to be much used (given the slow pace of signoffs), and there's
already a basic dhcp tool in [core] (networkd).
Any objections to move
El jueves, 27 de febrero de 2020 10:11:24 (CET), Alexander F Rødseth via
arch-dev-public escribió:
Hello,
It's time for the semi-yearly package cleanup of [community] packages, as
is tradition.
I have gathered a list of "unneeded orphans" in [community] (packages that
currently has no
The zn_poly package prior to version 0.9.2-2 was missing a soname link.
This has been fixed in 0.9.2-2, so the upgrade will need to overwrite the
untracked files created by ldconfig. If you get an error
zn_poly: /usr/lib/libzn_poly-0.9.so exists in filesystem
when updating, use
pacman
They were dependencies of the obsolete sage-notebook and I no longer need
them:
python-flask-autoindex
python-flask-silk
python-flask-oldsessions
python-flask-babel
python-speaklater
I will drop the ones that are not needed by anything to AUR if nobody
adopts them in a week.
El 21/12/19 a las 9:41 Andreas Radke via arch-dev-public escribió:
> 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
El domingo, 15 de diciembre de 2019 19:54:05 (CET), Sven-Hendrik Haase via
arch-dev-public escribió:
On Sat, 14 Dec 2019 at 16:25, Morten Linderud via arch-dev-public <
arch-dev-public@archlinux.org> wrote:
Yo!
Andreas Radke has done an impressive amount of bug assignments the past
week. But
The usual reminder that, due to Qt's ABI versioning, everything built
against 5.14 will have to wait in [testing] until Qt itself moves.
The usual warning: anything built against 5.13 will automatically get a runtime
dependency on it, so it will need to wait in testing until Qt itself moves.
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
On Wed, Mar 27, 2019 at 05:19:34PM +0100, Public mailing list
for Arch Linux development wrote:
Following up on xyproto's [community] cleanup, here is a list
of unrequired
orphans in [extra] which could be removed (minus the
aspell/hunspell dicts).
Please adopt them if you want to keep them
El jueves, 28 de marzo de 2019 18:17:54 (CET), Balló György via
arch-dev-public escribió:
I would adopt 'bluefish'.
Moved
Following up on xyproto's [community] cleanup, here is a list of unrequired
orphans in [extra] which could be removed (minus the aspell/hunspell
dicts). Please adopt them if you want to keep them (some of them are
clearly maintained, eg. vulkan stuff). If you ∈{TU's}\{devs} and want to
The usual reminder that, due to Qt's ABI versioning, any Qt application built
against 5.12 will depend on it, so it will need to stay in testing until Qt
itself moves.
> +1 for removing lcms1. I fixed the packages in the [community] repository.
> Someone else should fix packages in [extra], because I don't have access to
> this repository:
> - geeqie (FS#60091)
> - gimp (FS#60092)
> - xsane (FS#60090)
All fixed. lcms (and its lib32- and python2- derivatives)
El viernes, 24 de agosto de 2018 16:16:40 (CEST) Florian Pritz escribió:
> Please make a TODO list in archweb, otherwise manually checking what is
> done and what isn't is error prone.
>
I'm not very fond of adding todo lists for things that are not completely under
devs/TU's control (some
And gone. After the KDE4 and PyQt4 removal, 'pactree -sru qt4 | wc -l' went
down from 78 to 44. The full list is below: if any of your packages is in
there, please check whether it can be dropped, ported to use Qt5 or some other
toolkit. We should aim at dropping Qt4 as soon as possible, it has
I think it's time to drop the KDE4 libraries. They were EOL months ago and
most stuff that isn't yet ported to KF5 is dead upstream. This would allow
dropping a number of qt4 libraries and reduce the qt4 reverse dependencies (qt4
has been EOL for 3 years now). Affected packages are:
-
Hi all,
The latest pyqt4 release makes packaging more complex due to upstream's
decision of requiring a private namespaced sip (for mysterious reasons). It is
also the last release, so pyqt4 is now officially EOL. I would like to drop it
from our repos. It's mostly used as an optional
Vacation time. Will be intermittently available via email/irc but won't do any
packaging.
> Please reply if you have objections.
> A list of modules / programs can be obtained as following or viewed here
That list doesn't take makedepends/optdepends into account. There are a few
optdepends of sagemath there (pkgconfig, pynormaliz)
Latest release has been withdrawn upstream due to multiple issues.
As usual, due to Qt's ABI versioning, everything compiled against Qt 5.11 will
get a runtime dependency on it, so it will have to stay in testing until Qt
itself moves. Keep it in mind if you plan to build Qt stuff against testing or
staging.
Other changes of interest for packagers:
- qdoc now
El martes, 13 de marzo de 2018 11:23:07 (CET) Bruno Pagani via arch-dev-public
escribió:
> Some projects seems to default to Debug instead of None… So should we
> specify a BUILD_TYPE of None instead of Release?
>
Not sure if it's a good idea to systematically override the build type when it
El domingo, 11 de marzo de 2018 21:58:16 (CET) Eli Schwartz via arch-dev-public
escribió:
> I know repository PKGBUILDs are typically built in a clean chroot, so
> cached builds make no difference there, but then neither do unquoted
> srcdir/pkgdir. It is still not helpful to people who e.g.
El domingo, 11 de marzo de 2018 19:11:13 (CET) Bartłomiej Piotrowski via
arch-dev-public escribió:
> Sounds good. I'm also surprised that it's how it works, honestly. Are
> LDFLAGS taken into account regardless of CMAKE_BUILD_TYPE? Will there a
> to do list to track the progress?
>
Yes, linker
El domingo, 11 de marzo de 2018 1:44:07 (CET) Eli Schwartz via arch-dev-public
escribió:
>
> This theoretically sounds like a fantastic idea, but I'm not really sure
> what CMake's deal with build flags are in the first place. What is the
> default build type, and does CMake even look at build
El sábado, 10 de marzo de 2018 14:34:16 (CET) Bruno Pagani via arch-dev-public
escribió:
> As long as you accept exceptions to this (I have scientific stuff in
> mind, like NetCDF — currently not built with CMake but will be in next
> release), I’m fine with this.
This is just about stopping
Hi,
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 default
C(XX)FLAGS. So, for instance, our cmake packages are being
As per David's request [1], due to schiv's unresponsiveness, I
will move all of his packages which are not dependencies of any
[extra] package in a few days to [community], where David is
willing to maintain them. Any objections?
[1]
Baptiste Jonglez Wrote in message:
> 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
>
El Wed, 03 Jan 2018 16:05:46 +0100, Bartłomiej Piotrowski via
arch-dev-public escribió:
> cryfs
> pam_mount
> sdlmame
> transcode
Adopted (but if anybody in interested please take them)
> libmatekbd libmatemixer libmateweather
These are dependencies of MATE, should be kept
El Sun, 24 Dec 2017 10:43:27 +0100, Ike Devolder via arch-dev-public
escribió:
>>
> If you could move the following to community I can keep it there:
> - libftdi-compat
Moved in svn, but the repo moved failed because of missing .BUILDINFO.
Please rebuild it in community and I'll remove the
El Sun, 24 Dec 2017 11:15:52 +0100, David Runge escribió:
> I would take over
>
> ssmtp
>
> if it wasn't in [extra].
Moved
El Mon, 18 Dec 2017 10:54:37 +0100, Bartłomiej Piotrowski via
arch-dev-public escribió:
> - clamz:
> ronald: amarok arojas: amarok
Rebuilt amarok without it and dropped
> - double-conversion:
> fyan: qt5-base arojas: qt5-base
Adopted
> - qtscriptgenerator:
> ronald: amarok arojas:
El Mon, 18 Dec 2017 12:05:58 +0100, David Runge escribió:
>
>> - fltk:
>> ronald: octave schiv: alsa-tools arojas: libgiac, xcas arodseth:
>> tuxpaint-config, monica dvzrv: zynaddsubfx kkeen: xdiskusage, dillo
>> lfleischer: lmms spupykin: tigervnc
> Can't adopt the above, as they
Qt 5.10 is now in [testing]. Note that, due to Qt symbol versioning
schema, every Qt application automatically gets a dependency on the minor
Qt version it was compiled against, so Qt applications compiled against
[testing] will have to wait in testing until Qt itself moves. Keep this
in mind
El Sat, 02 Dec 2017 20:18:44 +, Jan Alexander Steffens via
arch-dev-public escribió:
>
> That's the question. I'm not even sure (but more confident) that we need
> libmagick6. I have the complete set ready, but we can still drop the
> packages that we later determine are not needed.
Last
El Sat, 02 Dec 2017 19:53:10 +, Jan Alexander Steffens via
arch-dev-public escribió:
> Hi list,
>
> if nobody objects I would like to start an upgrade to ImageMagick 7.
>
> The plan is:
> - Split imagemagick into (libmagick imagemagick imagemagick-doc).
> - Add imagemagick6, split into
44 matches
Mail list logo
