Re: [arch-dev-public] Orphaned packages from arcanis
On 2020-11-21 20:09:12 (+0100), Morten Linderud via arch-dev-public wrote: > - mftrace: > arcanis: lilypond > dvzrv: lilypond I've adopted this package and also * netpbm * gsfonts As they were orphaned makedepends of lilypond. Maybe it's even possible to use a less ancient guile for the latter... Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] away until next year
Hi all, from tomorrow on I'll be on holidays until early next year. While I will check my mails I won't necessarily be in places with good network connection. If anything comes up, feel free to bump my packages. I hope you all have a relaxing rest of the year. Stay healthy! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping arptables/ebtables
On 2020-12-11 10:28:27 (+0100), Sébastien Luttringer via arch-dev-public wrote: > I would like stop maintaining arptables and ebtables and drop them in > [unsupported]. > The future in the linux kernel is clearly nftables and keeping them in the > repository present is of little interest these days. > > ebtables is still an hard dependency on others packages, but the iptables-nft > package ship a remplacement based on nftables. I have not tested the > compatibility, so if someone think it's not possible, please let me know. I believe kubelet does not work with nftables (yet). There needs to be testing for this. It seems lxd is also affected. > If you have spare time, I suggest you take a look at the nftable package and > become a master in nft-fu. It is much more convenient and efficient than the > iptables / ipset / ebtables / arptables solution. For the less enthusiastic > about the command line, firewalld has an nftables backend. I agree. I have been using it on all of my machines for quite some time. Especially in the last two years the upstream wiki documentation has also improved significantly. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Add active Python versions to the repos
On 2020-11-21 14:34:24 (+), Filipe Laíns via arch-dev-public wrote: > Hi all, > > I want to propose adding all active Python versions to [community], not > just the latest one. This would only entail adding the interpreter > itself, no other packages. > > Having access to interpreters for older active versions is really > helpful for Python developers. This allows them to easily run test > suites against older versions. It is very common for developers to > maintain software against a couple major releases. Tools like tox or > nox are able to automate testing against multiple Python versions, just > needing the interpreter. > > The current active Python releases are: > - 3.9 > - 3.8 > - 3.7 > - 3.6 > - 2.7 > > The list can be found here[1]. > > So, I propose introducing 2 new packages: > - python3.7 > - python3.6 > > And when we update the python package to 3.9: > - python3.8 > > Does anyone have any big issue with this? What are your thoughts? I guess a downside is the increase in maintenance burden to provide this and it potentially leading to things not being ported/ fixed (ergo fragmentation) as maintainers might want to rely on several interpreters being around in the future (to build packages against). However, as you are specifically stating you would like to only have the interpreters added, maybe that's fine? An alternative (in a per-user setup) can be to use pyenv [1]. It works reasonably well with tox etc. and I have used it in the past successfully to develop against several python interpreter versions. Best, David [1] https://www.archlinux.org/packages/community/any/pyenv/ -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] [signoff] [extra] postfix-3.5.8-1
Hi all! I recently upgraded the postfix package and made quite a few adjustments (e.g. using tmpfiles.d instead of a 1000 line POSIX shell script, splitting shared libraries and applying mild hardening on the postfix.service). As for many setups postfix is probably rather mission-critical it would be excellent to get some signoffs on it. Specifically it would be good to test setups in which postfix is not handling virtual mailbox setups, but is using unix user setups (due to the changes introduced to the service file). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] News draft: Accessibility features added to installation media
Hey all, below is the news item I would like to post once the installation medium is released some time tomorrow: ``` We are very happy to announce that accessibility features have been added to our installation medium with [archiso v49](https://gitlab.archlinux.org/archlinux/archiso/-/tags/v49). From release 2020.11.01 onwards these are available via the 2nd boot loader menu item. Many thanks go to Alexander Epaneshnikov who integrated the features from the [TalkinArch](https://wiki.archlinux.org/index.php/TalkingArch) project into archiso's releng profile, which is used for creating the installation medium. Note: The bootloader timeouts have been set to 15s to allow blind users to select the menu item as the bootloaders themselves do not offer accessibility features. The timeout is stopped as soon as e.g. an arrow key is pressed. ``` If you have improvement suggestions, please let me know! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] archiso v49 with new features
Hey all! So, there are some exciting news for the upcoming archiso release! Maybe some of you have followed the presentations during Arch Conf 2020. I did one on archiso. The upcoming v49 will include accessibility features for blind and visually impaired, making it possible to install Arch Linux with the help of auditory feedback. Not only the resulting ISO itself has accessibility support now, but also the script to test a built image locally - run_archiso (via an option flag). Many thanks go to Alexander Epaneshnikov for spending the time to integrate his efforts from the talking-arch project into our builtin releng profile! Additionally, the use of build.sh scripts per profile has been removed. This is due to the fact that archiso has moved to (mostly) declarative profiles, which makes creating profiles less complicated (as now only mkarchiso is required to build a profile). There are still a few outstanding rough edges, but most of those are already tracked and I believe we have arrived at a pretty decent state by now. Many thanks go to nl6720 for a lot of brainstorming, implementing, breaking and fixing! :) If this mail reads like a changelog, then well, it is because I don't have a changelog in the project yet! ;-) Apart from that I thought it might be worthwhile to write a news item about it after the next ISO has been released and share the above two changes on the website. What do you think? Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Mail server migration
On 2020-10-24 18:58:49 (+0200), Jelle van der Waa wrote: > The migration is finished successfully. If you have problems accessing > your email via IMAP, please report your issue in #archlinux-devops. > > Greetings, > > Jelle Awesome stuff! Thanks for the move! \o/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Packages added to todo list 'Remove libjpeg from depends/makedepends/optdepends and use shared object dependency'
On 2020-10-18 23:25:24 (+0300), Evangelos Foutras via arch-dev-public wrote: > David, following the concerns raised on IRC [1], is this todo getting > canceled? > > [1] no prior discussion, library with stable soname, prioritization > and scalability of adding sodeps to more packages Yes. If anyone is still interested in depending on the package rather than a manual virtual dependency (so that it can be removed), it is as easy as switching from "libjpeg" to "libjpeg-turbo". If you would like to depend on the shared object instead/also: The information on how to do that is in the mail you have received. Closing I would like to add, that I found the aggressiveness of the "conversation" that was held nothing short of off-putting. As a community we have to strive for discussing things on a technical level without reverting to personal attacks, generalization and rage. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Packages up for adoption
On 2020-10-15 04:29:52 (+0800), Felix Yan via arch-dev-public wrote: > Adopted expat, libcap, libffi, libunistring, libusb, ncurses, > wpa_supplicant and co-maintained bash, bash-completion, readline. I'll co-maintain expat, libcap, libffi, libusb, ncurses. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Autumn extra cleaning
On 2020-10-06 20:34:08 (+0200), Morten Linderud via arch-dev-public wrote: > - chromaprint: > arojas: strawberry, clementine > anthraxx: vlc, mpd > jlichtblau: kid3-common > heftig: grilo-plugins, gst-plugin-opencv, gst-plugins-bad > dvzrv: mixxx, mpd > alucryd: python-pyacoustid I'll take chromaprint > - libkate: > dvzrv: icecast > anthraxx: vlc > heftig: gst-plugins-bad-libs, gst-plugin-opencv, gst-plugins-bad > jlichtblau: ffmpeg2theora And this one > - opencore-amr: > alucryd: ffmpeg > heftig: gst-plugins-ugly > dvzrv: sox > anthraxx: avidemux-qt, avidemux-cli > - tinycdb: > dvzrv: postfix > anthraxx: powerdns And this one. > - yajl: > jelle: i3status, i3-wm > anthraxx: mpd, i3status, i3-wm > mtorromeo: libmodsecurity > bpiotrowski: crun > Foxboron: i3-gaps, crun > arodseth: io > dvzrv: mpd > coderobe: libvirt And this one. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Autumn extra cleaning
On 2020-10-05 22:05:09 (+0200), Jelle van der Waa wrote: > David, this is also an archiso dep It's archboot, not archiso :) There is no more requirement for ifplugd in archiso. -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Autumn extra cleaning
On 2020-10-05 07:16:14 (+0200), Sven-Hendrik Haase via arch-dev-public wrote: > arch-install-scripts Adopted, as it is a dependency for archiso. > gstreamer Can adopt, because Wim Taymans \o/ Unless Jan wants to maintain that further as well (alongside the plugins). @Jan how much efforts are the plugins? > mtools Adopted. It has become a dependency of archiso. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Orphaning packages/ request for co-maintainership
On 2020-09-13 17:20:44 (-0700), Brett Cornwall via arch-dev-public wrote: > I'd be happily to co-maintain the following: > > aeolus > ardour > audacity > csound > csoundqt > fluidsynth > freepats-general-midi > freeverb > pd > qjackctl > supercollider > vim-csound good stuff! Thanks! I guess apart from audacity, (sometimes) ardour, csound and (sometimes) supercollider all of the above are fairly low-maintenance. About audacity: I have not yet found the energy to work on that package again, as it requires switching to cmake (which introduces more bugs) and potentially switching to a custom wxgtk3/wxwidgets version (only for audacity!) that is a fork of the development version (to have an actual "stable" package, as upstream neither supports the stable nor the development version of wxgtk3 - that's pretty painful). I have opened a few issues on their github issue tracker irt all that. About csound: Upstream has moved a few of the opcodes to a separate repository. Maybe worth checking it out to get back Python support, etc. About supercollider: Upstream uses git-flow and sometimes fixes get swallowed up (not cherry-picked onto a release branch) when a fix was committed towards their develop branch. Other than that, it has become much more reliable to build over the years! Anyways, thanks! :) -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Orphaning packages/ request for co-maintainership
Hi all, I'm orphaning the following packages as I don't use them and/or took them over from someone who is now not a team member anymore: # [extra] ddrescue easytag (can be moved to [community]) # [community] autorandr cacti flac123 flyspray gmm gpa grub-customizer libircclient libmusicxml libopenshot libopenshot-audio libquicktime marsyas minitube nfoview nomacs openshot plowshare pound smplayer-skins smtube wiiuse zopfli The above [community] packages (if possible) will be moved to the AUR if no maintainers are found until 2020-09-28. Additionally I have many packages that I'd be happy to find co-maintainers for. If packages that you are interested in co-maintaining are not in the list below (e.g. all the pro-audio stuff) just let me know - the list would have gotten too long otherwise :P # [extra] raptor rasqal redland scons # [community] hyperkitty irker mailman3 mailman3-hyperkitty postorius qtile quodlibet radicale slimit sigal solfege subdownloader tmuxp tuna waf Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Holidays 2020-08-20 -- 2020-09-01
Hey all, I will be on holidays between 2020-08-20 and 2020-09-01 and very likely not be able to do packaging. Feel free to bump my packages. Note, that audacity would require a lot of work.. so only get on to that one if you're really up for it :-P Juce is another such candidate (but also because it currently makes the build for iempluginsuite fail). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] News draft: AUR migration
Hey Giancarlo, only some minor spell fixes. On 2020-07-27 10:46:35 (-0300), Giancarlo Razzolini via arch-dev-public wrote: > AUR migration: New SSH Host keys > > Due to the fact the AUR was migrated to a new server, the SSH HostKeys used to Due to the fact *that* the AUR *has been migrated* [..] > pushed packages were changed in the process. These are the new keys > fingerprints: *connect to the host* have changed in the process. [..] >Ed25519: SHA256:RFzBCUItH9LZS0cKB5UE6ceAYhBD5C8GeOBip8Z11+4 >ECDSA: SHA256:uTa/0PndEgPZTf76e1DFqXKJEXKsn7m9ivhLQtzGOCI >RSA: SHA256:5s5cIyReIfNNVGRFdDbe3hdYiI5OelHGpw2rOUud3Q8 > > They can also be found on the AUR home page when not logged in. *The above fingerprints* can also be found [..] > Given this is somewhat urgent and the migration was done on Friday, > I'll not wait the full 24 hours before posting this, but I'll probably > post this by the end of the day, today, instead. Let me know if anyone > has any objections. ACK Thanks! :) Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] repos.archlinux.org has been migrated to a new server
On 2020-06-25 23:36:15 (+0200), Jelle van der Waa wrote: > repos.archlinux.org, svn.archlinux.org and rsync.archlinux.org are now > on a new server which has plenty of diskspace for us to continue > packaging for a while (16T free). Thanks for this transition and the work around this! It's much appreciated! Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] moving dhcpcd to [extra]?
On 2020-04-22 11:38:33 (+0200), Antonio Rojas via arch-dev-public wrote: > 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]? Not from my side! :) -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] qemu-arch-extra, ovmf, edk2
Hi all, Over the weekend I worked on getting archiso into a more reproducible state by building edk2's UEFI Shell from scratch so we can include it into the iso instead of downloading it. I realized, that the current ovmf [1] package basically uses the same toolchain (edk2), so I created a split package for them [2]. When looking at the included qemu firmware configuration files [3], I wondered why these are there and tried to get around using them by placing symlinks into the qemu directory (/usr/share/qemu) as qemu already provides configuratino files for edk2 based ovmf pointing at its own data directory. Only afterwards I realized, that the files mentioned in the qemu firmware configuration files (/usr/share/firmware/*.json) actually target the firmware blobs packaged with qemu-arch-extra (after Anatol was trying out the package and ran into file conflicts :-/). Long story short: While a separate package (e.g. edk2-ovmf) gives us more flexibility over **how** to create those firmwares, allows for signing of secure boot firmwares in the future, staying on top of edk2 releases and allows other applications that are unaware of those files below /usr/share/qemu to use them (some, such as lxd seem to default to /usr/share/OVMF for historical reasons), it is unclear to me whether qemu configuration files should or need to be still created for it (similar to the ones found in the current ovmf package). Any insights would be much appreciated! Best, David [1] https://www.archlinux.org/packages/extra/any/ovmf/ [2] https://www.archlinux.org/packages/testing/any/edk2/ [3] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/ovmf -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Founding an Arch-releng team
On 2020-03-28 22:33:01 (+0100), Christian Rebischke via arch-dev-public wrote: > just a general idea, but wouldn't it make sense to revive the > arch-releng mailing list a bit + found a release engineering team? > > We got a few additions to our monthly releases: > > * Arch Linux Docker > * Arch Linux Vagrant Boxes > * Arch Linux Cloud Images (soon) > * Arch Linux Tarball > > Would be cool, if we could manage to revive the #archlinux-releng > channel on freenode, revive the mailing list and maybe even have > weekly meetings, like the devops team has. That sounds like a good idea actually. IMHO the effort to streamline this further is a team effort. A lot of work in the container direction has already been done by you, which is great! The arch-releng mailing list is not dead though. Contributions are happening, but unfortunately there's noone to merge them after review currently. I didn't even know #arch-releng existed. Idling there now! :) Also, I got an offlist offer for help from someone who has seemingly been working towards build automation of sorts. I guess someone needs to add my SSH key to the repo for things to progress further. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Looking for an Arch ISO maintainer
On 2019-11-11 09:40:14 (-0300), Giancarlo Razzolini via arch-dev-public wrote: > But, we still don't have anyone wanting to become the actual > maintainer of archiso to help implement these changes. I'd be up for it. I have some ideas around certain possible test scenarios in regards to packer and ansible already. What is currently still unclear to me is how the archiso and bootstrap images on our download page are exactly generated from archiso (the actual specific calls) and whether a semi-automated way of doing that exists (I guess this question is aimed towards Pierre). I would like to automate this as far as possible and make this more transparent when maintaining archiso. How do we go on from here? Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] News draft: hplip 3.20.3-2 update requires manual intervention
On 2020-03-18 16:14:12 (+0100), Andreas Radke via arch-dev-public wrote: > News draft - https://bugs.archlinux.org/task/61329 > > The hplip package prior to version 3.20.3-2 was missing the compiled > python modules. This has been fixed in 3.20.3-2, so the upgrade will > need to overwrite the untracked pyc files created. If you get errors > like these need to overwrite the untracked .pyc files that were created. If you get errors such as these: > hplip: /usr/share/hplip/base/__pycache__/__init__.cpython-38.pyc exists > in filesystem hplip: > /usr/share/hplip/base/__pycache__/avahi.cpython-38.pyc exists in > filesystem hplip: > /usr/share/hplip/base/__pycache__/codes.cpython-38.pyc exists in > filesystem hplip: [..] > when updating, use > > pacman -Suy --overwrite /usr/share/hplip/\* > > to perform the upgrade. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Vacationing
Hi all, I'll be out until Wednesday (2020-02-26) in a location with likely very limited internet access and will not be updating packages. If there are any urgent updates required, of course feel free to do them! In the case of libgit2 rebuilds, I got stuck on ruby-rugged, as a subset of the integration tests fail with the new version of libgit2 (and a different subset with the current version of libgit2). I will not be touching this until then. Again: If the upgrade proves to be urgent, feel free to spend time on this. Thanks! :) Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] mailman3/hyperkitty/postorius in the repos now
On 2020-02-02 19:24:15 (+0100), Sébastien Luttringer via arch-dev-public wrote: > Great! So happy you moved forward. I'll test your work with my > building co-owner mailing list. Please be aware, that you might still hit bugs and such! Integration is probably not really there yet. But also: \o/ I'm able to test the import of (small) archives and mailing lists on my own infrastructure when I'm home. Really interesting would be the proper rollout of a test list on some infrastructure and the gathering of insights from that. > For the record, the new mailman (3.x) ecosystem is split into several > components (with different git and version), while the current version > (2.x) has all in one scm. Yes. The three most basic components are mailman(3), hyperkitty and postorius. As hyperkitty and postorius are optional, they can be run on a different or the same host, or not be used at all (no archiving and no clicky web-frontend for managing accounts then respectively). > I remember you planned to name the package against the components > names. Why did you named mailman-core to mailman3? In reality mailman-core is really mailman (both the repository and the python module are called mailman). My plan is to rename/replace mailman3 with mailman eventually (when mailman(2) has been gone from the repos for some time). > As soon as we don't require mailman 2.x on our infra, I plan to move > mailman to AUR. That's great! Would be awesome to introduce it as mailman2 then and make it conflict with the mailman(3) in the repos (they both share the same state dir and user). Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] mailman3/hyperkitty/postorius in the repos now
Hey all! I'm just on my way home from FOSDEM - train time, mail time ;-) I've spent the last weeks bringing the mailman3 ecosystem(!) to [community] and [community-testing] (~56 packages). Today I've added wiki pages for mailman3 [1] (it will replace the current mailman page once it's done by moving that to be 'mailman2' and eventually deleting it), hyperkitty [2] and postorius [3]. I've done initial integration tests with mailman3, hyperkitty and postorius and they "should just work"(TM). Before moving all the stuff to [community] and replacing the wiki page, it would be great to get some further integration testing with actual mail servers (note the expansion macro [4] in the mailman article) and importing of mailman2 data [5] [6] going. Any help is very much appreciated, as the switch requires quite the data migration and configuration changes for e.g. our own lists (the archives of some of them are pretty large). Additionally, the hosting aspects of both Hyperkitty and Postorius need some expansion as well (e.g. for Apache setups and for proper subdomain setups). Everyone, feel invited to install and test the applications and propose fixes and expansions to the documentation (or packages) as needed. Best, David [1] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman [2] https://wiki.archlinux.org/index.php/Hyperkitty [3] https://wiki.archlinux.org/index.php/Postorius [4] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Integrate_with_a_mail_server [5] https://wiki.archlinux.org/index.php/User:Davezerave/Mailman#Migrate_from_mailman_%3C_3.0 [6] https://wiki.archlinux.org/index.php/Hyperkitty#Importing_mailman2_archives -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] zstd rollout complete
On 2019-12-27 16:31:22 (+0100), Robin Broda via arch-dev-public wrote: > Happy packaging and greetings from 36c3. \000/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] libx11/xorgproto dependency
First of all, thanks for doing the cleanup! :) On 2019-12-21 09:41:46 (+0100), Andreas Radke via arch-dev-public wrote: > Please vote. I'd go for b) as to me it seems the more correct approach (and doesn't require introducing further packages). Additionally, it is reflected in the package guidelines [1]. I think, that the overhead of changing the packages is of course a reality, but also part of being a packager and changes like these don't happen every day. As reference: I've done a similar thing for the lv2 [2] package (which is a makedepend for all lv2 plugins and hosts, but not required at runtime) and ladspa [3] (which is a makedepend for all ladspa plugins, but not required at runtime). In the specific case of lv2 similar rules apply, as we don't have -devel packages (which is great) for e.g. suil or sratom (that require lv2 to build other things). However, upstream is currently about to change the way host applications are supposed to be build by moving all the disjointed libraries into a new conglomerate library (and is en route to introduce breaking changes to lv2). I'd rather stay overly explicit and pull in dependencies where they are needed (e.g. makedepends), which makes it more transparent to change in case of upstream change, than to rely on transitive dependencies. Best, David P.S.: I'd also love to see the provided shared libraries be exposed in the provides array of libx11 (i.e. libX11.so and libX11-xcb.so) [4]. [1] https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_dependencies [2] https://www.archlinux.org/packages/community/x86_64/lv2/ [3] https://www.archlinux.org/packages/extra/x86_64/ladspa/ [4] https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_relations -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Looking for an Arch ISO maintainer
On 2019-11-08 10:22:44 (+0100), Jelle van der Waa wrote: > To be completely honest, I am not sure what maintenance archiso > requires but there are a few things I would love to see: > > - Proper CI / automated testing of the archiso I agree and was surprised to see, that we don't really have that yet. Automated testing of archiso actually sounds pretty interesting, albeit challenging. > - Reproducible archiso (patches on the mailing list) [1] > - Support secure boot [2] > - Accessibility improvements (patches available on the mailing list) [3] I worked on a blocker around this topic (i.e. brltty). > Please reply if you are interested in becoming an archiso maintainer, > so far Alad has shown interested. I'm not exactly blessed with plenty of free time, but I'd be interested in giving it a go. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Retiring as a Trusted User
On 2019-10-02 11:10:59 (+0200), Florian Pritz via arch-dev-public wrote: > openshot libopenshot libopenshot-audio I adopted those (and libquicktime). Thank you! -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
On 2019-09-02 23:56:39 (-0400), Eli Schwartz via arch-dev-public wrote: > I've gotten several positive responses and no negative ones so far. > Although it's been noted that it might be nice to have a more > lightweight convert tool packaged, I think for now we can stick with the > one in qt5-webengine. > > Anyone else have any last-minute objections? Should I create a TODO list > for all our dictionary packages? Not that it is of our direct concern, but qt5-webengine seems to suffer from unresolved questionable licensing issues, which is why e.g. Parabola doesn't package it [1]. I don't know the specifics, but assume, that it is due to the Chromium license [2]. Best, David [1] https://www.parabola.nu/packages/?q=qt5- [2] https://github.com/qt/qtwebengine/blob/5.12/LICENSE.Chromium -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping Qt4
On 2019-04-28 12:44:45 (+0200), Antonio Rojas via arch-dev-public wrote: > hydrogen - Qt5 beta version (>1 year old) available I have just upgraded to the beta (which seems to work well enough). -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Unmaintained packages from Dan
On 2019-04-28 11:58:12 (+0200), Jelle van der Waa wrote:
> * munin{,-node}
Urgh, perl. I'm not sure I would like to do that :D
> * numactl
> * irqbalance
I could take over those, though!
Best,
David
--
https://sleepmap.de
signature.asc
Description: PGP signature
[arch-dev-public] Vacation (2019-03-21 -- 2019-04-04)
Hey all, I'll be on vacation in the timespan mentioned in the title of this mail. In case there are any urgent package updates required, feel free to do them! I might be available online from time to time, but most likely will not have the time to package anything. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Arch Conf
Fellow Archers! Some of us (in #archlinux-conf) are thinking of organizing an event for our community: A new Arch Conf! We would like to do a conference (earliest in the 2nd half of 2019), that concentrates on our internal community: The developers, trusted users and support staff. Most of us have never met in real life, which would in itself be quite nice to change. However, we also have many issues and challenges to tackle in Arch Linux. Doing a dedicated conference (in the scope of two days) again [1] seems to be a good starting point! As many of us live somewhere in central Europe, countries such as Germany have been taken into consideration. We looked at some free and paid locations in Berlin and Hamburg and Delft (The Netherlands), but nothing is decided yet. We are currently trying to figure out options for sponsorship, as we would also like to be able to (help) fly in developers from further away (without compromising). For this we would like to get more input from you. We were thinking of involvement for topics e.g. from the DevOps and security teams, but also more broad subjects, such as package repositories, bug tracker, wiki, etc. An Arch Conf will of course not only require involvement in the form of presentations and workshops, but volunteers to help prepare and handle a potential location and the event itself. Also, there should be video streaming (e.g. the VOC [2] offers free services for free software conferences) for those that can't be there. We would like to get some input from all of you regarding time, space and scope :) [1] https://web.archive.org/web/20130313105945/http://www.archlinux.ca/archcon2010/ [2] https://c3voc.de/ -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Remove svn propset id's
On 2018-08-29 22:23:07 (+0200), Jelle van der Waa wrote: > This has a few implications, pkgbuild_sha256sum is useless and we > can't reproduce packages due to the BUILDINFO not matching. Also the > reproduce tool uses ASP to retrieve the PKGBUILD and therefore can't > verify that it got the correct PKGBUILD (it relies on > pkgbuild_sha256sum). -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping KDE4 libs
On 2018-08-24 11:10:36 (+0200), Antonio Rojas via arch-dev-public wrote: > ams Will contact upstream (but project looks pretty dead, if in doubt I wouldn't wait on it) > hydrogen 1.0.0beta1 is the first Qt5-capable version. If they're too slow, I'll ship that. > lmms This should already be Qt5 capable. Rebuild incoming. > mixxx I hope this is portable! It's the only cross-platform tool for DJing. -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] jack rebuild required
Hey all, I've now created a realtime-privileges package to support a more general approach to acquiring realtime and rebuilt jack2 against those changes [2], making the aforementioned package an optional dependency for jack2 (while removing the redundant realtime settings). These changes are currently still in [community-testing]. As jack is in [extra], I'm unable to rebuild it with the changes, but I've prepared an update to its PKGBUILD [2]. I would be happy if some developer could rebuild jack with the updated build script and `svn rm jack.install, 40-hpet-permissions.rules, 99-audio.conf` before uploading. The changes have the benefit of outsourcing the settings, making it possible to reuse them in other applications, as previously discussed [3]. Best, David [1] https://lists.archlinux.org/pipermail/arch-proaudio/2018-July/000163.html [2] https://pkgbuild.com/~dvzrv/extra/jack/PKGBUILD [3] https://lists.archlinux.org/pipermail/arch-dev-public/2018-February/029172.html -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Gone until July 8th
Hey all,
I'm going to be "not so available" over the coming weeks due to my
wedding (leaving on Thursday and back July 8th).
Feel free to update packages, that are long out-of-date ('none' [1] [2]
currently).
Best,
David
[1] Latest khal is currently only adding a version pinning for
python-dateutil, which would require patching the setup.py (didn't have
time to do that yet and try to get more information out of upstream...
very slow-moving process).
[2] zita-convolver 4.0.0 introduces API changes, which break its
dependants and will require introducing the library in two versions
(will do that after I come back), for older and newer applications in
[community] to build.
--
https://sleepmap.de
signature.asc
Description: PGP signature
Re: [arch-dev-public] FrOSCon Arch Linux DevRoom
On 2018-06-10 16:25:03 (+0200), Jelle van der Waa wrote: > I've managed to get a room for Arch Linux on the Sunday of FrOSCon. > FrOSCon is a conference ran for a weekend at 25th and 26th August in > Bonn-Rhein-Sieg. It's a free event thanks to all the sponsors. Cool :) > We are free to plan our own program on Sunday, however it would be great > if we could give some talks or a workshop. Since I'm not sure how much > of the TU/Dev's can attend, community members are also welcome to mail > me with an proposal for a talk! I've just signed up in the frab and added "Pro-audio on Arch Linux", which will most likely be quite similar to the workshop at LAC2018, with some additional proper "showcases", as I won't be as crazy tired. I've added a note for the admins, that it's part of the Sunday Arch room, but I'm unsure as to how the mapping is done in frab. @Jelle: In case there's a lookup token for the "event" or however it is called frab-internally, let me know. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Realtime settings package
Hey all,
I'd like to discuss the split-out of the realtime settings for
jack{,2}* (see also the discussion on arch-proaudio [1]) to a separate
package.
Currently they all ship
/etc/security/limits.d/99-audio.conf
/usr/lib/udev/rules.d/40-hpet-permissions.rules
Redundancy alone would suggest moving these to a separate package, but I
think there is something more to gain from it: Other packages -
potentially requiring realtime scheduling - can benefit from these
settings (by depending or optdepending on such a "settings package").
Currently I am not aware of another use-case, but that might just be me
working on a subset of what is available out there. Any hints or
suggestions on what other software can possibly benefit from this are
very welcome!
The coupling with the audio group is more of a flaw, than anything imho,
as every member of the group "audio", used for e.g. accessing MIDI
devices, is automatically a realtime user (once jack is installed). I
would want to create a dedicated group, e.g. "realtime", that will hold
those limit permissions.
Also rtprio should be reduced to 95, as it is actually rather dangerous
having daemons run at the same pace as the kernel services themselves
(this is a definite upstream documentation flaw [2]!).
This means having a dedicated realtime group, that other packages can
depend on. The only thing needed to use it, is to add a user to a group.
Maybe there are even some ways to do this all with systemd by now?
I have been running jack2 successfully using a systemd user service [3]
for quite some time now (and eventually I plan on integrating it,
because it enables a lingering user to auto-start jack as a service).
However, this would only be a use-case for jack and jack2, but not for
jack2-dbus, as there the request of other applications requiring the
start of jack will not lead to using /usr/bin/jackd, but
/usr/bin/jackdbus by default.
I have looked at how Debian ships jackd2 [4] and they don't use the udev
rule at all. So I'm a little hesitant on whether to continue shipping
it and whether it is actually required. See also this very old bug
report [5], `man 5 limits.conf`, `man 8 pam_limits` for more info on the
overall topic.
Any input is very welcome!
Best,
David
[1]
https://lists.archlinux.org/pipermail/arch-proaudio/2017-December/20.html
[2] http://jackaudio.org/faq/linux_rt_config.html
[3] https://git.sleepmap.de/software/uenv.git/tree/user/jack@.service
[4] https://packages.debian.org/jessie/amd64/jackd2/filelist
[5] https://bugs.archlinux.org/task/26343
--
https://sleepmap.de
signature.asc
Description: PGP signature
[arch-dev-public] Pro-audio packages from AUR
Hey all, I'd like to move the following packages to community: zita-at1 [1] zita-bls1 [2] zita-dpl1 [3] zita-lrx [4] zita-rev1 [5] zita-njbridge [6] zita-mu1 [7] jacktrip [8] padthv1 [9] The first seven are de-facto standards, developed by Fons Adriansen (some other of his zita-* tools are already in extra and community). They are low maintenance and have a low frequency release cycle. Jacktrip is one of the few working audio-over-network solutions using jack servers on both ends [10]. Padthv1 is (yet) another Qt based audio application by Rui Nuno Capela and part of the vee one suite [11] (the other three parts of the set are already in community - synthv1, drumkv1, samplv1). As they have a low voting count, I'm hereby asking: Are there any objections to them being moved? Best, David [1] https://aur.archlinux.org/packages/zita-at1 [2] https://aur.archlinux.org/packages/zita-bls1 [3] https://aur.archlinux.org/packages/zita-dpl1 [4] https://aur.archlinux.org/packages/zita-lrx [5] https://aur.archlinux.org/packages/zita-rev1 [6] https://aur.archlinux.org/packages/zita-njbridge [7] https://aur.archlinux.org/packages/zita-mu1 [8] https://aur.archlinux.org/packages/jacktrip [9] https://aur.archlinux.org/packages/padthv1 [10] http://jackaudio.org/faq/netjack.html [11] http://www.rncbc.org/drupal/node/1879 -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Introducing python-imdby while dropping imdbpy
Hey all, I am deleting imdbpy (legacy python) and introduce python-imdbpy (python 3.x) instead. Upstream switched to the current python some time last year and dropped support for python 2.x. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
On 2018-01-03 16:05:46 (+0100), Bartłomiej Piotrowski via arch-dev-public wrote: > cacti I'd take cacti and maybe I find something else. Will get back to this tomorrow. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Phasing out cwiid
On 2017-12-04 20:24:20 (+0600), Rashif Ray Rahman via arch-dev-public wrote: > Your findings are also reflected in the wiki [1] and I would say drop > it. But it is required by kodi-eventclients for > kodi-eventclients-wiiremote component, which you will have to remove. > Anyone using Kodi with a Wiimote will lose functionality, but they can > check if Xwiimote works as well for them. I have rebuilt cwiid to fix some issues with the PKGBUILD, but the supercollider package has dropped its dependency for it now (was built without it since 3.8.0 anyways). Now waiting on Ike Devolder to get back to me on the topic of kodi. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Dropping glee and clalsadrv
On 2017-12-03 19:19:52 (+0100), David Runge wrote: > I found at least two, that should be deleted (more to come probably): > > * clalsadrv - superseeded by zita-alsa-pcmi > * glee - upstream dead, unmaintained for more than five years > > The first has no packages depending on it and the second only > electricsheep, which also seems quite half-dead. Removed them all from [community]. Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
I adopted pound proxytunnel I would take over ssmtp if it wasn't in [extra]. -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] 2017 repository cleanup
On 2017-12-18 10:54:37 (+0100), Bartłomiej Piotrowski via arch-dev-public wrote: > - dbus-c++: > schiv: libffado > dvzrv: libffado > fyan: kimtoy > - liboggz: > speps: sonic-visualiser > dvzrv: sonic-visualiser > - mxml: > dvzrv: zynaddsubfx > - twolame: > eric: audacity, sox > dvzrv: audacity > anthraxx: vlc Adopted the above > - fltk: > ronald: octave > schiv: alsa-tools > arojas: libgiac, xcas > arodseth: tuxpaint-config, monica > dvzrv: zynaddsubfx > kkeen: xdiskusage, dillo > lfleischer: lmms > spupykin: tigervnc > - libid3tag: > lfleischer: mixxx > ronald: imlib2 > guillaume: easytag > muflone: gmtp > spupykin: minidlna > lcarlier: mtpfs > fyan: lib32-libid3tag > eric: alsaplayer, audacity, sox > speps: sonic-visualiser > dvzrv: audacity, sonic-visualiser > tpowa: libmp3splt > bisson: mpd > - libiec61883: > schiv: cinelerra-cv, libffado > dvzrv: libffado > heftig: gst-plugins-good > fyan: lib32-libiec61883 > alucryd: ffmpeg Can't adopt the above, as they are in [extra] Will look into more in the coming days. Currently on the road. -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Phasing out cwiid
Hey all, I'd like to phase out cwiid [1] (as it's super old and unmaintained). Currently it's an optdepends for supercollider, but its use will be deprecated in the next version [2], so I will remove it there eventually. The only other packages depending on it are kodi (make) and kodi-eventclients. However, is it really required there? For now, I rebuilt cwiid, but I guess it could be dropped midterm, if it's not a hard requirement for kodi et al. Best, David [1] https://github.com/abstrakraft/cwiid [2] https://github.com/supercollider/supercollider/issues/3320 -- https://sleepmap.de signature.asc Description: PGP signature
[arch-dev-public] Dropping glee and clalsadrv
Hi all, I've been working through the list of packages, formerly maintained by speps (some of which are pro-audio things). I found at least two, that should be deleted (more to come probably): * clalsadrv - superseeded by zita-alsa-pcmi * glee - upstream dead, unmaintained for more than five years The first has no packages depending on it and the second only electricsheep, which also seems quite half-dead. Probably nothing, that should be lingering in [community]. @Eric Bélanger: Are you okay with dropping electricsheep? Best, David -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] Switching the bugtracker to Bugzilla
Sorry for being late to the party. On 2017-11-14 20:30:21 (+0100), Jelle van der Waa wrote: > It seems to be time to move on, and Bugzilla is one of the more active and > maintained bugtrackers out there. Used by several big projects such as > Gnome, LLVM and Mozilla. One of the benefits of moving would be the > possibility of default assignees per 'component'. I guess the decision has already been made towards bugzilla, but if not, MantisBT [1] is another "only bug tracker" web application. It has quite improved over the recent versions concerning usability (nicely scalable on small screens) and is actively maintained. Default assignies can be made "by category" afaik. I can't say, if it fits all or any of the other requirements you're seeking though. btw: I'm suggesting this not because I package mantisbt in AUR, but because I don't like using bugzilla too much ;-) > # Migration I would probably also opt for archiving and starting from scratch, if it indeed takes too long to sieve through and find relevant open bugs. > # User migration This would be great, but will be an ugly script job in any case ;) Additionally: If the relation to the user's bugs can be transferred, don't bother. > # Products Separating core/extra and a separate testing would be great. Although some "products" have found new bug tracking homes, I'd much rather see them unified under bugs.archlinux.org, than scattered. > Input would be welcome, on what we should migrate from flyspray and > what products we should define. Sorry for probably adding more noise. In any case, thanks for the work! Best, David [1] https://www.mantisbt.org/ -- https://sleepmap.de signature.asc Description: PGP signature
