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

[arch-dev-public] Can anyone take nvidia-390xx?
by Sven-Hendrik Haase 23 Feb '20

23 Feb '20

I don't run nvidia-390xx on any of my devices. I would appreciate it if somebody could take those drivers. I will continue maintaining the mainline nvidia package.

2 1

[arch-dev-public] Improving overall experience for contributors
by Bartłomiej Piotrowski 06 Feb '19

06 Feb '19

Hi all, Spending some time outside the regular Arch circles, I realized that the way we "outreach" potential contributors is at least imperfect. One of the problems I keep hearing about is that there is no clear place where potential contributors could start. Sure, some things seem obvious to us: take care of some wiki article or adopt orphan AUR packages. It isn't actually that easy. Not everyone is interested in editing or maintaining random packages, and while there is plenty to do, how someone new could know it? We could use help not only with existing projects like archweb, pyalpm or namcap, but also with development of new code (for example a maintainable rebuild automation) and infrastructure side (which is in fact too generic term that could be better described). I am totally in love with What can I do for Mozilla?[1] which is open source, so why not steal this wonderful idea? But it also means we need a way to communicate with people interested in helping us: at least an IRC channel and new mailing list. Another thing that I heard in last few months isthat it is actually hard for potential TU candidates to find a sponsor. While I believe it is perfectly fine to e-mail few potential sponsors to ask for opinion, throwing random messages at people doesn't sound really appealing. In my humble opinion, we should rethink the way we recruit people and probably introduce fine-grained permissions to dbscripts that would allow to limit new maintainers to limited set of packages. We should also lower our expectations towards candidates. At least once we rejected one for some stupid reason (no fingerpointing here, I'm not saint either), leaving packages they wanted to adopt virtually orphan. It's better to help amn inexperienced packager gain experience than voting no, really; to be brutally honest, quite a lot of packaging work we are handling doesn't have much in common with rocket science. I also wanted to touch mailing lists vs GitHub vs Gitlab topic but we will tackle it another time. Your thoughts? Bartłomiej [1] https://whatcanidoformozilla.org/

8 11

[arch-dev-public] Arch Linux Cloud Images (virtualbox and Qemu)
by Christian Rebischke 07 Nov '18

07 Nov '18

Hello everybody, Some months ago Bartlomiej had the awesome idea to generate qemu and virtualbox images as well. Afterwards we had a small discussion about this topic in #archlinux-projects. I would like to refresh this discussion and move it to this mail thread. So, our vagrant boxes are building automatically and without issues for a few months now. I could just generate virtualbox and qemu images as side products monthly, but I have no idea how we would release them. Another big topic is security. The vagrant images are at the moment not signed and seems like vagrantcloud doesn't support this either. This doesn't mean that we shouldn't sign our qemu or virtualbox images. We could just generate an automated cloud image signing key (only for this purpose) of course and automatically sign the images with that key. Problem with this is: If our build server ever get pwned the person will have these keys for signing cloud images as well. Any opinion about this? In my humble opinion I would be fine with a signing key that follows only this particular purpose. Another idea would be to move the whole production process to a physical server behind a firewall that is physical accessible by one or more Arch Linux Developers. I really would like to push this forward. Any comments? Chris

4 4

[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

[arch-dev-public] [RFC] Remove svn propset id's
by Jelle van der Waa 12 Sep '18

12 Sep '18

Most of our PKGBUILDs svn propset's break reproducible builds and the pkgbuild_sha256sum in the BUILDINFO file. When building a package before commiting the PKGBUILD the propset $Id will differ since the $Id is set on commit. 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). To resolve this issue we could simply remove the propset id's, since for me, although not sure about others they don't seem particulary useful. The proof that the sha256sums's don't match: $ extra-x86_64-build $ grep sha256 .BUILDINFO pkgbuild_sha256sum = 8748d60d2c782f477cb7e692a3dad30be90491cdc13fe8951340da4c0bc7f19e $ $repopkg $ sha256sum PKGBUILD d8ab51a983026dd4a6e2f48e9dc66177eca8cf6c1c0ffefb950b093db299e304 PKGBUILD # The git checkout [jelle@helium][/tmp/bar/community/python-psutil/trunk]%sha256sum PKGBUILD ce7f1e68a3b426412a24f46016817d30721860c8ef6b3d0a2dddac8ff2448b84 PKGBUILD [jelle@helium][/tmp/bar/community/python-psutil/trunk]%diff PKGBUILD /tmp/python-psutil/trunk/PKGBUILD 1c1 < # $Id$ --- > # $Id: PKGBUILD 375007 2018-08-28 17:24:26Z jelle $ -- Jelle van der Waa

6 7

[arch-dev-public] /r/linux AMA
by Morten Linderud 10 Sep '18

10 Sep '18

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_develope… 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 :) -- Morten Linderud PGP: 9C02FF419FECBE16

8 9