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.
Re: [arch-dev-public] Orphan mono packages
El Wed, 18 Oct 2017 11:08:06 +, Antonio Rojas escribió: > monodevelop > xsd > mod_mono > mono-basic > boo > mono-debugger > mono-upnp > gtk-sharp-beans > gettext-mono All dropped
[arch-dev-public] Orphan mono packages
After Daniel's resignation, mono related packages became orphan. anthraxx and grazzolini adopted nuget and mono itself, but the following packages still don't have a maintainer: monodevelop xsd mod_mono mono-basic boo mono-debugger mono-upnp gtk-sharp-beans gettext-mono and others I may have missed. mono stuff breaks frequently (in fact most of these packages don't build currently) so they need a dedicated maintainer. Please adopt them if you're interested (or reply here so they're moved to community if you're a TU), otherwise I'll drop them in a few days.
[arch-dev-public] Away until 18 Aug
It's vacation time. Will have intermittent internet access but no signing key. Feel free to fix/update anything, just make sure not to break Sage if you touch any of its dependencies.
[arch-dev-public] Outdated orphans
The following packages are orphan and outdated, some of them for months or even years, and some have been broken for a while (FS#54615). If you're interested, please adopt them and fix them, otherwise they should be removed so they can be properly maintained in AUR - xen (xenstore, xe-guest-utilities, python2-xenstore) - openvas (-cli,-libraries,-manager,greenbone) - ironpython - gdc (we already ship 2 other D compilers also unmaintained, do we need 3? - taskjuggler3 - xbase - xmind - ypbind,ypserv,yp-tools (dep of archboot, is it useful?)
Re: [arch-dev-public] Replacing qt5-webkit
El Wed, 14 Jun 2017 16:53:29 +, Antonio Rojas escribió: > Latest version 5.212.0 should have feature parity with the old > qt5-webkit and be ready to replace it. If there are no objections, I > will add replaces=(qt5-webkit) and drop the old insecure qt5-webkit in a > few days. > Please give it some testing if you haven't done so yet. Actually I just found out from the developer that his fork has been merged in upstream Qt already [1]. So I will simply update the qt5-webkit package to his latest release instead of replacing it with -ng [1] http://code.qt.io/cgit/qt/qtwebkit.git/log/?h=5.212
Re: [arch-dev-public] Replacing qt5-webkit
El Sat, 21 Jan 2017 13:37:40 +, Antonio Rojas escribió: > Continuing with the trend of replacing insecure packages: qt5-webkit has > been deprecated upstream for a long time already. It is still being > community released, but it is on life support with only build fixes, and > the webkit code itself hasn't been updated since 2013, so it's plagued > with security issues by now. The "official" replacement qtwebengine has > its own issues (eg. crashes on nouveau) and some projects are reluctant > to move to it. > > In this case removing the package is out of the question, as some > important packages (such as Plasma) depend on it. Fontunately someone > took up the job of maintaining a fork [1] based on the latest webkit > code. The aim is to have this shipped with upstream Qt eventually, but > that could still be many months away. > > I've packaged this fork as qt5-webkit-ng. It should be a drop-in > replacement for qt5-webkit, please test it and if it's good enough we > can consider replacing the old qt5-webkit package with it. > > [1] https://github.com/annulen/webkit/wiki Latest version 5.212.0 should have feature parity with the old qt5-webkit and be ready to replace it. If there are no objections, I will add replaces=(qt5-webkit) and drop the old insecure qt5-webkit in a few days. Please give it some testing if you haven't done so yet.
Re: [arch-dev-public] wxgtk split
El Wed, 07 Jun 2017 19:37:44 +, Antonio Rojas escribió: > > If you maintain a wx-based package, you may want to try switching to > build against wxgtk3, which offers some additional features (hipdi, > smooth scrolling, touchscreen support). Packages using wx-webview (boinc, moneymanagerex and perhaps some other via wxpython) should get high priority for porting. Besides gnucash, these are the only packages left using the insecure webkitgtk.
[arch-dev-public] wxgtk split
Hi, As you may have noticed, the wxgtk package is now a split package that build both gtk2 and gtk3 versions. The gtk2 package is a drop-in replacement for the old wxgtk package, so by default all packages will keep building against gtk2. If you maintain a wx-based package, you may want to try switching to build against wxgtk3, which offers some additional features (hipdi, smooth scrolling, touchscreen support). To allow coinstallability, the wx-config script has been renamed to wx- config-gtk3 in the GTK3 package, so in order to build against the gtk3 version the script name needs to be specified at build time (--with-wx- config=/usr/bin/wx-config-gtk3 for autotools, - DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config-gtk3 for cmake)
Re: [arch-dev-public] Improving overall experience for contributors
El Wed, 24 May 2017 13:08:18 +0200, Bartłomiej Piotrowski escribió: > We are open source distribution with pretty much closed development > model. It is unsustainable in the longer term. There are 413 orphan > packages in our repositories (excluding i686), some of the out-of-date > flags are unhandled since 2014. And those are just the literally orphan ones. We have many more virtually orphan packages due to some dev/TUs not giving signs of life for months, even years. We do have a serious manpower issue, which I think it is starting to affect the quality of the distribution (eg. several DEs are currently unmaintained), and I don't see this getting any better with our current recruiting model. I do like the idea of having a 'trial period' of a couple of months for new contributors, under the supervision of a mentor, in which they could have access to svn but not to the repos, and perhaps move the voting to the end of this period. And yes, we need a central place to communicate our needs to potential new contributors. Perhaps we could start with a wiki page until we set up something more sophisticated?
Re: [arch-dev-public] OpenSSL 1.1.0
El Thu, 23 Feb 2017 22:29:17 +0100, Christian Hesse escribió: > Mariadb is still unsolved. There is a ticket in upstream jira [0] but it > does not carry anything useful. There's a reference for a review, but I > could not find the patch in mail archive. Will try to contact the > developers and express our interest... In the meantime, is temporarily switching to internal yassl (as Debian does) an option? This is blocking all Qt rebuilds (which will also be a pain themselves), so it would be nice to have a build in staging soonish.
[arch-dev-public] Replacing qt5-webkit
Continuing with the trend of replacing insecure packages: qt5-webkit has been deprecated upstream for a long time already. It is still being community released, but it is on life support with only build fixes, and the webkit code itself hasn't been updated since 2013, so it's plagued with security issues by now. The "official" replacement qtwebengine has its own issues (eg. crashes on nouveau) and some projects are reluctant to move to it. In this case removing the package is out of the question, as some important packages (such as Plasma) depend on it. Fontunately someone took up the job of maintaining a fork [1] based on the latest webkit code. The aim is to have this shipped with upstream Qt eventually, but that could still be many months away. I've packaged this fork as qt5-webkit-ng. It should be a drop-in replacement for qt5-webkit, please test it and if it's good enough we can consider replacing the old qt5-webkit package with it. [1] https://github.com/annulen/webkit/wiki
Re: [arch-dev-public] Phasing out webkitgtk{,2}
El Thu, 19 Jan 2017 01:14:27 +0100, Balló György via arch-dev-public escribió: > > We should consider the same thing for qtwebkit, which is unmaintained too, > but it affects much more packages. Not really. The reverse dependency list is big because it contains KDE4, but there are already patches around to strip off webkit from kdelibs. Once that is sorted out, the number of packages that link to qtwebkit is not that big: acetoneiso2 bibletime clipgrab fcitx-libpinyin freecad freemat gambas3-gb-qt4-webkit kbibtex kchmviewer krecipes kvirc python-pyside qlandkartegt qt4pas wkhtmltopdf amarok k3b python-pyqt4 qtscriptgenerator So +1 to both, I'm all for dropping unmaintained stuff. As for the webkitgtk list: pan is built without webkit support now.
Re: [arch-dev-public] Moving arduino into [community] important notes
El Mon, 28 Nov 2016 01:34:38 +0100, Bartłomiej Piotrowski escribió: > There is no way to remove epoch, ever. I know it looks ugly for some > packagers, but there is nothing to be ashamed for. We have it for a > reason, and if it's been added, it stays. I thought AUR packages were unsupported. Sure, it is nice to give them a higher version number when they are moved to the official repos to allow for a smooth upgrade, but that shouldn't be an enforced rule IMO. And removing epoch is a reasonable enough reason not to do it.
Re: [arch-dev-public] Long out of date packages
El Thu, 20 Oct 2016 04:24:10 +0600, Ray Rashif via arch-dev-public escribió: > - liblo: this was flagged by me as a reminder based on a user's e-mail > [1] > - ardour: awaiting testing - libffado: compilation issues, didn't dig > [2] > . > [2] Help appreciated in identifying the patch or at least the cause. Fedora patch: http://pkgs.fedoraproject.org/cgit/rpms/libffado.git/tree/libffado-gcc6.patch
Re: [arch-dev-public] New TeXLive 2016 packages in [testing]
Rémy Oudompheng via arch-dev-public wrote: > > Done. > > I have also removed verbosity in the hooks. They is still an install > script for texlive-bin and texlive-core because rebuilding the formats > file has a dependency on the hooks being run. > > I need more work to move the format files to a framework like the > "maps" files, so that they are also managed by hooks (it will also > remove potential warnings and instabilities during install/upgrades). > > Rémy. Thanks for the update. So is it safe to remove the install files from tex packages now? AFAICS the following packages are affected: extra/asymptote extra/gnuplot extra/latex2html extra/r community/auctex community/hevea community/sagetex
Re: [arch-dev-public] Long out of date packages
Florian Pritz via arch-dev-public wrote: > Can everyone please either update their packages or explain here why > each package is not being updated? If it's due to lack of interest, > please consider orphaning it and post the names of the packages here so > they can be adopted. > > If a package is flagged incorrectly, please unflag it. > +1, would also be good if devs/TUs who have been inactive for some months could give us an update on their status
Re: [arch-dev-public] Discussion about optional dependencies
In theory: +1 But splitting VLC properly is a non-trivial task. See FS#21934 if anybody wants to give it a shot (there are some issues not mentioned there, such as vlc crashing KDE applications if not all plugins are installed) Hopefully VLC 3 will make it easier. Daniel Micay via arch-dev-public wrote: > On Tue, 2016-07-19 at 03:39 +0200, Balló György via arch-dev-public > wrote: >> I agree with this, and the same apply for vlc I think, which recently >> lost >> its qt4 dependency: >> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packag >> es/vlc=b1a56bb8d107ebb51a6f2e32c67f866e2693517b >> >> -- >> György Balló >> Trusted User > > For a case like that, it should really just be a split package. As long > as there's still a main package named after the project for all the > components, split packages aren't annoying. It's rarely worth putting > in the effort to do that, but it's a much nicer way to do it than > moving the problem to users.
Re: [arch-dev-public] Hooks rebuild #1
Allan McRae wrote: > > Hrm... it was on the list I uploaded. > > $ grep kdepim rebuild.txt > kdepim > kdepimlibs > kdepimlibs4 > kdepim-runtime Ah, so the issue is todo lists not accepting pkgbases as input > You have obviously figured it out so who cares... Yeah but there could be more packages affected
Re: [arch-dev-public] Hooks rebuild #1
Allan McRae wrote: > On 28/04/16 21:18, Antonio Rojas wrote: >> Allan McRae wrote: >> >>> No idea... I generated the list via a quick grep, so there are false >>> positives (more than I expected...). Just mark them as done. >>> >>> A >> >> It seems that it also didn't catch install files from split packages, eg. >> kdepim or kdewebdev are missing from the todo list. >> > > Is the base package there? No, neither the base package nor any of its subpackages.
Re: [arch-dev-public] Hooks rebuild #1
Allan McRae wrote: > No idea... I generated the list via a quick grep, so there are false > positives (more than I expected...). Just mark them as done. > > A It seems that it also didn't catch install files from split packages, eg. kdepim or kdewebdev are missing from the todo list.
Re: [arch-dev-public] Dropping kdebase-workspace
Antonio Rojas wrote: > TL;DR: kdebase-workspace is dead and should be dropped from the repos > ...and it's gone
[arch-dev-public] Dropping kdebase-workspace
TL;DR: kdebase-workspace is dead and should be dropped from the repos The KDE4 Plasma desktop has been in maintenance mode for a few years and is EOL since last August (the git repo has been locked, so not even security fixes are allowed). We've been trying to support it alongside Plasma 5 for as long as possible, but this requires some packaging efforts, lots of duplicated KDE4 versions of libraries (also unmaintained) and is starting to cause some issues (FS#46730). Plasma 5 has been around for over a year, 5.5 has just been released and should be stable enough to replace KDE4. Therefore, I would like to drop the following packages from our repos: kdebase-workspace kdeartwork kde-wallpapers kdebase-plasma kdeplasma4-addons bluedevil4 kscreen4 kdeplasma-applets-plasma-nm kcm-touchpad There are a few other packages which currently depend on kdebase-workspace: ktorrent - can be compiled without linking to kworkspace (will lose the shutdown plugin) knemo - there is a working frameworks branch, we should switch to it digikam - will lose the theme chooser (not a big loss) openbox - simply calls startkde, so the dependency just needs to be changed to plasma-workspace qtcurve - the configuration UI has been ported to KF5 over a year ago, but there is no release yet - we should package a git snapshot, the current version is too old anyway I don't plan to automatically upgrade to Plasma 5; this would be difficult technically due to the split packages and also the configuration is not migrated, so it's better to let users upgrade manually. Note that this affects the KDE4 desktop only: KDE4 applications (kde-runtime) are still supported and will be for the foreseeable future. Any objections?
Re: [arch-dev-public] On pushing a standalone opencv 3.x
Rashif Ray Rahman wrote: > > If there are no objections, I'll go ahead and push 3.x, which should > co-exist fine with 2.x. I suppose it's OK to break our naming > convention in cases like these. > Have you checked if this is actually still needed? At least KDE packages (digikam, kipi-plugins, libkface) support opencv3 already.
Re: [arch-dev-public] Integrity Check x86_64: core, extra, community, multilib 27-03-2015
repoma...@archlinux.org wrote: Missing Dependencies -- extra/kdeplasma-applets-plasma-nm -- 'libnm-qt' What's the problem here? libnm-qt is provided by libnm-qt4
