Re: [arch-dev-public] Add active Python versions to the repos
On 21/11/2020 18.48, Filipe Laíns via arch-dev-public wrote: > I understand that. I am not asking to put all releases of Python on the > repos, only the active ones, which people are using. I presume you can back it up with numbers how widely 3.7 and 3.6 are used by Arch users. All I can see is that both have less than 30 votes in AUR. Even if I take into account how irrelevant AUR votes are, I assume the problem is exaggerated. > Why are we packaging software that is used by far less people but we > can't package these Python interpreters which are being actively missed > by people? Our approach of "YOLO push random new packages to repos" is something I never agreed with, for the record. Unfortunately it's a kingdom with almost no rules. BP
[arch-dev-public] Packages up for adoption
Hi, Due to lack of free time, I've orphaned some packages I don't want to think about: bash bash-completion chrome-gnome-shell expat gdbm libcap libffi libunistring libusb networkmanager-fortisslvpn ncurses openfortivpn readline texinfo wpa_supplicant I've also disowned some packages I've been co-maintaining with other packagers but that's not so interesting. Bart
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On 20/04/2020 00.32, Morten Linderud via arch-dev-public wrote: > I have also removed `-mod=vendor` from the default listing in `prepare()` as > Anatol wasn't fond of the idea. I'm still unsure if we really want this as we > would be willynilly downloading sources in `build()` and `check()` during > packaging. Opinions welcome. Ideally we don't, but practically it's irrelevant as long as devtools run builds with network access. Bart
Re: [arch-dev-public] Todos for language specific rebuilds
On 13/01/2020 18.28, Christian Rebischke via arch-dev-public wrote: > [testing] has been used and I wanted to test my packages, but the push > from [testing] to [community] happened before my scheduled date for > this. Have you raised this on the TU or staff channels before the move happened? Otherwise I don't find it surprising no one guessed your personal testing plan. Documented procedures are surely nice, proper communication is even better. BP
Re: [arch-dev-public] Restricting ability to post news items
On 05/01/2020 23.04, Morten Linderud via arch-dev-public wrote: > On Mon, Jan 06, 2020 at 07:53:21AM +1000, Allan McRae via arch-dev-public > wrote: >> Following the roll out of the base metapackage, and its poorly written >> news post, we agreed that all new posts should have a draft posted to >> arch-dev-public. > > Wait, where was this agreed? I heard something about all drafts should be > headed > for arch-dev, but this hasn't been announced nor discussed anywhere. > > Are the TUs missing from the loop here? > If you look at the non-trivial news items, you can easily correlate them with drafts posted to arch-dev-public. The main page isn't a personal website. New posts should – and have been – reviewed, and that's what this mailing list is for. Bart
Re: [arch-dev-public] Information about the base meta-package
On 14/10/2019 23.11, Levente Polyak via arch-dev-public wrote: > Q: Why has this been implemented so suddenly? > A: That's a good question, while we have discussed this topic multiple >times in the past and also issued a concrete proposal to arch-dev- >public (plus its follow-up summary) no further steps were taken to >get something testable. However, during arch-conf in Berlin, the >general enthusiasm and acceleration of the group was so strong, that >we have warp-10 driven this task. We acknowledge that this could have >been handled more carefully, but in the spirit of arch-conf please >excuse us and bear with us. For instance, we could have noticed >during a test phase the consequences of not having systemd- >sysvcompat. For the time being, we have added it to the base package >as the implications were not explicitly desired and discussed >beforehand, however that topic will be covered in a follow-up. This e-mail is probably not needed at all now when the change has already happened. The rationale really should have landed on the main website when the new base package has been released to [testing]. I don't think gathering number of contributors physically can justify total lack of communication with people who did not attend. I understand the good intention and while I agree the change was already extensively discussed, all it needed was just a summary what we're going with in the near future instead of YOLO pushing the metapackage and news post during conference. What I would like to see in this Q is if that's how decision process is going to look like from now on or you see what went wrong and won't forget it in 2 or 3 months. Bart
Re: [arch-dev-public] Semi-away till 2019
Damn calendars, how do they even work!? Yes, I meant 2020. On 03/09/2019 18.41, Alad Wenter via arch-dev-public wrote: > ... 2020? > > Time flies. > > Alad > > On 9/3/19 6:36 PM, Bartłomiej Piotrowski via arch-dev-public wrote: >> Hi all, >> >> As I have free time shortage lately, I think it's fair to officially say >> I will be in semi-away mode till 2019. I will try my best to keep up >> with uncomplicated pkgver bumps for packages I maintain on my own and >> make sure all keys are properly signed, but that's all I can promise. >> >> It also means I'm unable to give toolchain attention it deserves. Please >> poke me somewhere if you happen to be interested in co-maintaining it. >> >> My responses on IRC or via e-mail may be also delayed so take that into >> account before kicking me out. >> >> Bartłomiej
[arch-dev-public] Semi-away till 2019
Hi all, As I have free time shortage lately, I think it's fair to officially say I will be in semi-away mode till 2019. I will try my best to keep up with uncomplicated pkgver bumps for packages I maintain on my own and make sure all keys are properly signed, but that's all I can promise. It also means I'm unable to give toolchain attention it deserves. Please poke me somewhere if you happen to be interested in co-maintaining it. My responses on IRC or via e-mail may be also delayed so take that into account before kicking me out. Bartłomiej
Re: [arch-dev-public] packaging hunspell dictionaries converted for qt5-webengine
I'd go with updating all packages to ship the converted files. Cluttering /usr with untracked files doesn't sound good. BP
Re: [arch-dev-public] New ideas for notifying users about (minor) changes
On 30/07/2019 09.33, Bartłomiej Piotrowski via arch-dev-public wrote: > On 30/07/2019 02.44, Christian Rebischke via arch-dev-public wrote: >> One problem I see with the News section is that it's Dev only. I >> wouldn't even know who I need to ask (and I am TU for several years >> now). > > The list of developers is public. If after few years you don't know a > single person to ask if they could proofread and publish something for > you, or even can't send a draft yourself to arch-dev-public, introducing > another tool won't help at all. > > BP > I have also changed TU permissions to include "add news" and "change news" actions.
Re: [arch-dev-public] New ideas for notifying users about (minor) changes
On 30/07/2019 02.44, Christian Rebischke via arch-dev-public wrote: > One problem I see with the News section is that it's Dev only. I > wouldn't even know who I need to ask (and I am TU for several years > now). The list of developers is public. If after few years you don't know a single person to ask if they could proofread and publish something for you, or even can't send a draft yourself to arch-dev-public, introducing another tool won't help at all. BP
Re: [arch-dev-public] GCC 9 removed from [testing]
On 02/06/2019 09.37, Bartłomiej Piotrowski via arch-dev-public wrote:
> On 26/05/2019 22.39, Eli Schwartz via arch-dev-public wrote:
>> Question: are you going to set up an archbuild alias on soyuz/dragon for
>> this, the way you did for gcc8? (Which reminds me, those archbuild
>> aliases still exist and could be deleted).
>
> I can create it, sure.
>
>> Also please bump the pkgrel for these packages as they were currently
>> just cp'ed from testing. dbscripts knows how to auto-reject uploaded
>> packages built with your repo, as long as the gcc/binutils/etc.
>> pkgver-pkgrel are new and thus do not appear in the archives.
>
> I think packages built againt GCC9 with bumped pkgrel would be rejected
> anyway ("package does not appear in repositories" or something along
> this) but yeah, I don't plan to touch it for the time being.
>
Ah, right, I forgot it also does some archive magic now. I guess I will
have to change it then… Likely today in the evening.
Re: [arch-dev-public] GCC 9 removed from [testing]
On 26/05/2019 22.39, Eli Schwartz via arch-dev-public wrote:
> Question: are you going to set up an archbuild alias on soyuz/dragon for
> this, the way you did for gcc8? (Which reminds me, those archbuild
> aliases still exist and could be deleted).
I can create it, sure.
> Also please bump the pkgrel for these packages as they were currently
> just cp'ed from testing. dbscripts knows how to auto-reject uploaded
> packages built with your repo, as long as the gcc/binutils/etc.
> pkgver-pkgrel are new and thus do not appear in the archives.
I think packages built againt GCC9 with bumped pkgrel would be rejected
anyway ("package does not appear in repositories" or something along
this) but yeah, I don't plan to touch it for the time being.
BP
Re: [arch-dev-public] GCC 9 removed from [testing]
On 26/05/2019 18.51, Bartłomiej Piotrowski via arch-dev-public wrote: > Hi all, > > I just deleted GCC 9 and related packages from [testing] due to the > filesystem corruption bug when bcache is used[1]. You will have to -Syuu > your systems. > > People hungry for breakage can install it from [gcc9] repo I uploaded to > pkgbuild.com: > > [gcc9] > Server = https://pkgbuild.com/~bpiotrowski/gcc9/ > > Bartłomiej > [1] should be pointing to https://bugs.archlinux.org/task/62730
[arch-dev-public] GCC 9 removed from [testing]
Hi all, I just deleted GCC 9 and related packages from [testing] due to the filesystem corruption bug when bcache is used[1]. You will have to -Syuu your systems. People hungry for breakage can install it from [gcc9] repo I uploaded to pkgbuild.com: [gcc9] Server = https://pkgbuild.com/~bpiotrowski/gcc9/ Bartłomiej
Re: [arch-dev-public] Co-maintainers and less time for packaging
Adopted restic and pass-otp.
Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”
On 18/03/2019 09.18, Gaetan Bisson via arch-dev-public wrote: > [2019-03-18 08:39:45 +0100] Bartłomiej Piotrowski via arch-dev-public: >> I asked Bruno to start another round as previous thread is way too long >> for people who missed the party to catch up. > > So some of us have taken the time to discuss this issue just a month ago > but because it's too much to read for you we must start all over again? I am sorry for bringing forth an idea of recapping what we agree or not agree upon after hearing that the thread could be too long for bystanders. > We currently have a base group that you're not happy with. Levente and > Bruno suggest to update its package list and/or maybe make it a meta- > package. From your perspective that would be no better and no worse than > the current situation, right? So I don't see why you are against this > change but if you are please tell us what concretely you propose we do? It will be later leveraged to vouch for implicit or transitive dependencies. If you consider it independent topic then fine, I'm happy to bring it up as "but that's unrelated" counterargument in the future. Bartłomiej
Re: [arch-dev-public] Follow-up on the “Proposal: minimal base system”
On 17/03/2019 23.13, Gaetan Bisson via arch-dev-public wrote: > [2019-03-17 19:07:23 +0100] Bruno Pagani via arch-dev-public: >> This is a follow-up on the last month discussion about a “minimal base >> system”. > > Creating a new thread removed from the discussion we had a month ago > just makes it so much harder for all of us to remember what everyone's > arguments and counter-arguments were. Please do not do this. For my > part, I thought we had reached consensus with Allan's message: I asked Bruno to start another round as previous thread is way too long for people who missed the party to catch up. > > https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029471.html > > Summary: You propose what you want your new group to be (metapackage, > list of dependencies, etc.) and we adopt this as the new base. > > If that is not satisfactory to you, please reply to that specific > message and say why. That would have been far more constructive than > your present message which rehashes some of the discussion we've already > had and adds new questions I have no idea where you're going with. The previous discussion doesn't answer (or even if it does, I don't care to re-read it at this point) if the idea behind the new metapackage is to be implicit dependency of all packages or just optional thing like base group always was. Currently maintainers either put actual dependencies into depends=(), including glibc if something dynamically links to libc.so or assume that base is group expected to be present on every installation, which I wholeheartedly disagree with, because I can just instead use Slackware if I weren't caring about dependency system. Bartłomiej
Re: [arch-dev-public] Proposal: minimal base system
On 18/03/2019 00.35, Gaetan Bisson via arch-dev-public wrote: > [2019-03-18 00:25:09 +0100] Alad Wenter via arch-dev-public: >> Assuming we implement this group or meta-package as something of policy, >> i.e. every repository package is assumed to depend on it. This would then >> make base similar to base-devel, except for depends() instead of >> makedepends(). >> >> With base-devel, we've always encouraged people to remove the makedepends >> already in that group. Would we do the same for "base", i.e. remove >> dependencies that, beforehand, were explicit? > > We've been doing this for as long as I can remember. > > Only 156 packages have glibc in their depends array. > > Cheers. > We is very generic term. I'm not doing it. If your package links to libc.so, put it into deps. Bartłomiej
[arch-dev-public] Away until Feb 11
Hi all, I'm trying to run away from winter so I'll be away starting Wednesday. I will be partially available via IRC/e-mail but I don't plan to do any packaging. Bartłomiej
Re: [arch-dev-public] Proposal: minimal base system
On 22/01/2019 00.23, Allan McRae via arch-dev-public wrote: > On 22/1/19 8:03 am, Levente Polyak via arch-dev-public wrote: >> Everything that won’t be part of base-system needs to be added as a >> dependency to all requiring packages; alternatively don't omit any first >> level runtime dependencies at all. >> >> This package should only depend on strictly required explicit packages >> to get a working minimal Arch Linux system. >> >> The proposed end result is: >> - base: convenient helper group for quickly getting a working system >> when installing, must include the new base-system package >> - base-system: package defining the minimum dependencies for a working >> base runtime > > I think the proposal is OK. I'm not comfortable with our line about > base group packages being required given how many of them I don't have > installed. > > However... I don't like idea of the base group and base-system package > existing together. You definition of what base-system should be is much > the same as what the base group was defined to be. What package > justifies itself in the base group, but would not be in base-system? It > seems we would have two very similar things where one would do. > > Allan > Maybe it's my reading comprehension failing me but I also don't really understand the point of base-system, or rather why the base group can't be simply stripped down to Levente's list. Bartłomiej
Re: [arch-dev-public] Looking for maintainer for mkinitcpio/a-i-s
On 16/12/2018 21.52, Dave Reisner wrote: > Hi, > > I'm finding myself lacking these days in both time and motivation to > continue maintenance of both mkinitcpio and arch-install-scripts. Is > anyone interested in taking these over? Both projects are fairly stable, > but bugs do crop up as the rest of the OS evolves. > > dR > I can help with a-i-s; also with mkinitcpio for the time being, but I'd prefer more hands with this one. Bartłomiej
[arch-dev-public] Access to CNCF community cluster
Few months ago I asked on arch-dev whether we would like to ask for access to Cloud Native Computing Foundation cluster, which we could use to experiment with automated package builds (or anything else really). Following no response I actually did so anyway[1] and I have been invited to CNCF organization on packet.net, where we can spawn new dedicated machines for fun and profit. Obvious caveat is that we are guests and shouldn't abuse it; less obvious one is that packet.net does not support Arch out-of-the-box but it can be achieved via PXE and cloud-init (currently residing in AUR?). I just realized I never communicated this properly so here it is. Let me know if there's anything you would like to try. Bartłomiej [1] https://github.com/cncf/cluster/issues/85
Re: [arch-dev-public] TU application process
On 06/11/2018 12.13, Bruno Pagani via arch-dev-public wrote: > Yeah, but [community] used to be something completely separated from > [extra]. This is less and less the case (numerous packages were moved > from [extra] to [community] so that TUs could maintain them for > instance). The line between devs and TUs has become quite blurried, and > in my opinion who we accept as TU is highly depending on the meaning we > have for those repos and roles. I think devs should thus be concerned by > the quality of what we have in [community]. Or we should start caring about repo hierarchy again, and keep [core] and [extra] independent. > Here again I would argue that they are devs that have [core] pushing > rights, as well as devs that are Master Key holders. So even if you > don’t want to write this black on white, this actually means a small > group of people have the real control over the distro (technically, > Master Key holders could revoke everyone else). You can argue, but it's simply not true. Any developer has access to [core]. Master key holders aren't considered any better than other developers besides having more duties and no one has ever refused to sign new TU; for every master key holder, there is someone else holding revocation certificate. There is no hierarchy. > Because you think Arch work, we (as some TUs/devs) think they are a > number of issues. Any sort of council would be a big turn-off for me not just now, but also years ago when I joined TU ranks first. > Thanks for your input, and this is the kind of opinions for which I said > we should have this discussion here. Personally I'm not interested in this either and I find it difficult to find anything substantial in Christian's message indicating that discussion should take place on arch-dev-public and not aur-general. I know anthraxx is preparing actual outline but it's really bad way to start off. Bartłomiej
Re: [arch-dev-public] Meeting on dbscripts git repository layout and debug packages
On 15/09/2018 23.06, Bartłomiej Piotrowski via arch-dev-public wrote: > On 14/09/2018 18.46, Bartłomiej Piotrowski via arch-dev-public wrote: >> Hi all, >> >> We would like to discuss design, issues and what is left to do about the >> future dbscripts git migration and enabling debug packages by default. >> >> Please fill which time suits you best on Monday (17.09) or Tuesday >> (18.09) here[1]. >> >> The meeting will take place on #archlinux-devops on Freenode. It's a >> public channel so anyone who's interested can join. >> >> I will send an update with final date till Sunday. >> >> Bartłomiej >> >> [1] https://doodle.com/poll/6hsbn8z3et8gazmi >> > > The meeting will take place on Monday, 7PM CEST. I will publish > minutes/log after it's over. > > Bartłomiej > It happened and according to some, it wasn't as terrible as I think! Notes from the meeting can be found here[1]. I will migrate it to DeveloperWiki later this week. Bartłomiej [1] https://etherpad.gnome.org/p/ArchDebugGitMeeting
Re: [arch-dev-public] Meeting on dbscripts git repository layout and debug packages
On 14/09/2018 18.46, Bartłomiej Piotrowski via arch-dev-public wrote: > Hi all, > > We would like to discuss design, issues and what is left to do about the > future dbscripts git migration and enabling debug packages by default. > > Please fill which time suits you best on Monday (17.09) or Tuesday > (18.09) here[1]. > > The meeting will take place on #archlinux-devops on Freenode. It's a > public channel so anyone who's interested can join. > > I will send an update with final date till Sunday. > > Bartłomiej > > [1] https://doodle.com/poll/6hsbn8z3et8gazmi > The meeting will take place on Monday, 7PM CEST. I will publish minutes/log after it's over. Bartłomiej
[arch-dev-public] Meeting on dbscripts git repository layout and debug packages
Hi all, We would like to discuss design, issues and what is left to do about the future dbscripts git migration and enabling debug packages by default. Please fill which time suits you best on Monday (17.09) or Tuesday (18.09) here[1]. The meeting will take place on #archlinux-devops on Freenode. It's a public channel so anyone who's interested can join. I will send an update with final date till Sunday. Bartłomiej [1] https://doodle.com/poll/6hsbn8z3et8gazmi
Re: [arch-dev-public] /r/linux AMA
On 09/08/2018 18.41, Morten Linderud via arch-dev-public wrote: > Yo! > > The subreddit /r/linux have started organizing AMA threads for relevant > projects. Gentoo had one of these a few months ago and is an interesting read. > > https://www.reddit.com/r/linux/comments/8nsdj0/we_are_gentoo_developers_ama/ > https://www.reddit.com/r/linux/comments/93qlow/established_project_developer_team_member_flairs/ > > I think it's a good idea Arch Linux does an AMA as it's might give users some > incentive to help contributing to the project. I have chatted with a subreddit > mod at /r/linux, and the AMA should preferably start on any Monday from 27th > and > onwards. It will also run for a few days, so there is no need to be present > all > the time, or when it starts. > > > If you are interested participating please reply to the list with the > following > information: > > * Reddit username. > * What you do. > * What Monday fits for you? > > I have also started handing out flairs on the /r/archlinux subreddit. It's not > an official forum, but if developers and team members want flairs for their > reddit accounts you can also reply to this mail or poke me on IRC :) > I'd like to participate too, if time allows. /u/barthalion, I'm a developer maintaining the toolchain, master key holder and DevOps team member. I'll be completely away for the first week of September, I should be fine after that. Bartłomiej
[arch-dev-public] Enforcing 2FA in GitHub organization
Hi all, I want to enable mandatory two-factor authentication in our GitHub organization. Few of you unfortunately don't use it and will be effectively removed when I flip the switch, which I plan to do next week, 6th July. allanbrokeit anthraxx Atsutane Bluewind brain0 City-busz djgera eli-schwartz foutrelis lordheavy phrakture SantiagoTorres seblu shibumi vesath wonder Bartłomiej
Re: [arch-dev-public] glibc 2.27 based toolchain in [staging]
New draft that includes pam_unix2 deprecation. Title: glibc 2.27-2 and pam 1.3.0-2 may require manual intervention The new version of glibc removes support for NIS and NIS+. The default `/etc/nsswitch.conf` file provided by `filesystem` package already reflects this change. Please make sure to merge pacnew file if it exists prior to upgrade. NIS functionality can still be enabled by installing `libnss_nis` package. There is no replacement for NIS+ in the official repositories. `pam 1.3.0-2` no longer ships pam_unix2 module and `pam_unix_*.so` compatibility symlinks. Before upgrading, review PAM configuration files in the `/etc/pam.d` directory and replace removed modules with `pam_unix.so`. Users of pam_unix2 should also reset their passwords after such change. Defaults provided by `pambase` package do not need any modifications.
Re: [arch-dev-public] Deprecation of pam_unix2
On 2018-04-16 13:02, Bartłomiej Piotrowski via arch-dev-public wrote:
Hi team,
During libnsl rebuild heftig pointed out that we are shipping pam_unix2
that has been dead upstream for a long time (to the point that it's
being built from our own mirror now). I'm also unwilling to spend time
to fix its configure.ac to make it build with libnsl and libtirpc
correctly.
Unless someone's life depends on it, I'd like to drop it from repositories.
Bartłomiej
(Note it's not packaged separately and ships as part of core/pam.)
While on it, I'm dropping pam_unix_{acct,auth_passwd,session}.so
symlinks from pam package that are also relics of the distant past.
Bartłomiej
[arch-dev-public] Removing gksu
What a day! gksu has been deprecated for years. Applications that require elevated privileges should use PolicyKit instead - and it seems that everything in our repositories do. I plan to remove gksu (and libgksu) from repositories this week. Bartłomiej
[arch-dev-public] Deprecation of pam_unix2
Hi team, During libnsl rebuild heftig pointed out that we are shipping pam_unix2 that has been dead upstream for a long time (to the point that it's being built from our own mirror now). I'm also unwilling to spend time to fix its configure.ac to make it build with libnsl and libtirpc correctly. Unless someone's life depends on it, I'd like to drop it from repositories. Bartłomiej
Re: [arch-dev-public] Boost looking for new maintainer
On 2018-03-20 18:45, Levente Polyak via arch-dev-public wrote: On March 20, 2018 4:55:16 PM GMT+01:00, Robin Broda via arch-dev-public <arch-dev-public@archlinux.org> wrote: On 03/20/2018 02:36 PM, Bartłomiej Piotrowski via arch-dev-public wrote: Hi team, As I'm absolutely the worst with C++, none of my packages depend on boost and I've spent enough nights terrified of its build system quirks, I'll be orphaning it soon. Feel free to adopt it in archweb. Bartłomiej If you're willing to drop it to [community] i'll gladly adopt it. Rob Well I pretty much love cpp and boost and have multiple packages depending on it, if nobody here feels butt hurt or robbed I would happily adopt it. I don't fear sleepless nights and I explicitly welcome everyone to propose sane changes now or in future, working together is key to success :D Cheers Levente New version has been released yesterday so enjoy! Bartłomiej
[arch-dev-public] glibc 2.27 based toolchain in [staging]
Hi,
I've had too much faith in GCC 8 release schedule. To sweeten the wait
(and catch some possible issues sooner), I'm going to push glibc 2.27
and binutils 2.30 to [staging] in the evening.
The new glibc doesn't ship libnss_nis{,plus} and RPC interface anymore.
Packages that require the last should switch to libtirpc; libnsl shared
library is still provided for backwards compatibility with old ABI, but
dependent packages should be rebuild against standalone libnsl package
(rebuild in archweb will follow soon).
As some users may have used NIS in their nsswitch.conf file, news post
wouldn't hurt. Here's a draft:
Title: glibc 2.27-2 removes support for NIS and NIS+
The new version of glibc removes support for NIS and NIS+. The default
`/etc/nsswitch.conf` file provided by `filesystem` package already
reflects this change. Please make sure to merge pacnew file if it exists
prior to upgrade.
NIS functionality can still be enabled by installing `libnss_nis`
package. There is no replacement for NIS+ in the official repositories.
Re: [arch-dev-public] New build server in Singapore
On 2017-10-22 13:13, Bartłomiej Piotrowski wrote: > Hi all, > > for those of you that are living closer to Asia than Europe, there is > new build server available, located in Singapore. It is considerably > less beefy than soyuz, but should be okay for regular builds. > > All packagers should be able to ssh into it with username and the key > used on other servers. The address is sgp.pkgbuild.com. You can compare > fingerprints below: > > SHA256:f9VrDpIpOHvgWk+OXXRG+VMvJlbs577YFZfyxPtXKqU (ED25519) > SHA256:fDdeGInsD764tfnGCbNIPH69L4k7mNs98ttFpTOv01U (RSA) > SHA256:MsoXUmTXowWcPb4gma3U60Po0/5sTT5Fg+oM8bWIIUE (ECDSA) > > It also hosts a mirror available at https://sgp.mirror.pkgbuild.com > > Enjoy, > Bartłomiej > For the record, the build server lives on at sgp.mirror.pkgbuild.com. The old one that went done few months ago failed to boot after replacing its system with Arch so I'm bailing out. Bartłomiej
[arch-dev-public] Boost looking for new maintainer
Hi team, As I'm absolutely the worst with C++, none of my packages depend on boost and I've spent enough nights terrified of its build system quirks, I'll be orphaning it soon. Feel free to adopt it in archweb. Bartłomiej
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
On 2018-03-13 15:32, Eli Schwartz via arch-dev-public wrote: > This wrapper changes depending on which version of meson you have installed. The wrapper is part of the package that changes. > The fact that autoconf has weird bugs like needing to set localstatedir > and sysconfdir to their defaults minus the /usr prefix, is an autoconf > bug. Maybe we could work on having meson not require setting bizarre > options just to get sane defaults? Neither is a bug. It's just a convenience script. Do you propose to work on upstreaming defaults that make sense for Arch, but not necessarily for what other distributions do or aim for? > (Setting the prefix automatically propagates to everything specified > with relative paths, which is most things, and libexecdir and sbindir > could just specify a *different* relative path.) (Which is completely unrelated to our use case, even if you put this between parentheses.) > So other languages, which completely disregard our CFLAGS but which > meson itself has magic wrappers for... and the solution is to add a > magic script to use in the PKGBUILD which does not respect makepkg.conf > but can add debug symbols only loosely related to what we were trying to > get? A script which arbitrarily adds debug symbols to packages that were > rebuilt with OPTIONS=(!debug) by users who wanted to make local > modifications? Other languages ignore CFLAGS (hint: these are CFLAGS after all) anyway. Users wanting to make local modifications were always on their own. > since apparently meson is so perfect we should do literally everything > directly in meson. A cheap hyperbole. Obviously unnecessary if you want to be taken seriously. > Or we could at least make a *proper* wrapper which can talk to makepkg > and determine if debug info is wanted. Patches welcome. Would be more productive use of your time than making a storm in the glass of water here. Bartłomiej
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
On 2018-03-13 14:40, Allan McRae via arch-dev-public wrote: > On 13/03/18 21:22, Jan Alexander Steffens via arch-dev-public wrote: >> For that matter, I'm all for putting an arch-configure helper into our >> autoconf package. > > Don't muck around with vanilla packages. Put it in another package > (devtools). > > A > Makes no sense unless devtools become part of base-devel. It's hardly any meddling as it doesn't hinder possibility to use default configure script or meson binary. Bartłomiej
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On 2018-03-12 05:33, Pierre Schmitz wrote: > Thanks for digging this up again. You may use the github issue or > project system to plan the different steps. Also (and please don't get > it the wrong way) let's keep the purpose I intended for our Docker > image intact. No one has suggested changing "the purpose". I'm not sure what is unclear in Santiago's mail. Bartłomiej
Re: [arch-dev-public] RFC: Dropping -DCMAKE_BUILD_TYPE from packages using cmake
On 2018-03-10 11:34, Antonio Rojas via arch-dev-public wrote: > 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? > 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? Bartłomiej
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On 2018-01-29 20:29, Pierre Schmitz wrote: > * I did not look into the details of how we exactly need to proceed > with making an "official" image. A few pull requests or some kind of > setp-by-step plan (wiki or github) would help. Necrobumping. You actually quoted the message from Santiago that describes the process. I'm going to grant him and Christian write permissions so they can start working on this on separate branch. Bartłomiej
Re: [arch-dev-public] Test repository with gcc8
On 2018-02-13 16:13, Eli Schwartz via arch-dev-public wrote: > On 02/13/2018 09:29 AM, Bartłomiej Piotrowski via arch-dev-public wrote: >>>> I have updated gcc in the repository to snapshot from 2018-02-11 >>>> (r257571). Additionally, if you have access to soyuz, the repo can be >>>> easily used in build chroots with 'gcc8-x86_64-build' command (which >>>> also enables [testing]). >>> >>> Nice, thanks! >>> >>> Could you enable the password-less rules for sudo that are already setup >>> for extra-x86_64-build? Currently gcc8-x86_64-build asks for a sudo >>> password, but most of us are not sudoers on soyuz (and don't need to be). >>> >>> Baptiste >>> >> >> Try now. My change may be overwritten as I didn't add it to our Ansible >> playbooks but I cross my fingers to see 8.1.0 soon. > > Would it be worth adding a sudoers configuration that allows any > /usr/bin/*-x86_64-build command? On the theory that that is a rather > specific script suffix, and is exceedingly unlikely to be created in > /usr/bin/ for any reason other than as a symlink to archbuild with a > corresponding /usr/share/devtools/pacman-*.conf (which is presumably > something that should always be allowed). > I'm not sure if it's worth it as the repo is only semi-official, and besides I've had time only for a band-aid today. Also you know where the infrastructure repo resides and I'll be more than happy to run 'git am' your patch if you share it on #archlinux-devops. Bartłomiej
Re: [arch-dev-public] Test repository with gcc8
On 2018-02-13 15:19, Baptiste Jonglez wrote: > On 13-02-18, Bartłomiej Piotrowski via arch-dev-public wrote: >> On 2018-02-04 14:02, Bartłomiej Piotrowski via arch-dev-public wrote: >>> Hi all, >>> >>> I've prepared external repository with GCC 8 built from trunk (as there >>> is no stable release yet) that also contains glibc 2.27 and binutils 2.30. >>> >>> [gcc8] >>> Server = http://pkgbuild.com/~bpiotrowski/gcc8/ >>> >>> From less obvious packaging changes, glibc no longer ships with obsolete >>> rpc and nsl, which means that you should switch your packages to >>> libtirpc; also if your nsswitch.conf still contains "compat" instead of >>> "files", better fix it before reboot. If for some reason you still use >>> nsl, the repository also ships libnsl and libnsl_nis packages. >>> >>> As usually, simple things build, and colossi like LibreOffice don't, but >>> I haven't had time yet to check why. If you found some issue, the best >>> would be to reply either here or arch-general. >>> >>> Enjoy, >>> Bartłomiej >>> >> I have updated gcc in the repository to snapshot from 2018-02-11 >> (r257571). Additionally, if you have access to soyuz, the repo can be >> easily used in build chroots with 'gcc8-x86_64-build' command (which >> also enables [testing]). > > Nice, thanks! > > Could you enable the password-less rules for sudo that are already setup > for extra-x86_64-build? Currently gcc8-x86_64-build asks for a sudo > password, but most of us are not sudoers on soyuz (and don't need to be). > > Baptiste > Try now. My change may be overwritten as I didn't add it to our Ansible playbooks but I cross my fingers to see 8.1.0 soon. Bartłomiej
Re: [arch-dev-public] Test repository with gcc8
On 2018-02-04 14:02, Bartłomiej Piotrowski via arch-dev-public wrote: > Hi all, > > I've prepared external repository with GCC 8 built from trunk (as there > is no stable release yet) that also contains glibc 2.27 and binutils 2.30. > > [gcc8] > Server = http://pkgbuild.com/~bpiotrowski/gcc8/ > > From less obvious packaging changes, glibc no longer ships with obsolete > rpc and nsl, which means that you should switch your packages to > libtirpc; also if your nsswitch.conf still contains "compat" instead of > "files", better fix it before reboot. If for some reason you still use > nsl, the repository also ships libnsl and libnsl_nis packages. > > As usually, simple things build, and colossi like LibreOffice don't, but > I haven't had time yet to check why. If you found some issue, the best > would be to reply either here or arch-general. > > Enjoy, > Bartłomiej > I have updated gcc in the repository to snapshot from 2018-02-11 (r257571). Additionally, if you have access to soyuz, the repo can be easily used in build chroots with 'gcc8-x86_64-build' command (which also enables [testing]). Bartłomiej
[arch-dev-public] Test repository with gcc8
Hi all, I've prepared external repository with GCC 8 built from trunk (as there is no stable release yet) that also contains glibc 2.27 and binutils 2.30. [gcc8] Server = http://pkgbuild.com/~bpiotrowski/gcc8/ From less obvious packaging changes, glibc no longer ships with obsolete rpc and nsl, which means that you should switch your packages to libtirpc; also if your nsswitch.conf still contains "compat" instead of "files", better fix it before reboot. If for some reason you still use nsl, the repository also ships libnsl and libnsl_nis packages. As usually, simple things build, and colossi like LibreOffice don't, but I haven't had time yet to check why. If you found some issue, the best would be to reply either here or arch-general. Enjoy, Bartłomiej signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?
Whoa, this is so good to bash that I can't decide where to begin. Microsoft started noticing Linux (or rather stopped to fight it so valiantly) when they realized where the money is. On this ground alone I don't see a reason to help some corporation in putting our logo on their website so they can brag how they love Linux now, especially when there are no real gains for us in all of this. If you want more technical angle, at least few months ago installing Arch on WSL required patched glibc. I won't maintain such patches because of something I completely don't care about. Even if it was solved since, good luck with debugging all possible heisenbugs that can be encountered due to sloppy implementation of Linux syscalls on Windows. If the proposal gets through, I'm not going to spend time on any of such reports at all, making heavy use of EWONTFIX. I don't use Windows and I don't care about WSL. Having Docker image makes sense as it can bring some value for people using different distributions for development or testing purposes alone. That can't be said about WSL. Bartłomiej
Re: [arch-dev-public] Arch Linux Docker / Vagrant: Current situation
On 2018-01-20 20:19, Christian Rebischke via arch-dev-public wrote: > The Arch Linux Vagrant images are currently be build for libvirt and > virtualbox. We have over 3800 downloads at the moment and slowly > catching up to the community based arch linux vagrant images.[1] It would be probably seen as more "official" if it was mentioned on our website. > My first goal has been to add some hypervisors, but due to > the fact that we have only libvirt and virtualbox in our repositories I > have dismissed this plan. The automated build process works fine so far > (except some issues with qemu[2] and the dependency on punctual iso > releases on soyuz. The latter should we definitly fix. Currently the iso > images are build manually. Can we automate this somehow? I really rely > on punctual releases otherwise the automated build will fail and > somebody needs to trigger the build again manually. Happened about 1-2 > times..) This is something that would require a virtually offline box to be fully automated. For the time being, it sounds better to upgrade your vagrant image after first week of the month. Also, any plans to expand the scope to support OpenStack, AWS and GCE? At the moment the scope sounds rather limited. > Sangy/Santiago[3] was so nice to speak with the docker guys. They said > they would approve our docker image and we could move it to the other > official images[4]. But for this we need to do some changes on our > docker repository on github. (As long I understood sangy correct it > would be just some new branches). Can you actually give more details how it's going to look like? Bartłomiej
Re: [arch-dev-public] 2017 repository cleanup
Hi team, I've finished moving unneeded orphans to AUR. The only exceptions that were simply removed are nvidia-304xx family (EOL'ed upstream) and nautilus-open-terminal (seems to be built into nautilus these days). You can find the list of (re)moved packages here[1]. Let's try not to make such a mess this time! Bartłomiej [1] https://paste.xinu.at/VjGQ/
Re: [arch-dev-public] Package group between repositories
On 2018-01-04 13:02, Balló György via arch-dev-public wrote: > Currently the 'xfce4-goodies' package group[1] is in split between [extra] > and [community]. Most of its packages are in [extra], but 'ristretto' and > 'xfce4-whiskermenu-plugin' are in [community]. > > My question is: is it okay, or should we avoid it by removing these two > packages from the 'xfce4-goodies' group or moving them to [extra]? > > [1] https://www.archlinux.org/groups/x86_64/xfce4-goodies/ > > -- > György Balló > Trusted User > Groups are just for convenience and members don't have to be in the same repository. The latter also applies to regular dependencies these days as it's more practical to have a dependency maintained by a TU than left rotten in [extra]. At least that's my view on it. BP
Re: [arch-dev-public] 2017 repository cleanup
On 2018-01-04 12:17, Balló György via arch-dev-public wrote: > The following packages should be kept too: > - dvdauthor > arojas: kdenlive > fyan: kdenlive > heftig: brasero > jgc: brasero The only two packages that really require it are unneeded orphans, so I don't see the point. > - sofia-sip > heftig: empathy Ditto. There is nothing special about unmaintained optdepends that are providing completely optional functionality. Bartłomiej
Re: [arch-dev-public] 2017 repository cleanup
On 2018-01-04 10:35, Rashif Ray Rahman via arch-dev-public wrote: > 2018-01-03 21:05 GMT+06:00 Bartłomiej Piotrowski via arch-dev-public > <arch-dev-public@archlinux.org>: >> >> Hi team, >> >> This is the final update before I start moving packages to AUR over this >> week. >> >> List of orphans required by maintained packages: >> >> ... > > Just to confirm, are these going to be dropped despite being required > by maintained packages? No, it's a list of orphans that could be adopted by maintainers of packages that require them. Removal would mean broken dependencies, so they're going to stay maintained or not. BP
Re: [arch-dev-public] 2017 repository cleanup
On 2018-01-04 00:20, Balló György via arch-dev-public wrote: > Please move the following packages from [extra] to [community], so I can > adopt them: > - gnome-icon-theme-extras > - libgovirt > - python2-telepathy > > -- > György Balló > Trusted User > Moved, enjoy. BP
Re: [arch-dev-public] 2017 repository cleanup
On 2018-01-03 23:31, Balló György via arch-dev-public wrote: > Please don't remove anything yet. I'll adopt some packages in the next 24 > hours. > > You missed some optional and indirect dependencies. We should keep the > following packages: I explicitly said that I'm not taking optdepends into account. There are some false positives on the list but I haven't said I'm going to drop everything blindly either. Bartłomiej
Re: [arch-dev-public] 2017 repository cleanup
Hi team, This is the final update before I start moving packages to AUR over this week. List of orphans required by maintained packages: - autoconf-archive: jgc: dbus, gspell, gnumeric tomegun: dbus, dbus-docs, libimobiledevice heftig: gst-plugins-base-libs, gstreamer, libgweather zorun: ring-daemon fyan: lib32-gst-plugins-good, lib32-gstreamer, deepin-metacity alucryd: hexchat, lib32-polkit faidoc: cinnamon-settings-daemon eschwartz: cinnamon-settings-daemon bgyorgy: budgie-desktop andyrtr: fontconfig lcarlier: lib32-dbus eworm: packagekit - bctoolbox: arojas: mediastreamer - bcunit: arojas: mediastreamer - blackbox: jlichtblau: bbpager - bmake: spupykin: lua51-alt-getopt, lua-alt-getopt, lua52-alt-getopt - bzrtp: arojas: mediastreamer - caja: bgyorgy: filemanager-actions eschwartz: xreader - cd-discid: schuay: abcde - cddb_get: jlichtblau: hacburn - cinepaint: eworm: gimp-ufraw - classpath: svenstaro: uwsgi-plugin-zabbix, uwsgi-plugin-jvm, uwsgi-plugin-pypy fyan: uwsgi-plugin-zabbix, uwsgi-plugin-jvm, uwsgi-plugin-pypy arodseth: clojure - convertlit: arojas: ebook-tools - db: pierre: php-imap, php-sqlite, php-odbc tpowa: smbclient, libwbclient, samba jgc: apr-util, evolution-data-server anatolik: apr-util bluewind: perl spupykin: opendkim, opensips, postgrey alucryd: lib32-db andyrtr: bogofilter schiv: jack lfleischer: libical bisson: postfix - dvgrab: bluewind: openshot - ecryptfs-utils: jsteel: clonezilla - enca: anthraxx: mplayer, mencoder jlichtblau: ogmrip - faenza-icon-theme: alucryd: faience-icon-theme - farstream: foutrelis: libpurple, pidgin, finch heftig: telepathy-farstream - frei0r-plugins: heftig: gnome-video-effects arojas: mlt, mlt-python-bindings - gamin: schiv: snd tpowa: smbclient, libwbclient, samba - giblib: anthraxx: scrot - gnustep-base: svenstaro: oolite heftig: meson anthraxx: meson - gnustep-gui: svenstaro: oolite - gnustep-make: svenstaro: oolite - goocanvas: bgyorgy: ocrfeeder jgc: libgda heftig: libgda jlichtblau: goocanvasmm - gpsbabel: jlichtblau: gebabbel - graphene: heftig: gst-plugins-bad - gwenhywfar: jlichtblau: aqbanking - hevea: spupykin: ejabberd zorun: coq, coqide, coq-doc arojas: libgiac, xcas - hunspell-hu: heftig: ibus-typing-booster - hunspell-it: heftig: ibus-typing-booster - hunspell-ro: heftig: ibus-typing-booster - hwloc: anthraxx: openmpi - idnkit: seblu: bind-tools, bind tpowa: archboot - ifplugd: tpowa: archboot - imlib: jlichtblau: kuickshow - intel-tbb: svenstaro: openimageio, opensubdiv, openshadinglanguage ronald: suitesparse kkeen: cryptominisat5 stativ: embree schiv: opencv - ispell: andyrtr: hunspell-de - jbigkit: jelle: netpbm eric: libtiff - js185: Archange: couchdb - lasem: jgc: goffice - lcms: fyan: lib32-lcms eworm: gimp-ufraw, gimp eric: geeqie tpowa: xsane-gimp, xsane arodseth: netsurf anthraxx: gimp lcarlier: devil - lib32-libcdio: schuay: pcsxr - libantlr3c: fyan: cvc4 - libcdaudio: eric: epplet-base - libdbi: jsteel: monitoring-plugins bisson: collectd eric: syslog-ng seblu: ulogd - libdiscid: lcarlier: kaudiocreator xyne: cmus bisson: python2-discid, python-discid bgyorgy: goobox jgc: sound-juicer heftig: sound-juicer - libdvbpsi: anthraxx: vlc - libfm-qt: jleclanche: lxqt-qtplugin, pcmanfm-qt, lximage-qt - libgadu: foutrelis: libpurple, pidgin, finch arojas: kopete - libgme: anthraxx: vlc bisson: mpd jlichtblau: qmmp heftig: gst-plugins-bad - libgoom2: anthraxx: vlc - libgovirt: bgyorgy: gnome-boxes - libkeybinder2: bgyorgy: lxpanel - liblouis: andyrtr: cups-filters jgc: orca - liblqr: ronald: digikam, kipi-plugins arojas: digikam, kipi-plugins heftig: libmagick6 eric: libmagick stativ: gimp-plugin-lqr - libnice: arojas: telepathy-gabble - libnids: zorun: dsniff - libnl1: seblu: keepalived, ipvsadm - libofa: ronald: amarok arojas: amarok heftig: gst-plugins-bad - libopenshot: bluewind: openshot - libraqm: heftig: libmagick6 eric: libmagick - libsidplayfp: jlichtblau: qmmp foutrelis: audacious-plugins - libtiger: anthraxx: vlc heftig: gst-plugins-bad - libtommath: andyrtr: libreoffice-still, libreoffice-fresh, libreoffice-fresh-sdk - libupnp: zorun: ring-daemon arojas: amule, mediastreamer anthraxx: vlc bisson: mpd - live-media: anthraxx: mplayer, vlc, mencoder - lua51: fyan: ibus-pinyin, uwsgi-plugin-zabbix, uwsgi-plugin-jvm spupykin: lua-sec, lua51-sec, lua51-expat svenstaro: uwsgi-plugin-zabbix, tolua++, uwsgi-plugin-jvm eric: rrdtool eworm: lua52-lpeg, lua51-lpeg,
[arch-dev-public] gdbm 1.14 removed from [testing]
Hi all, gdbm 1.14 introduced silent ABI breakage[1] so for now, I removed it from [testing]. I contacted upstream about the issue and if the time allows, I will prepare a fix today. Bartłomiej signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] 2017 repository cleanup
On 2017-12-18 23:51, Baptiste Jonglez wrote: > On 18-12-17, Bartłomiej Piotrowski via arch-dev-public wrote: >> On 2017-12-18 10:54, Bartłomiej Piotrowski via arch-dev-public wrote: >>> Please look at both lists and adopt what your packages are using or >>> you're personally interested in. I will drop whatever makes sense in >>> January. >> >> And of course, if you are missing some permissions or need something >> moved to [community], let me know. > > Useful script, thanks! > > Can you move fig2dev to [commmunity] so that I can adopt it? > > I have also adopted a few unneeded orphans. > > Baptiste > Moved, enjoy. BP
Re: [arch-dev-public] 2017 repository cleanup
On 2017-12-18 10:54, Bartłomiej Piotrowski via arch-dev-public wrote: > Please look at both lists and adopt what your packages are using or > you're personally interested in. I will drop whatever makes sense in > January. And of course, if you are missing some permissions or need something moved to [community], let me know. BP
[arch-dev-public] 2017 repository cleanup
Hi team, Recently I've spent a bit of time on the train so I spent that on writing a script (of questionable quality) for generating packages cleanup list. The main difference from the "unneeded orphans" report is that it also includes orphans that require only other orphans and additionally generates possible maintainers for required but unmaintained packages. The script can be found here[1] and I will probably improve it a bit on the next journey. Note that it doesn't consider optdepends when checking if orphan is needed only by other orphans. Max. 3 packages requiring given orphan are listed next to possible maintainer. It also ignores repo hierarchy because it's just a theater these days. Please look at both lists and adopt what your packages are using or you're personally interested in. I will drop whatever makes sense in January. Bartłomiej [1] https://paste.xinu.at/Hsbt/ Orphans required by maintained packages: - augeas: shibumi: ruby-augeas mtorromeo: python2-augeas fyan: python-augeas - autoconf-archive: faidoc: cinnamon-settings-daemon jgc: gnote, appstream-glib, dbus-docs heftig: gst-plugins-bad, gtksourceview3, bijiben fyan: lib32-gst-plugins-good, lib32-gst-plugins-base, lib32-gstreamer tomegun: dbus-docs, libimobiledevice, dbus alucryd: lib32-polkit, hexchat andyrtr: fontconfig lcarlier: lib32-dbus eworm: packagekit bgyorgy: budgie-desktop - babl: jgc: gnome-photos heftig: gnome-photos anthraxx: gimp eworm: gimp - bctoolbox: arojas: mediastreamer - bcunit: arojas: mediastreamer - blackbox: jlichtblau: bbpager - bmake: spupykin: lua-alt-getopt, lua51-alt-getopt, lua52-alt-getopt - bzrtp: arojas: mediastreamer - caja: bgyorgy: filemanager-actions - cd-discid: schuay: abcde - cddb_get: jlichtblau: hacburn - cimg: svenstaro: wxcam - cinepaint: eworm: gimp-ufraw - cinnamon-menus: faidoc: cinnamon-control-center, cinnamon - clamz: ronald: amarok arojas: amarok - classpath: svenstaro: uwsgi-plugin-rack, uwsgi, uwsgi-plugin-jvm fyan: uwsgi-plugin-rack, uwsgi, uwsgi-plugin-jvm arodseth: clojure - convertlit: arojas: ebook-tools - cvc4: fyan: maude - dante: fyan: shadowsocks - db: pierre: php-gd, php, php-imap schiv: jack jgc: evolution-data-server, apr-util bluewind: perl spupykin: opendkim, perl-berkeleydb, postgrey tpowa: smbclient, samba, libwbclient lfleischer: libical bisson: postfix alucryd: lib32-db anatolik: apr-util andyrtr: bogofilter - dbus-c++: schiv: libffado dvzrv: libffado fyan: kimtoy - dev86: eworm: virtualbox, virtualbox-sdk, virtualbox-guest-utils-nox - dmenu: kkeen: spectrwm lcarlier: uzbl-browser - docbook2x: spupykin: moreutils, lxc andyrtr: libcmis seblu: nftables guillaume: java-jsvc, java-commons-daemon fyan: ibus-table bisson: conky - dotconf: svenstaro: libspeechd, speech-dispatcher - double-conversion: fyan: qt5-base arojas: qt5-base - dvgrab: bluewind: openshot - ecryptfs-utils: jsteel: clonezilla - enca: anthraxx: mencoder, mplayer jlichtblau: ogmrip - faenza-icon-theme: alucryd: faience-icon-theme - farstream: foutrelis: pidgin, finch, libpurple heftig: telepathy-farstream - fig2dev: zorun: coqide, coq, coq-doc - flickcurl: Archange: darktable - fltk: ronald: octave schiv: alsa-tools arojas: libgiac, xcas arodseth: tuxpaint-config, monica dvzrv: zynaddsubfx kkeen: xdiskusage, dillo lfleischer: lmms spupykin: tigervnc - freetds: fyan: qt5-base, qt5-xcb-private-headers arojas: qt5-base, qt5-xcb-private-headers pierre: php-gd, php, php-imap spupykin: perl-dbd-sybase - frei0r-plugins: heftig: gnome-video-effects arojas: mlt-python-bindings, mlt - fribidi: eric: avidemux-qt, fvwm, avidemux-cli anthraxx: avidemux-qt, avidemux-cli alucryd: libass, ffmpeg2.8, ffmpeg jlichtblau: glob2, fillets-ng ronald: efl svenstaro: wesnoth, supertuxkart idevolder: kodi bisson: m17n-lib spupykin: fbreader arodseth: tuxpaint jgc: abiword lcarlier: warzone2100 - ftjam: eric: lincity-ng jlichtblau: lincity-ng svenstaro: megaglest Archange: argyllcms - gamin: tpowa: smbclient, samba, libwbclient schiv: snd - gegl: jgc: gnome-photos heftig: gnome-photos - gegl02: anthraxx: gimp eworm: gimp - giblib: anthraxx: scrot - glyr: Alad: pragha - gnome-autoar: jgc: nautilus, evolution heftig: nautilus bgyorgy: gnome-recipes - gnome-icon-theme-symbolic: jgc: gnome-icon-theme - gnustep-base: svenstaro: oolite heftig: meson anthraxx: meson - gnustep-gui: svenstaro: oolite - gnustep-make: svenstaro: oolite - goocanvas: jlichtblau: goocanvasmm bgyorgy: ocrfeeder jgc: libgda heftig: libgda - gpsbabel: jlichtblau: gebabbel
