Re: [arch-dev-public] Autumn extra cleaning
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 just dumping a list of packages. Taken: chromaprint convertlit freetds gnugo id3lib liblqr libmng telepathy-farstream I have zero interest in any of them besides them being dependencies of other packages I maintain, so comaintainers welcome. Most of them are dead upstream anyway.
Re: [arch-dev-public] Autumn extra cleaning
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 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] That list contains many packages that are dependencies of other packages in [extra]. Do we officially no longer care about repo hierachy?
Re: [arch-dev-public] HEADS UP: Qt 5.15 in [testing]
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 maybe worth a shot. While it is true that the patch fixes the build, that was not the only (or the main) reason I wanted to get rid of this package. It is long dead upstream (last commit was 3 years ago) and most styles crash when you try to use a modern QML application. I've seen complaints from the KDE devs due to the amount of crash reports they're getting caused by this. These are just a few from the last couple of months: https://bugs.kde.org/show_bug.cgi?id=418917 https://bugs.kde.org/show_bug.cgi?id=419259 https://bugs.kde.org/show_bug.cgi?id=420024 https://bugs.kde.org/show_bug.cgi?id=420399 https://bugs.kde.org/show_bug.cgi?id=421092 https://bugs.kde.org/show_bug.cgi?id=421846
Re: [arch-dev-public] HEADS UP: Qt 5.15 in [testing]
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
[arch-dev-public] HEADS UP: Qt 5.15 in [testing]
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.
Re: [arch-dev-public] Spring cleaning (moving orphaned packages from [community] to AUR)
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 of [community] packages, as > > is tradition. > > > > I have gathered a list of "unneeded orphans" in [community] (packages that > > currently has no maintainer, and no other package depends on them) from the > > excellent list on our web page. > > Hi Alexander, > What's the status of this? It's been almost two months. If you don't have > time currently, I can go ahead and drop the remaining packages to AUR. > And done (except for dictionaries, which require close to zero maintenance)
[arch-dev-public] moving dhcpcd to [extra]?
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 it to [extra]?
Re: [arch-dev-public] Spring cleaning (moving orphaned packages from [community] to AUR)
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 maintainer, and no other package depends on them) from the excellent list on our web page. Hi Alexander, What's the status of this? It's been almost two months. If you don't have time currently, I can go ahead and drop the remaining packages to AUR.
[arch-dev-public] Yet another missing solink announcement
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 -Syu --overwrite usr/lib/libzn_poly-0.9.so to perform the upgrade.
[arch-dev-public] Disowned python/flask packages
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.
Re: [arch-dev-public] libx11/xorgproto dependency
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 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. > > 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. > > 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. I'm fine with either (a) or (b), both can be seen as correct for some definition of "dependencies". But please not (c), it doesn't really fix anything and it's an unnecessary divergence from our usual practice of not having split devel packages.
Re: [arch-dev-public] Missing bugtracker assignment emails
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 it looks like the assignment emails themselves are not sent correctly and you might not have noticed this. Please look over your bug assignments on the tracker in case you haven't ... Just for the archive: We seem to have emails now somehow. Morten confirmed this today in IRC when I assigned a bug to him. If this comes back, at least we'll remember it worked for him and me today. I missed emails for some comments in my assigned bugreports yesterday, so this is definitely not completely fixed. It just happens randomly.
[arch-dev-public] Qt 5.14 in [testing]
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.
[arch-dev-public] HEADS UP: Qt 5.13 in [testing]
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.
[arch-dev-public] Dropping Qt4
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
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?
Re: [arch-dev-public] Spring cleaning (take 2)
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 (some of them are clearly
maintained, eg. vulkan stuff). If you ∈{TU's}\{devs} and want to maintain
something, reply and I will move it to [community]. Will start dropping
stuff in a week.
All remaining ones dropped, except for icewm and fvwm (they seem fairly
popular and have active upstreams)
Re: [arch-dev-public] Spring cleaning (take 2)
El jueves, 28 de marzo de 2019 18:17:54 (CET), Balló György via arch-dev-public escribió: I would adopt 'bluefish'. Moved
Re: [arch-dev-public] Spring cleaning (take 2)
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
maintain something, reply and I will move it to [community]. Will start
dropping stuff in a week.
alsaplayer
artwiz-fonts
bluefish
bluez-firmware
bootchart
di
enlightenment16
epplet-base
fetchmail
fonts-tlwg
foobillard++
fvwm-crystal
fyre
geeqie
glsof
gnome-alsamixer
icewm
idnkit
linux_logo
lua-luajson
sbsms
scim-anthy
scim-hangul
scim-m17n
scim-pinyin
scim-tables
scim-uim
streamripper
thinkfinger
ttf-arphic-ukai
ttf-arphic-uming
ttf-baekmuk
ttf-cheapskate
ttf-freebanglafont
ttf-hannom
ttf-khmer
ttf-mph-2b-damase
ttf-sazanami
ttf-tibetan-machine
ttf-ubraille
vulkan-extra-layers
vulkan-trace
wpa_actiond
xbill
xfig
xmahjongg
xsnow
[arch-dev-public] HEADS UP: Qt 5.12 in [testing]
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.
Re: [arch-dev-public] rename lcms -> lcms1
> +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) can now be dropped.
Re: [arch-dev-public] Dropping KDE4 libs
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 packages have not been ported upstream yet). It will just sit there unfinished for months and we will eventually forget about it. Once we decide it's time to drop qt4, we can open a todo list with a deadline after which packages that are still not ported will be dropped.
Re: [arch-dev-public] Dropping KDE4 libs
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 been EOL for 3 years already. $ pactree -sru qt4 | sort ams appmenu-qt4 chinese-calendar clementine fbreader fcitx-qt4 freemat gambas3-gb-qt4 gambas3-gb-qt4-ext gebabbel gnuradio-companion hydrogen ibus-qt keepassx keepassx2 launchy libdbusmenu-qt4 libechonest liblastfm-qt4 liblightdm-qt4 libmygpo-qt4 licq lmms mixxx mumble murmur openssh-askpass projectm-jack projectm-pulseaudio projectm-qt qjson qmpdclient qt4 qt-assistant-compat qtcurve-qt4 qtiplot qwt5 qwtplot3d scribus sni-qt tipp10 tuxcards v4l2ucp x2goclient
[arch-dev-public] Dropping KDE4 libs
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: - recorditnow (there are many alternatives available) - ligthdm-kde-greeter (dead upstream, no signs of KF5 porting) - krecipes (dead upstream, no signs of KF5 porting) - kdiff3 (has been ported to KF5 for a while, just needs a release. Could be updated to a snapshot) - pidgin-kwallet (uses kwallet dbus API, so should work with the KF5 version without any modification) - libreoffice-still (would lose the KDE4 VCL, which is quite buggy anyway. LO-fresh has a new VCL that uses KF5 file dialog) - amarok: it has a WIP KF5 port, but it's not quite ready and development is stalled. IMO we should let it rest in peace - I can keep a KF5 snapshot in kde-unstable for a while but it doesn't look like it's going anywhere any time soon at the current development pace. There are a few alternatives in the repos. Comments?
[arch-dev-public] Dropping pyqt4/pyside1
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 dependency of python packages that also support a pyqt5 backend, so it shouldn't cause much trouble. Other packages that require it (gnuradio, hgview) have alternative UIs (wxwidgets and ncurses respectively). And in any case, pyqt4 is not a build-time dependency, so the pyqt4 UI would still work by installing pyqt4 from AUR. Besides these, the only package that still needs it is ninja-ide. It is ported to PyQt5 in git, so it could be updated to a snapshot. I'd also like to drop pyside1, for the same reasons (unused/EOL). This would reduce the number of reverse qt4 dependencies, and bring us closer to dropping it. Any comments or objections?
[arch-dev-public] Away until Aug 17
Vacation time. Will be intermittently available via email/irc but won't do any packaging.
Re: [arch-dev-public] Removing 'orphan' python2 modules
> 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)
[arch-dev-public] Notice: sip 4.19.{9,10} removed from [testing]
Latest release has been withdrawn upstream due to multiple issues.
[arch-dev-public] HEADS UP: Qt 5.11 in [testing]
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 relies on the clang code parser to generate docs. Since qt5-tools contains many other unrelated stuff I've only made it an optdepend. If your package uses qdoc to generate docs you'll need to explicitely add clang as a makedepend. - there's been a huge header cleanup in Qt modules. Expect build failures for applications that rely on transitive includes instead of declaring all required headers. Those need to be fixed upstream by explicitely adding the missing includes.
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
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 has been explicitely set by upstream. Some projects may be doing so for good reasons. Although explicitely setting it to Debug in a release tarball seems odd, do you have any example of such a project?
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
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. check out a > PKGBUILD from svntogit and rebuild it locally for any of a number of > reasons to have unpredictable behavior due to assumptions about always > building in a clean chroot. So I think maybe we should still (or start?) > specifying this. You don't need to build in a clean chroot to prevent this from happening, you just need to make sure you clean up your build dir before rebuilding after having changed the build flags, which IMO is a reasonable assumption to make.
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
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 flags work the same way: CMAKE_SHARED_LINKER_FLAGS is taken from the env LDFLAGS and then the different build types append stuff to it (Release doesn't seem to add anything here). If everybody agrees with the change, I'd prefer mass-removing it from svn - I'd rather not add yet another huge todo list that will be sitting there unfinished for months.
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
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 flags from the
> environment at all (at least in a sane manner)?
This is very poorly documented, so you have to dig into the cmake code to
figure it out. The default build type is None, which means CMAKE_C(XX)_FLAGS is
used (see /usr/share/cmake-3.10/Modules/CMakeCInformation.cmake:117), whose
value is taken from the environment C(XX)FLAGS (see
/usr/share/cmake-3.10/Modules/CMakeCXXInformation.cmake:198). So yes, not
setting CMAKE_BUILD_TYPE will simply use the build flags from C(XX)FLAGS. If
you want to test yourself, run cmake with the -LAH flag and check the output
for CMAKE_C(XX)_FLAGS.
> For example, I am currently the maintainer of a package that has,
> apparently, historically used:
>
> -DCMAKE_C_FLAGS:STRING="${CFLAGS}" \
> -DCMAKE_CXX_FLAGS:STRING="${CXXFLAGS}" \
> -DCMAKE_BUILD_TYPE=Release \
The first two lines should not be necessary (see above)
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
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 systematically doing this. Of course particular packages may have to modify their build options for certain reasons (although personally I'd prefer if it was done transparently by setting the C(XX)FLAGS explicitely instead of relying on semi-obscure cmake presets)
[arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
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 built with -O3 instead of our default -O2. Besides the inconsistency that this brings to our binaries, IMO it's not a good idea to override our default C(XX)FLAGS unless there's a good reason to. This will also cause issues once we start building debug packages by default (-DCMAKE_BUILD_TYPE=Release also adds DNDEBUG). Therefore I'm proposing to drop -DCMAKE_BUILD_TYPE from all our cmake packages, building them with our default C(XX)FLAGS as all other packages. Comments?
[arch-dev-public] Moving schiv's packages to [community]
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] https://lists.archlinux.org/pipermail/arch-proaudio/2018-Janua ry/50.html
Re: [arch-dev-public] Packages sometimes fail to build: "Failed to attach XXXX to compat systemd cgroup /user.slice/user-1000.slice/session-c1.scope/payload: No such file or directory"
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 > 16:06:22 CET 2018) > ==> Retrieving sources... > -> Updating ring-client-gnome git repo... > Fetching origin > ==> Validating source files with sha256sums... > ring-client-gnome ... Skipped > Failed to attach 9683 to compat systemd cgroup > /user.slice/user-1000.slice/session-c1.scope/payload: No such file or > directory > Failed to attach 9661 to compat systemd cgroup > /user.slice/user-1000.slice/session-c1.scope/supervisor: No such file or > directory > Failed to chown() cgroup > /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-c1.scope/payload: > No such file or directory > Parent died too early > ==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/zorun/build > > > Any idea? > Baptiste > Had the same issue yesterday, a relogin fixed it
Re: [arch-dev-public] 2017 repository cleanup
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
Re: [arch-dev-public] 2017 repository cleanup
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 [extra] package afterwards.
Re: [arch-dev-public] 2017 repository cleanup
El Sun, 24 Dec 2017 11:15:52 +0100, David Runge escribió: > I would take over > > ssmtp > > if it wasn't in [extra]. Moved
Re: [arch-dev-public] 2017 repository cleanup
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: amarok Adopted (hopefully to be dropped soon) > - xsd: > fyan: libkolabxml arojas: libkolabxml Adopted > Unneeded orphans: > gmic krita-plugin-gmic Adopted > mate-applet-dock mate-applet-streamer > mate-applets mate-backgrounds mate-calc mate-common mate-control-center > mate-desktop mate-icon-theme mate-icon-theme-faenza mate-media mate-menu > mate-menus mate-netbook mate-notification-daemon mate-panel mate-polkit > mate-power-manager mate-screensaver mate-sensors-applet > mate-session-manager mate-settings-daemon mate-system-monitor > mate-terminal mate-themes mate-user-guide mate-user-share mate-utils Mate is fairly popular and quite low-maintenance. I will take care of it (as I've been doing lately) if noone else takes it, but will not adopt it as I want it to be clear that it needs a proper maintainer.
Re: [arch-dev-public] 2017 repository cleanup
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 are in [extra] > Moved to [community]
[arch-dev-public] Heads up: Qt 5.10 in [testing]
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 if you plan to push any Qt application to testing.
Re: [arch-dev-public] ImageMagick 7
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 time a tried not a single package that links to libmagick was building with 7, so I'd be surprised if libmagick6 wasn't needed.
Re: [arch-dev-public] ImageMagick 7
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 (libmagick6 imagemagick6). No docs. > > libmagick and libmagick6 contain the parallel-installable libraries. > > imagemagick and imagemagick6 conflict with each other, containing the > tools, the perl module and the conflicting build files. > > We'll need some rebuilds, of course. > > Thoughts? Will imagemagick6 (the tools) still be needed after we ship IM7? I'd rather not ship two versions of the tools if that's possible.
