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

[arch-dev-public] TU application process
by Christian Rebischke 06 Nov '18

06 Nov '18

Hello everybody, First of all, the following mail has nothing to do with the last two TU applications, it's a general view on the current TU application process. I would like to propose a new process for TU applications due to several reasons: 1. I have the feeling that most sponsors are not aware of the responsibility of sponsoring a new TU candidate. There is more to do than just approving their application. Candidates should get advice for and after the application process. This includes: * learning how to sign mails * getting feedback for their PKGBUILDs from their sponsoree * getting advice for building packages correctly via makechrootpkg wrappers * getting help for the post-application-process, when the candidate has been accepted. * directing the new candidates to our IRC channels or mailinglist for community intergration. 2. I have the feeling that most TUs only vote, because of our new stricter bylaws. 3. I miss more TU contribution in TU application processes as well. I guess the reasons for the points above are missing time or missing mood for actively participating in the discussion. Therefore I would like to suggest some modifications to our TU application process. Here are some ideas from a discussion we had last night in the TU IRC channel: 1. Establishing a TU council, that get elected a certain time slot. The members of this council are responsible for accepting or rejecting a TU. Every TU can still sponsor or suggest a candidate, but the voting process will be done in this council only. The council should consist out of very active TUs and devs, who are known for a good package quality. 2. Establishing a 2-sponsors-rule instead of the current policy of one sponsor. 3. <your suggestion here> Best regards from Germany chris / shibumi

7 10

[arch-dev-public] New permissions on ArchWiki
by Alad Wenter 02 Nov '18

02 Nov '18

Hi everyone, New user groups have been deployed to the wiki (thanks to Dario and Bluewind [1]), and I've started migrating DeveloperWiki and the developer accounts accordingly. More information on the groups can be found at [2]; I will give a short summary below. 1) DeveloperWiki pages can now be edited by the "cosysop" group, the former group for wiki maintainers. It is a weaker form of "sysop" or the group meant for purely administrative tasks such as deletion of pages. As such, I have added the "cosysop" group to developer wiki accounts. To avoid extraneous permissions on the wiki where they would otherwise not be required, "sysop" rights were removed from these accounts if present. If for some reason you still require the "sysop" right, please send me an email off-list. User rights may be viewed under [3]. 2) The "cosysop" and "sysop" groups are distinct from the "roles" as we commonly know them. In particular, every TU is now part of the "archtu" group, every staff member of the "archstaff" group, and every developer part of the "archdev" group. These groups in themselves have no additional permissions, and serve for easy identification of staff members on the wiki. 3) When groups are changed on a wiki account, the owner is notified with an email that his user page has changed. [4] However, no changes are visible in the history. This appears to be a bug in MediaWiki. If there are further questions, please let me know. Alad [1] https://github.com/archlinux/archwiki/pull/20 [2] https://wiki.archlinux.org/index.php/ArchWiki:Access_levels_and_roles [3] https://wiki.archlinux.org/index.php/Special:UserRights [4] https://ptpb.pw/2rj0

1 0

[arch-dev-public] .gnuog owned by root when using devtools in first place
by NicoHood 13 Oct '18

13 Oct '18

I ran extra-x86_64-build on a new system with an uninitialized gnupg keyring. I think it was responsible for creating a .~/gnupg directory, but with root privilegs. I chowned it to my user, it is all good now. Maybe the script could be improved to check if the gnupg keyring was initialzed or not, to prevent such issues. I was confused in the first place. ~Nico

2 1

[arch-dev-public] Removing the vim-systemd package
by Alexander Rødseth 08 Oct '18

08 Oct '18

Hi, systemd syntax support is now included in both vim and neovim. I'm removing the vim-systemd package from [community]. -- Best regards, Alexander F. Rødseth

1 0

[arch-dev-public] Away for two weeks
by Jelle van der Waa 05 Oct '18

05 Oct '18

Hi all, I'll be away for two weeks without a laptop so I won't be able to do any packaging. Feel free to update my packages or fix my open bugs ^_^ If there is something really urgent, I should be able to reply via e-mail. -- Jelle van der Waa

3 2

[arch-dev-public] Meeting on dbscripts git repository layout and debug packages
by Bartłomiej Piotrowski 18 Sep '18

18 Sep '18

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

1 2

[arch-dev-public] rename lcms -> lcms1
by Christian Hesse 18 Sep '18

18 Sep '18

Hello everybody, we have packages lcms (which provides lcms 1.x) and lcms2. The former is flagged out-of-date every now and then for version 2.x... I would like to rename the package to lcms1 with replace and provide for lcms. Any concerns? -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

4 4

[arch-dev-public] Request to orphan Snowman's packages
by Balló György 17 Sep '18

17 Sep '18

Eric Bélanger (Snowman) was inactive as package maintainer in the past two years. [1][2] Is it possible to disown his packages on archweb? I think it would better to make it visible that his packages are actually orphan. https://git.archlinux.org/svntogit/packages.git/log/?qt=author&q=eric https://git.archlinux.org/svntogit/community.git/log/?qt=author&q=eric -- György Balló Trusted User

2 1

[arch-dev-public] Proposal to remove libglade
by Balló György 17 Sep '18

17 Sep '18

Hi all, Similar to my previous mail, I orphaned some of my packages which have a dependency on libglade. Libglade is deprecated in favor of GtkBuilder since 2009, [1] and does not receive any fixes since then. I would propose to remove it from the official repositories. The following packages were ported from libglade to GtkBuilder, but not released yet: - deluge (via pygtk.glade, only the GUI part) - gespeaker (via pygtk.glade) - obconf - ogmrip The following packages were not ported yet, and most of them have inactive upstream: - agave (via libglademm) - bless (via glade-sharp) - foxtrotgps - fyre - gnome-hearts - gnome-schedule (via pygtk.glade) - gsql - keepnote (via pygtk.glade) - labyrinth (via pygtk.glade) - lat (via glade-sharp) - mono-tools (via glade-sharp) - muine (via glade-sharp) - netactview - obmenu (via pygtk.glade) - planner - pympd (via pygtk.glade) - python2-matplotlib (via pygtk.glade, only the GTKAgg and GTKCairo backends, which were already removed from git master) - rox-lib (via pygtk.glade) - scribes (via pygtk.glade) - smuxi (via glade-sharp) - tuna (via pygtk.glade, only the GUI part) - vmoviedb - xournal (via libgnomecanvas) - xscreensaver (only the xscreensaver-demo GUI) After the above packages were fixed or removed, libglade support can be disabled in the following packages: - gtk-sharp-2 - pygtk After that libglade and related packages can be removed: - glade-perl - gnet - lib32-libglade - libart-lgpl - libglade - libglademm - libgnomecanvas Any objections? [1] https://mail.gnome.org/archives/devel-announce-list/2009-May/msg00003.html -- György Balló Trusted User

1 0

[arch-dev-public] Proposal to remove GConf
by Balló György 13 Sep '18

13 Sep '18

Hi all, Recently I orphaned some of my packages which have a dependency on gconf. GConf was used in GNOME 2 as the settings storage daemon. It's deprecated since 2010 in favor of GSettings, and does not receive any fixes since 2013. I would propose to remove it from the official repositories. The following packages are fully functional without GConf: - aisleriot (FS#60000) - brasero (FS#59978) - emacs (FS#59887) - firefox-developer-edition - firefox (FS#59992) - gnome-terminal (FS#59980) - ibus (requires gsettings-schema-convert during build if the dconf module is enabled) - qcef (libcef must be built from sources to disable gconf usage) - steam-native-runtime (FS#60036) - thunderbird (FS#59993) The following packages were ported from GConf to GSettings, but not released yet: - ekiga - ogmrip The following packages were not ported yet and have inactive upstream: - alleyoop - apcupsd (only the GUI part) - billreminder - ccgo - docky - gnome-alsamixer - gnome-do - gnome-schedule - gsql - hamster-time-tracker - muine - planner - tomboy - vmoviedb After the above packages were fixed or removed, GConf and related packages can be removed too: - gconf - gconf-editor - gconfmm - gconf-sharp - lib32-gconf - python2-gconf Any objections? -- György Balló Trusted User

1 0