- Arch-dev-public - lists.archlinux.org

[arch-dev-public] New ideas for notifying users about (minor) changes
by Christian Rebischke 30 Jul '19

30 Jul '19

Hello everybody, I got assigned to this issue here: https://bugs.archlinux.org/task/62823 The users would like to have a notice in pre/post install/upgrade notifications via pacman .install files. I am not a fan of spamming such news via pacman and I think the installation/upgrade process should be clean of such messages, but I don't have access to the news tool on our website as well. So what can we do here? I am a big fan of Gentoos Newsletter feature[1]. It would be super awesome if we would have a tool such like `archnews <packagename>` to retrieve NEWS about a certain package from an endpoint. This endpoint should be controllable by every maintainer (devs and TUs included). I discussed this with coderobe a bit and we came to different solutions: Solution 1: a NEWS file inside of the package repository: -------------------------------------------------------- A maintainer could upload a `NEWS` file into the package repository and then a client could grab this information directly via downloading the file from: https://git.archlinux.org/svntogit/community.git/plain/trunk/NEWS?h=package… Pro: + every maintainer could control this NEWS file easily via our current tools. + It's easy to download the NEWS files (we can expect new tools from the community) Con: - We bloat our repository Solution 2: commit messages as NEWS ------------------------------------ The maintainer could/should put such news into the latest commit message. Pro: + no extra file + using existing infrastructure + one workflow Con: - I need an actual change in the repository to create a new NEWS object (If we have a look on my example with strongswan, I would need to add something in the PKGBUILD to make a new commit to make a new NEWS object) - It's more difficult to get with tools. The user needs to checkout the repository (in solution 1 it can be just a curl call) Solution 3: A webapp on news.archlinux.org with a fancy UI ----------------------------------------------------------- This solution would be the most work. We could have a new webapp (such like our security tracker) just for NEWS objects. Every maintainer should have access to their assigned packages. Pro: + Fancy + Easy to use + API endpoints Con: - A lot of work ------------------------------------------------------------- I would go for solution 1. What would be interesting to know for me: 1. Do you think that we actually *need* such a tool? 2. Would you use such a tool/workflow? 3. Do you have other/better ideas? I hope for an interesting constructive discussion. Best regards chris [1] https://wiki.gentoo.org/wiki/Gentoo_Cheat_Sheet#Gentoo_Monthly_Newsletter_.…

6 10

[arch-dev-public] Database maintenance affecting AUR & BBS
by Jelle van der Waa 27 Jul '19

27 Jul '19

Hi all, Luna requires some database maintenance to improve the stability of MySQL. This will affect the AUR and the BBS (forums) which will be down for some time to dump and import the aur and bbs database. It is expected that this will take an hour at max. Maintenance will shall start today at 12:00 UTC. -- Jelle van der Waa

1 0

[arch-dev-public] Dropping dingo from [community]
by Felix Yan 27 Jun '19

27 Jun '19

Hi All, I have removed dingo the Google DNS-over-HTTPS client from [community]. The upstream is inactive for years and supports Google only. I would recommend dns-over-https [1] instead which has support for multiple protocols and is still actively maintained. Note that Google announced [2] yesterday that they recommend to use the newer IETF protocol (at a new endpoint), which is also the protocol of all other major DoH providers (CloudFlare, Quad9, etc). [1] https://www.archlinux.org/packages/community/x86_64/dns-over-https/ [2] https://security.googleblog.com/2019/06/google-public-dns-over-https-doh.ht… -- Regards, Felix Yan

2 1

[arch-dev-public] HEADS UP: Qt 5.13 in [testing]
by Antonio Rojas 22 Jun '19

22 Jun '19

The usual warning: anything built against 5.13 will automatically get a runtime dependency on it, so it will need to wait in testing until Qt itself moves.

1 0

[arch-dev-public] Drop ekiga?
by jan＠jgc.homeip.net 09 Jun '19

09 Jun '19

Hello, I would like to drop Ekiga. The software hasn't seen a release in years, the git master branch has some active development now and then, but a release for Ekiga5 is not near (though upstream stated the software itself is ready enough to release v5 a year ago). Alternative is to bump Ekiga to git master and hope it doesn't have too much bugs. Issue that gets fixed: one package less that depends on gconf Issue that remains: Ekiga still depends on deprecated and unmaintained versions of Opal/ptlib Regards, Jan de Groot

3 3

[arch-dev-public] Away until June 17
by Laurent Carlier 07 Jun '19

07 Jun '19

For holidays Feel free to break everything ! -- Laurent Carlier http://www.archlinux.org

2 1

Re: [arch-dev-public] Dropping nvidia-340xx series
by Giancarlo Razzolini 04 Jun '19

04 Jun '19

Em maio 21, 2019 11:40 Ralph Corderoy escreveu: > > That's a good idea. > > I'll try switching to nouveau and seeing if that handles video well on > here now. > https://wiki.archlinux.org/index.php/Nouveau#Keep_NVIDIA_driver_installed > I think nouveau will probably perform better for most of the hardware covered by 340xx. If nobody steps up in the following days I'll drop the package to the AUR. Doesn't help keeping it rotting in our repo when the next kernel update will make it obsolete. Regards, Giancarlo Razzolini

2 2

[arch-dev-public] Archweb updates
by Jelle van der Waa 04 Jun '19

04 Jun '19

Hi all, In the latest archweb release on our website there is a new report called "non existing dependencies" which shows packages with missing (opt|check|make)depends these should be fixed. [1] Apart from that, the signoff overview page on /devel now shows the packager and maintainer which can be useful for rebuilds. [2] [1] https://www.archlinux.org/devel/reports/non-existing-dependencies/ [2] https://www.archlinux.org/devel/ -- Jelle van der Waa

1 0

[arch-dev-public] Proposal for a new organisation structure
by Christian Rebischke 03 Jun '19

03 Jun '19

Hello everybody, ---------------------------- DISCLAIMER: Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. ---------------------------- inspired by the last thread about moving proprietary software to community, our general problem of getting more people involved in Arch Linux and the (for me) chaotic organisation structure and hierarchy I would like to propose a discussion about changes. Please don't see this thread as an attack on your current position or whatever. I would like to propose a more democratic, simplified and more contribution friendly approach for our current hierarchy and organisation structure. At the moment we have the following three Groups (If I miss something feel free to correct me): - Devs - Trusted Users - Support Staff These three groups have the following 'features' and tasks: - Devs: - Tasks: The developers care about [core] and [extra] repositories, they form a direction for the whole project 'arch linux' and they seem to have a veto-permission for TU decisions. Furthermore they have access on most infrastructure and they are maintaining/developing the core software like pacman. Some devs also care about trademarks, legal requests and finance or community events. - How to be a developer?: The developers will decide in a non public and secrete ritual who is worthy to be a developer. The process is unclear. - Trusted Users: - Tasks: The trusted users care about the [community] repository, somehow some TUs have more tasks like: security team involvement, wiki administration, infrastructure administration, maintainership of software projects and other infrastructure projects like docker images, reproducible builds etc. Furthermore they care mostly about the package quality in the AUR (eg. answering submitted requests...) - How to be a trusted user?: It's well documented, we have rules for misbehavior, rules for applying, guidelines for moving packages into community and more. - Support Staff: - Tasks: They do various tasks like infrastructure administration, wiki administration, bug wrangling, software contribution, forum moderators, security team, but they have no access to any repository. - How to be a support staff: It's unclear, mostly a new contributor just knows the right people and does the right thing at the right time and get somehow acknowledged by developers or TUs for their work. Ok, I hope this gives a good overview over all three groups. Besides these groups, we have also people in more than of these groups. Anthraxx is for example listed as (dev,tu and support staff) on our website, I am listed as (tu and support staff) and so on. So what is my actual proposal. Well my proposal is to simplify the whole organisational structure, tear down bureaucracy, tear down 'walls' and unify the community and make it easier for 'outsiders' to contribute to the project we all love. Therefore I would like to propose a discussion around the following things: 1. Simplified repositories Currently we have [core], [extra] and [community]. These three repositories are there, because they have grown to this structure over time. At the moment I don't see any real meaning for the split of [core] and [extra]. So one suggestion would be to either: - merge [extra] and [core] - or use [extra] for a new purpose, like for example a proprietary repository, for all proprietary software. (I know that this is not possible for all packages, because we have binary blobs in device drivers and kernel modules). 2. Repository access At the moment a TU can access all packages inside of the [community] repository. Therefore they are able to modify packages in a good or bad manner. This can have nice effects and bad effects, how the past has shown to use, such as: - rapid updates in case of security vulnerabilities (good effect) - updates of packages, because somebody thought it needs an update, but the real reason for the delay was a bug inside of the new version of a software (bad effect) 3. Organisation structure Depending on the repository access, we could reduce our organisation structure to just two groups: Devs and maintainers (a similar approach to big distributions like Debian). Devs could still have the 'superpower' for caring about infrastructure and legal/finance stuff and the group of trusted users and support staff would merge to one group of maintainers. With person-related access to package repositories we could tear down the whole repository structure to one, maybe two, repositories and we could give co-maintainership an actual meaning (permission to modify a foreign package). 4. More transparency At the moment the recruiting process for developers is pretty unclear, as well as the actual decision making inside of the developers group, veto permissions and other things. This leads to a 'they vs/with us' thinking and makes it difficult to increase contribution in the community. Therefore I would like to propose more transparency for all groups who are involved in Arch Linux development and more communication between devs and TUs. At the moment the devs will mostly say:"Ok, this is a TU thingie, so I don't need to get involved in this question regarding TU rules or rules for community or anything else". It would be also nice to form an actual roadmap (yes.. I know.. we are not a company, but a roadmap or overview over all current projects inside of our community would be nice). This way it would be also easier to contribute for 'outsiders'. Sorry for the huge mail, I didn't thought it would get so long. If you feel attacked/angry or whatever about it, take a deep breath before you answer. I hope for a constructive discussion without personal attacks. Best regards and many thanks for reading the whole mail, shibumi / chris

7 11

[arch-dev-public] bringing vivaldi browser to community
by Ike Devolder 02 Jun '19

02 Jun '19

3 years have passed since I first proposed to bring vivaldi into community. Now there is a clear differentiation between what vivaldi offers out-of-the box compared to other browsers. Vivaldi offers a ton of customisation features out of the box, and is also able to just use the chrome/ium addons from the chrome webstore. Personally I'm using vivaldi as my main browser since somewhere in 2015 (shortly after the first beta was released) and the key features no other browser currently offers are: - webpanels - quick commands - tabtiling - tabstacking - tabbar positioning I'll bring it in the same way as with opera, where you have the webbrowser + separate packge with libffmpeg.so to allow the playback of proprietary formats like mp4.

4 9