Re: [arch-dev-public] Orphaned packages from arcanis
I'll be dropping these packages to the AUR the upcomming days. - eric - eric-i18n - pychecker - canorus - julius - libasl - python-pmw - libmatio - pdfsam - voxforge-am-julius - g15daemon - libg15 - libg15render -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] [RFC] Debug packages and debuginfod
On Tue, Dec 01, 2020 at 12:58:40PM +0100, Jelle van der Waa wrote: > > > > - Add a debuginfod role to the infrastructure repository. > > Please create a new ticket in the infra repo with some > requirements/details! Especially with information where we host > debuginfod, size requirements etc. I don't know about size. I think the question is if we are happy to have the debuginfod service running on gemini, or if we want another service for this purpose. This is also why I wanted some time on this on a future devops meeting :) So hopefully we can lay down some problems and solutions. > > - Test and deploy the dbscripts support for debug packages. > > Is this separate of the Git migration? Or is the git migration a > requirement to get debug packages This is seperate from the git migration, yes. > > - Add support to devtools for uploading debug packages. > > - Announce debuginfod support. > > - Discuss how to distribute the packages. > > We can at least host them on gemini and make them staff only in the > beginning. I agree :) > Greetings, > > Jelle Thanks for the followup! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] [RFC] Debug packages and debuginfod
Give me cake, or give me debug symbols. - Some comedian, probably. Yo! For quite a few years people has wanted debug packages, but there has never really been any progress towards them. Pacman got support almost 10 years ago, and Allan wrote a POC for dbscripts in 2015[1]. In recent years this has largely been a discussion how large such a repository would become, and how to distribute it. But since we don't have any numbers things have more or less stalled with things being discussed, but never worked on. Dropping an imaginary 100 GB on some poor mirror hosts doesn't seem quite right. However, things has been been progressing for the better when it comes to the distribution of debug symbols that can hopefully make this entire process easier for us. debuginfod has been introduced into elfutils which allows a standardized API for fetching remote debug symbols [2]. Eli and I have have been chatting a little with upstream since February to ensure we could get our package format supported. This was fairly straight forward with an example package from us and things have been working nicely. Patches in elfutils: https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=499129e77aa88b94756bd6c8d50347721689065c https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=0245c6ed65a80bceb105317525f0cf38bf27b623 https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=ad09e791320d13149854ce7a0529842ea0d41a3d We have been distributing debuginfod since 0.178-1 and debuginfod support came to gdb with the 10.1 release, which is why I'm picking up on this now :) We did some testing with the debuginfod support with Stapelberg during the summer, and it works fairly well [3]. Eli has also started writing up the support for splitting out the debug packages into a separate pool [4]. I have since merged some of Elis dbscripts patches to the POC git migration server to test things. The idea is to allow uploads of debug packages to repos.a.o into a separate package pool, have a public reachable debuginfod and then consider if we want/need debug package distribution. We can then check the new mirror requirements, and give a clear heads up to any potential mirror admin while providing debug packages. I think this is a reasonable compromise for everyone. OpenSUSE already has one such server as an example [5]. There isn't any one way we have to progress on this, but my proposed timeline is as follows: - Add a debuginfod role to the infrastructure repository. - Test and deploy the dbscripts support for debug packages. - Add support to devtools for uploading debug packages. - Announce debuginfod support. - Discuss how to distribute the packages. I anticipate we can start a new discussion for the last point as I think there is some issues we should think about in terms of archiving debug packages and so on. Is there any questions, concerns or suggestions for this proposed implementation? If anyone is interested trying out debug packages and debuginfod, on the POC git migration server, please do poke me! -- Morten Linderud PGP: 9C02FF419FECBE16 [1]: https://lists.archlinux.org/pipermail/arch-projects/2015-August/004301.html [2]: https://developers.redhat.com/blog/2019/10/14/introducing-debuginfod-the-elfutils-debuginfo-server/ [3]: https://twitter.com/zekjur/status/1268626664814247939 [4]: https://github.com/eli-schwartz/dbscripts/commits/wip/debug [5]: https://debuginfod.opensuse.org/ signature.asc Description: PGP signature
[arch-dev-public] Orphaned packages from arcanis
Yo! As a followup from the recent TU removal, I have composed a list of orphaned packages from arcanis. Please write back if you adopt anything else I'll drop packages into the AUR after some time has passed. As of now there are no package resigning that needs to be done. $ pkgsearch -m arcanis -l 1 | cleanup-list.py - Orphans required by maintained packages: - eric: arcanis: eric-i18n-en, eric-i18n-es, eric-i18n-de - g15daemon: idevolder: lcdproc - mftrace: arcanis: lilypond dvzrv: lilypond Unneeded orphans: canorus eric-i18n julius libasl libg15 libg15render libmatio libmmtf pdfsam pychecker pymol python-biopython python-pmw scala voxforge-am-julius Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Add active Python versions to the repos
On Sat, Nov 21, 2020 at 04:47:27PM +0100, David Runge wrote: > 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. > > > 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. I'm personally not very excited for the idea of adding more python interpreters. I'm a bit concerned that we today say "no packages" but in the future we relax a bit and end up with python36-$pkgname, as it's the pragmatic option as opposed to blocking entire rebuilds or package updates. What is the downsides of utilizing something like pyenv? There are user repositories providing older python interpreters as well if people need it. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Pam lockout
On Fri, Sep 11, 2020 at 03:55:17PM +0200, Tobias Powalowski via arch-dev-public wrote: > Hi guys, Yo, > https://bugs.archlinux.org/task/67644 > I second Levente's post of it's a configuration issue that needs to be > addressed by user and not by the package itself. Typing 3 times wrong > password is a sane default imho. > Any other opinions out there? What was the decision you wound up with here? The issue is still open and there should preferably be a decision? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Arch Conf 2020 videoes
Yo! I'd like to just point out to people that we have uploaded the talks to media.ccc.de :) https://media.ccc.de/c/arch-conf-2020 Youtube Playlist: https://www.youtube.com/playlist?list=PL3tfdJ8q1zXRFu6QPELCaIwU3BIzauUJi It went a bit quicker then expected so I'll do a httpdir drop with slides, music, written Q and any misc stuff that was used for the production of the conference sometime later this week. I'll also announce it properly on the conference webpage and to our speakers! I recommend everyone to go watch the keynote talk of the conference if you didn't catch it. The surprise from day 2 has also been added :) https://media.ccc.de/v/arch-conf-online-2020-6379-arch-linux-past-present-and-future Have a good week<3 -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] New version of the pkgstats client
On Mon, Oct 26, 2020 at 06:15:24PM +0100, Pierre Schmitz wrote: > Thanks for the hint. I thought I was on that list once; maybe I should > post more than twice a decade though :-) You where, but the planet was reimplemented into archweb to get rid of python2 services we don't strictly need. Also easier for people to manage their blog rss feeds instead of poking devops :) This probably works as a reminder for others to do the same! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] New version of the pkgstats client
On Sun, Oct 25, 2020 at 03:29:28PM +0100, Pierre Schmitz wrote: > For more information see the integrated help; I also wrote a quick > post at > https://pierre-schmitz.com/pkgstats-version-3-lookup-package-statistics-from-your-terminal/ Should add your blog to the planet :) https://www.archlinux.org/devel/profile/ -> Website rss: -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] SVN to Git Migration work and POC
We are moving to git! Hopefully...maybe...someday! This has been a change that has been discussed for years, but progress has been stalled because of different reasons. I decided to pick it up and work on getting devtools and dbscripts up to speed. It's important to note that nothing is changing in the very-near future, and there is still A LOT left to be figured out. This email is intended for the ones that wish to help out testing the current point of concept and come forward with thoughts and ideas. # tl;dr A quick summary of the technical changes so far: - Each package is it's own git repository located under a packages group on gitlab - Consolidated the dbscript distinction between "community" and "packages" into "packages" The git repostitories still keep the namespaces "community" for TUs, and "packages" for developers. - devtools creates .SRCINFO files upon commit - devtools creates signed tags in the package repository - Git tags has a seperate version scheme from pacman because git has limitations - pacman version: 1:1.2.3-1 - git tag:release-1-1.2.3-1 # Testing ## Gitlab Access We have gotten a gitlab instance running where we can create repositories. To help testing svn2git migration you need to access this instance. All accounts from team-members should have been created already, and all you need to do is to reset the password with your archweb email. https://gitlab.archlinux.org If you don't get any emails, you should contact devops. Important to note that I need to add you to the `package-test` group on gitlab if you wish to test the tooling. Please reply to me offlist, or poke me on `#archlinux-projects`. ## SVN Repository to Git conversion Anthraxx, with the great help of Ismael, has rewritten the original `gitsvn2git` bash script to a nice python tool to help us convert git2svn packages into standalone git repositories. When following the instructions below you can make your own packages or play around with the script with your current packages. https://github.com/anthraxx/arch-svn-package-to-git ## WIP Repository Currently there is a POC server running dbscripts on svn2gittest.archlinux.org. This server is provisioned by the devops team, with me being the administrator. Install the WIP devtools package from my repository: https://pkgbuild.com/~foxboron/repos/devtools/ It should live alongside the current devtools package and only provide the WIP tooling with git support. - Ensure you can ssh into svn2gittest.archlinux.org - The box has been deployed with our archusers ansible role and should contain the same users as orion - Navigate the package-tests project; https://gitlab.archlinux.org/packages-test - Create a repository in either packages or community. - You can use any package you want. Any consistency checks in the WIP repository has been removed and shouldn't interfer with any packages you push. - Work with the package as normal. - When you commit the changes use: `git-extrapkg` for packages under `packages-test/packages` `git-communitypkg` for packages under `packages-test/community` - When you have uploaded the package: ssh svn2gittest.archlinux.org "/packages/db-update" Note: The dbscripts tooling has been consolidated. There is not need for `/community/db-update` If there are any bugs, please poke me in #archlinux-projects The technical overview is currently being worked on in on in the archwiki: https://wiki.archlinux.org/index.php/User:Foxboron/GitMigration Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Congrats to the Arch Conf Team
On Mon, Oct 12, 2020 at 09:24:18AM +1000, Allan McRae via arch-dev-public wrote: > A big shout out to the Arch Conf Team! > > This weekend's conference was nothing short of awesome. It pulled > together very well, particularly given the short organisation period and > it being the first one run online. > > The recorded talks followed by live Q worked very well, and I enjoyed > the live commentary by the community either on IRC or twitch. > > Looking forward to next year! :) > > Allan Thank you Allan :) Much appreciated<3 I'll ensurer the Conf team see this email! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Autumn extra cleaning
So, Barth pointed out to me that I had actually taken his cleanup-list script and added it to contrib last year. Which I had forgotten. It generates a complete list of suggested maintainers instead of just dumping a list of packages. https://github.com/archlinux/contrib/blob/master/package/cleanup-list.py I'll work on improving a bit after Arch Conf. But here is the current orphan list run over [extra] as of tonight. The list currently contains devs and TUs. But it's a nice helper to figure out packages. I hope this helps :) # Orphans required by maintained packages: - a2ps: andyrtr: foomatic-db-engine - aalib: felixonmars: lib32-aalib, lib32-gst-plugins-good anthraxx: vlc, mplayer, mencoder jgc: xawtv heftig: gst-plugins-good - antlr2: svenstaro: classpath - antlr4: eworm: mysql-workbench - c-ares: seblu: quagga jelle: mosquitto felixonmars: nodejs, aria2, python2-gevent svenstaro: tensorflow-cuda, tensorflow-opt-cuda, python-tensorflow-opt-cuda kgizdov: tensorflow-cuda, tensorflow-opt-cuda, python-tensorflow-opt-cuda mtorromeo: php-grpc, grpc-cli, grpc spupykin: unrealircd Archange: nodejs-lts-erbium, nodejs-lts-dubnium, electron5 anthraxx: wireshark-qt, wireshark-cli, pgbouncer FFY00: wireshark-qt, wireshark-cli jgc: nghttp2 tensor5: electron, electron5 - 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 - cln: felixonmars: cvc4 jlichtblau: ginac - cmark: alucryd: mkvtoolnix-cli, mkvtoolnix-gui - convertlit: arojas: ebook-tools - cvs: kkeen: gerbv - enca: anthraxx: mplayer, mencoder - expac: kkeen: pacmatic, aurphan felixonmars: bibletime, deepin-kwin, deepin-qt5platform-plugins FFY00: deepin-terminal - farstream: foutrelis: finch, pidgin, libpurple - fastjar: anthraxx: openjdk7-src, jdk7-openjdk, openjdk7-doc - freetds: pierre: php-embed, php-snmp, php-cgi eworm: freeradius felixonmars: qt5-xcb-private-headers, qt5-base arojas: qt5-xcb-private-headers, qt5-base spupykin: perl-dbd-sybase - giblib: anthraxx: scrot - gnugo: arojas: kigo - gperftools: foxxx0: ceph-libs, ceph, ceph-mgr dvzrv: mixxx, pound - gsfonts: jgc: cairo, evince andyrtr: cairo lcarlier: cairo kkeen: racket, racket-minimal diabonas: texworks arcanis: lilypond lfleischer: graphviz felixonmars: libwmf, lib32-cairo anthraxx: xpdf arojas: imagemagick, imagemagick-doc heftig: libmagick6, evince jelle: grafana seblu: grafana arodseth: ditaa - gts: lfleischer: graphviz - hddtemp: foutrelis: xfce4-sensors-plugin - id3lib: arcanis: id3v2 jlichtblau: kid3-common, castget alucryd: easytag dvzrv: easytag arojas: kwave - ifplugd: tpowa: archboot - ispell: andyrtr: hunspell-de - java-hamcrest: anthraxx: ant-doc, ant FFY00: pdftk diabonas: tpm2-pkcs11, pdftk - java-rhino: anthraxx: openjdk7-src, jdk7-openjdk, openjdk7-doc - junit: foxxx0: ceph-libs, ceph, ceph-mgr anthraxx: icedtea-web, ant, grails andyrtr: libreoffice-fresh, libreoffice-fresh-sdk, libreoffice-still-sdk FFY00: pdftk diabonas: junit-system-rules, tpm2-pkcs11, pdftk arodseth: swi-prolog - leveldb: foxxx0: ceph-libs, ceph, ceph-mgr lcarlier: minetest-common, minetest-server, minetest felixonmars: python-plyvel, librime - libatomic_ops: foxxx0: ceph-libs, ceph, ceph-mgr anatolik: crystal andyrtr: libreoffice-fresh, libreoffice-fresh-sdk, libreoffice-still-sdk arodseth: gauche - libkate: dvzrv: icecast anthraxx: vlc heftig: gst-plugins-bad-libs, gst-plugin-opencv, gst-plugins-bad jlichtblau: ffmpeg2theora - liblqr: arojas: imagemagick, imagemagick-doc heftig: libmagick6 - libmilter: spupykin: opendmarc, opendkim foxxx0: opendmarc, amavisd-milter, libspf2 anthraxx: clamav - libmng: anthraxx: mplayer, mencoder, gimp bgyorgy: synfig eworm: gimp felixonmars: qt5-imageformats arojas: qt5-imageformats - libnet: anthraxx: dsniff, openjdk11-src, jre11-openjdk sangy: ettercap, ettercap-gtk bluewind: syslog-ng spupykin: ipguard - libnice: arojas: telepathy-gabble heftig: gst-plugins-bad-libs, gst-plugin-opencv, gst-plugins-bad - libofa: heftig: gst-plugin-opencv, gst-plugins-bad, gst-plugins-bad-libs - libots: jgc: abiword - libpano13: Archange: hugin - libspiro: jgc: gegl lfleischer: fontforge - libstroke: kkeen: geda-gaf - libtiger: anthraxx: vlc - libtommath: andyrtr: libreoffice-fresh, libreoffice-fresh-sdk, libreoffice-still-sdk felixonmars: libfbclient - libuninameslist: lfleischer: fontforge - libusb-compat: Archange: libnfc, acsccid, flashrom bluewind: apcupsd bgyorgy: gnokii
Re: [arch-dev-public] News draft: Arch Conf 2020 schedule
On Wed, Sep 23, 2020 at 11:01:33AM -0400, Santiago Torres-Arias wrote: > > > I think it's pretty clear from the drop down on the right (it also lets > > > me choose my local TZ)... > > > > What :D I don't see any drop downs > > > > I'll add a link to https://everytimezone.com/ regardless to make it easier > > after > > an offlist suggestion from Stapelberg. > > Ok, the more the merrier, but am I crazy for seeing this? (ss attached). > > -Santiago We sorta deduced on IRC that this is probably shown when you are outside of the conference timezone. Which is a tiny bit non-obvious :) But I'll add the timezone link regardless so people in UTC+2/CEST don't ask. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] News draft: Arch Conf 2020 schedule
On Wed, Sep 23, 2020 at 09:38:31AM -0400, Santiago Torres wrote:
> On Wed, Sep 23, 2020 at 02:48:59PM +0200, Morten Linderud via arch-dev-public
> wrote:
> > On Wed, Sep 23, 2020 at 11:43:16AM +0200, Morten Linderud wrote:
> > > On Mon, Sep 21, 2020 at 11:56:43PM +0200, Morten Linderud wrote:
> > > >
> > > > On the 10th and 11th of October there is going to be an online edition
> > > > of Arch
> > > > Conf. The conference is going to have presentations from the Arch team
> > > > along
> > > > with community submitted presentations and lightning talks.
> > > >
> > > > We are proud to announce the first revision of the schedule!
> > > >
> > > > ${LINK_TO_SCHEDULE}
> > > >
> > > > Updates and additional information can be found on the conference page:
> > > > https://conf.archlinux.org
> > > >
> > > > See you there!
> > >
> > > https://pretalx.com/arch-conf-online-2020/talk/
> >
> > I'll add a note about the timezone for the conference is CEST/UTC+2
> > (Europe/Oslo) as it's not clear from the schedule. Unsure if it's any good
> > way
> > to have this note somewhere on the schedule page itself.
> >
> I think it's pretty clear from the drop down on the right (it also lets
> me choose my local TZ)...
What :D I don't see any drop downs
I'll add a link to https://everytimezone.com/ regardless to make it easier after
an offlist suggestion from Stapelberg.
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-dev-public] News draft: Arch Conf 2020 schedule
On Wed, Sep 23, 2020 at 11:43:16AM +0200, Morten Linderud wrote:
> On Mon, Sep 21, 2020 at 11:56:43PM +0200, Morten Linderud wrote:
> >
> > On the 10th and 11th of October there is going to be an online edition of
> > Arch
> > Conf. The conference is going to have presentations from the Arch team along
> > with community submitted presentations and lightning talks.
> >
> > We are proud to announce the first revision of the schedule!
> >
> > ${LINK_TO_SCHEDULE}
> >
> > Updates and additional information can be found on the conference page:
> > https://conf.archlinux.org
> >
> > See you there!
>
> https://pretalx.com/arch-conf-online-2020/talk/
I'll add a note about the timezone for the conference is CEST/UTC+2
(Europe/Oslo) as it's not clear from the schedule. Unsure if it's any good way
to have this note somewhere on the schedule page itself.
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-dev-public] News draft: Arch Conf 2020 schedule
On Mon, Sep 21, 2020 at 11:56:43PM +0200, Morten Linderud wrote:
>
> On the 10th and 11th of October there is going to be an online edition of Arch
> Conf. The conference is going to have presentations from the Arch team along
> with community submitted presentations and lightning talks.
>
> We are proud to announce the first revision of the schedule!
>
> ${LINK_TO_SCHEDULE}
>
> Updates and additional information can be found on the conference page:
> https://conf.archlinux.org
>
> See you there!
And the first revision of the schedule has been release :)
https://pretalx.com/arch-conf-online-2020/talk/
If the news item looks fine and there is no objection I'll publish at the end of
the day.
Thanks!
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
[arch-dev-public] News draft: Arch Conf 2020 schedule
Yo!
I'd like to poste a news item about the schedule for Arch Conf. I reckon the
front page has better reach then the planet RSS feeds. Currently waiting for the
last of the talks to be confirmed before posting.
8<
On the 10th and 11th of October there is going to be an online edition of Arch
Conf. The conference is going to have presentations from the Arch team along
with community submitted presentations and lightning talks.
We are proud to announce the first revision of the schedule!
${LINK_TO_SCHEDULE}
Updates and additional information can be found on the conference page:
https://conf.archlinux.org
See you there!
>8
Cheers!
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-dev-public] Call for Participation - Arch Conf 2020 Online
On Mon, Sep 14, 2020 at 05:46:30PM +0200, Morten Linderud wrote: > On Thu, Aug 20, 2020 at 07:20:19PM +0200, Morten Linderud wrote: > > # Important Dates > > * Submission deadline: 18th of September Yo! The CFP ended 13 minutes ago. Thanks everyone from the team and community members for your talk submissions! Some preliminary statistics of what we have received: * 13 Talks * 6 Lightning Talks * 19 submissions in total 9 of these submissions are from team members :) People from the team should have gotten their confirmation emails already, and I'll go through the community submissions this weekend. The first schedule will be published Monday depending on the confirmations we get. I have submitted a Q on behalf of the team. The intention is to do this one live over jitsi one of the conf days and take questions from the chat. Please poke me if you are interested, or I'll poke you :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Call for Participation - Arch Conf 2020 Online
On Thu, Aug 20, 2020 at 07:20:19PM +0200, Morten Linderud wrote: > # Important Dates > > * Conference date: 10th - 11th of October > > * Submission deadline: 18th of September Heads up that the CFP date is comming up :) Please submit your talks before the deadline! Currently we are somewhere around 12-13 submitted talks :D https://pretalx.com/arch-conf-online-2020/cfp Poke me if you have questions! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Pam lockout
On Fri, Sep 11, 2020 at 03:55:17PM +0200, Tobias Powalowski via arch-dev-public wrote: > Hi guys, > https://bugs.archlinux.org/task/67644 > I second Levente's post of it's a configuration issue that needs to be > addressed by user and not by the package itself. Typing 3 times wrong > password is a sane default imho. > Any other opinions out there? I think this is fine. However, In danger of hijacking a discussion, what about FS#67636? That issue hasn't be handled and the lockout stuff is a non-issue after my opinion. https://bugs.archlinux.org/task/67636 -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Bug tracker migration
On Sun, Aug 30, 2020 at 01:02:51AM +0200, Frederik Schwan via arch-dev-public wrote: > Hi folks, > I'd like to migrate the beloved Flyspray bug tracker to our new Gitlab > instance. > [snip] > TLDR: > [snip] > - new bug tracker -> Gitlab > [snip] > 3) When enough tickets are closed or when $DevOps is tired enough of Flyspray, >we'll migrate the rest of the tickets to Gitlab. We seek to keep Flyspray > as a >static homepage to allow the reference in the new bug tracker to old > tickets >and to keep the integrity of search engine results. Removing flyspry is all fine and dandy, but I'm why hasn't there been any discussion *how* bugs are supposed to be handled on gitlab? What are our options besides gitlab? Why gitlab at all? There is some discussions moving from svn to git in the future, and I should have sent an email about this, but how can we be moving a bugtracker when we don't even know how packages are going to be structured in the first place? There is a lot that has been left out so why this sudden announcemnt with no insight? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Call for Participation - Arch Conf 2020 Online
Hello everyone! We are super excited to announce that the Arch Linux Conference 2020 is going to be held online on the 10th and 11th of October. The CFP has been published and everyone is free to submit talks and lightning talks from today until the 18th of September. If you have other ideas please do reach out! https://pretalx.com/arch-conf-online-2020/cfp # Pre-recorded talks All talks should be pre-recorded and sent to the team by the video submission deadline. You will be notified if the talk has been accepted shortly after the submission deadline has passed. # Important Dates * Conference date: 10th - 11th of October * Submission deadline: 18th of September * Video submission deadline: 5th of October # Streaming Streaming details are going to be published through September as there is still some more planning required for this part :) # Contributing We are still going to hold regular meetings over mumble and general planning in #archlinux-conf @ freenode until the conference starts in October. If you want to get involved and help out please do reach out and join the meeting :) Cheers from the Conference Team! signature.asc Description: PGP signature
Re: [arch-dev-public] Online Arch Linux Conference
A quick followup after last weeks meeting! The conference date is going to on the 10th and 11th of October. This was probably the most important thing to decide on so we have something to work towards. For the Call for Participation (CFP), we have been looking at utilizing pretalx. It's Open software, along with beeing used for the Chaos Communication Congress for a number of years, ang other conferences. Currently I'm trying to figure out if we can reach some deal with them, or self-host it. https://pretalx.com/p/about/ For the streaming itself we are looking at using the Chaos Computer Club VOC and media services. This would allow us to piggyback on great infrastructure for the stream distribution, along with keeping the recording of the talks. https://media.ccc.de/ There currently is some technical stuff that needs to be fixed and figured out regarding mixing and rtmp stream forwarding. The next meeting is going to be 18th of August, 19:00 CEST. #archlinux-conf @ freenode. The plan is to try have meeting on regular intervals and keep them under an hour. Feel free to join the next mumble meeting! Sorry for not sending this out sooner, I have been in the middle of between two apartments :) And for fun, here is me testing some stream overlay stuff: https://paste.xinu.at/Y9pK34lmjujXF/ -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Online Arch Linux Conference
On Wed, Jul 29, 2020 at 04:45:17PM +0200, Morten Linderud wrote: > On Wed, Jul 29, 2020 at 04:17:44PM +0200, Morten Linderud wrote: > > # Meeting > > > > Below is a suggested meeting date for interested parties to attend. I'm > > unsure > > if it's going to be mumble or purely text based. > > > > Date of meeting: > > 4th of August > > 19:00 CEST (UTC+2) - https://everytimezone.com/s/a5112249 > > IRC: #archlinux-conf @ freenode > > Just to clarify, this is the date for the initial planning of the conference. > Not the conference date itself :) Surely y'all haven't grown tired of my emails yet :) The meeting for the initial planning of the conf is today in 5 hours. Feel free to attend if you want to contribute, or contact me if you have nice! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Online Arch Linux Conference
On Wed, Jul 29, 2020 at 04:17:44PM +0200, Morten Linderud wrote: > # Meeting > > Below is a suggested meeting date for interested parties to attend. I'm unsure > if it's going to be mumble or purely text based. > > Date of meeting: > 4th of August > 19:00 CEST (UTC+2) - https://everytimezone.com/s/a5112249 > IRC: #archlinux-conf @ freenode Just to clarify, this is the date for the initial planning of the conference. Not the conference date itself :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Online Arch Linux Conference
Yo! Because of COVID-19 I assume most people have had some conference plans cancelled this year. FroSCon has had an Arch Linux devroom the past years, but as we are not meeting physically I guess that isn't happening either. Thus I want to try rally some people and have an online Arch Linux conference/devroom. There are not any major ambitions really. This can be a few hours an evening, or a weekend event. We will see what we figure out :) # Ideas Some of the ideas I have had so far is as roughly: * Team Q * Talks/presentations * team member and the wider community * Interactive streams * See how packagers do their work? * Arch Linux installation speedruns(?) * Workshops? Feel free to email me offlist, or poke me on other platforms, if you have other great ideas that could work! # Organization To organize we would need some help and might need some roles filled. This is a shortlist of the ones I can come up with. But I'm sure there are more tasks and roles needed: * Art-work/graphics * Help figuring out streaming * Planning and handling CFP There is no requirement to be on the Arch team to contribute. If you think you have anything to contribute, please do come talk with me! Need every help one can get :) # Meeting Below is a suggested meeting date for interested parties to attend. I'm unsure if it's going to be mumble or purely text based. Date of meeting: 4th of August 19:00 CEST (UTC+2) - https://everytimezone.com/s/a5112249 IRC: #archlinux-conf @ freenode Cheers! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] [aur-general] AUR migration
On Fri, Jul 24, 2020 at 05:27:06PM -0400, Eli Schwartz via arch-dev-public wrote: > This seems like it could be a reasonable situation for posting to > https://www.archlinux.org/news/ so that people seeing the keys change > understands why and that it's okay. Not everyone follows a-d-p or > aur-general. > > Thoughts? Yes please, I reckon people are going to ask repeatedly on support forums. Provide it signed as well, for the sake of it :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Wed, May 13, 2020 at 10:16:43PM +0200, Morten Linderud wrote: > If there are no objections, I'll probably merge the guidelines this weekend > section-by-section to make the wiki admins happy. The new package should land > sometime nextweek. It's been done. `go-pie` is no more. Please look over the new guidelines when you are packaging new stuff and do update your packages before the todo arrives at the end of the month. https://wiki.archlinux.org/index.php/Go_package_guidelines -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Thu, May 14, 2020 at 09:39:58AM +0200, Levente Polyak via arch-dev-public wrote: > > At the end of the month I'll make a todo with the remaining packages > > depending > > on `go-pie`. > > > > The complete future Go PKGBUILD is attached to this email below. > > > PS: shouldn't we look into Go getting those flags as well? The Go > compiler itself doesn't have RELRO and fortified sources :) Because everything, sadly, breaks. I'd much rather try look into reproducibility before actually caring about binary hardening. If we PIE compile the test suite upstream fails quite badly. Evidently upstream doesn't test the go compiler with PIE/RELRO enabled. Unsure if they care at all even. If we also try define `CGO_CFLAGS` we end up with errors like: /usr/include/features.h:397:4: error: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp] `-buildmode=pie` is also going to land you in trouble with the race detection in their test suite. So not quite there yet for the compiler itself. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Wed, May 13, 2020 at 04:35:11PM -0400, Eli Schwartz via arch-dev-public wrote: > On 5/13/20 4:16 PM, Morten Linderud via arch-dev-public wrote: > > The complete future Go PKGBUILD is attached to this email below. > > > ``` > replaces=(go-pie) > provides=(go-pie) > ``` > > Should this provide it too? Anything that explicitly expected go-pie > cannot assume the new package is a drop-in replacement, it will need > changes for the flags and can, at the same time, swap out the > requirement for go-pie. > > Yes, this would mean any PKGBUILD which makedepends on it needs to be > updated immediately or fail to rebuild. `go-pie` never provided PIE nor Full RELRO without the appropriate flags. Nothing is really lost by simply replacing and providing it. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
Yo!
After another few lazy weeks I have finished up the new Go packaging guidelines.
https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines#Flags_and_build_options
The changes that has been done since last time is some structing of the page,
added a list explaining all the flags that have been added to `GOFLAGS`, and the
addition of `-mod=readonly`.
The intention of adding this flag is to prevent Makefiles or build systems to
silently modify the lockfile of the source code after checkout. This is
to ensure reproducible build.
If there are no objections, I'll probably merge the guidelines this weekend
section-by-section to make the wiki admins happy. The new package should land
sometime nextweek.
At the end of the month I'll make a todo with the remaining packages depending
on `go-pie`.
The complete future Go PKGBUILD is attached to this email below.
--
Morten Linderud
PGP: 9C02FF419FECBE16
# Go PKBUILD
pkgname=go
epoch=2
pkgver=1.14.2
pkgrel=2
pkgdesc='Core compiler tools for the Go programming language'
arch=(x86_64)
url='https://golang.org/'
license=(BSD)
makedepends=(git go perl)
replaces=(go-pie)
provides=(go-pie)
options=(!strip staticlibs)
source=(https://storage.googleapis.com/golang/go$pkgver.src.tar.gz{,.asc})
validpgpkeys=('EB4C1BFD4F042F6DDDCCEC917721F63BD38B4796')
sha256sums=('98de84e69726a66da7b4e58eac41b99cbe274d7e8906eeb8a5b7eb0aadee7f7c'
'SKIP')
build() {
export GOARCH=amd64
export GOROOT_FINAL=/usr/lib/go
export GOROOT_BOOTSTRAP=/usr/lib/go
export GOPATH="$srcdir/"
export GOROOT="$srcdir/$pkgname"
export GOBIN="$GOROOT/bin"
cd "$pkgname/src"
./make.bash --no-clean -v
PATH="$GOBIN:$PATH" go install -v -race std
PATH="$GOBIN:$PATH" go install -v -buildmode=shared std
}
check() {
export GOARCH=amd64
export GOROOT_FINAL=/usr/lib/go
export GOROOT_BOOTSTRAP=/usr/lib/go
export GOROOT="$srcdir/$pkgname"
export GOBIN="$GOROOT/bin"
export PATH="$srcdir/$pkgname/bin:$PATH"
export GO_TEST_TIMEOUT_SCALE=2
cd $pkgname/src
./run.bash --no-rebuild -v -v -v -k
}
package() {
cd "$pkgname"
install -d "$pkgdir/usr/bin" "$pkgdir/usr/lib/go" "$pkgdir/usr/share/doc/go"
cp -a bin pkg src lib misc api test "$pkgdir/usr/lib/go"
cp -r doc/* "$pkgdir/usr/share/doc/go"
ln -sf /usr/lib/go/bin/go "$pkgdir/usr/bin/go"
ln -sf /usr/lib/go/bin/gofmt "$pkgdir/usr/bin/gofmt"
ln -sf /usr/share/doc/go "$pkgdir/usr/lib/go/doc"
install -Dm644 VERSION "$pkgdir/usr/lib/go/VERSION"
rm -rf "$pkgdir/usr/lib/go/pkg/bootstrap" "$pkgdir/usr/lib/go/pkg/tool/*/api"
# TODO: Figure out if really needed
rm -rf "$pkgdir"/usr/lib/go/pkg/obj/go-build/*
install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}
signature.asc
Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Thu, Apr 30, 2020 at 04:58:01PM -0400, Eli Schwartz via arch-dev-public wrote: > Why does it matter to makepkg how the go compiler downloads source code, > or using which options? Any download that is done outside the source=() > array is violating the PKGBUILD contract, and is not cached in $SRCDEST. > It is therefore not persisted between successive clean chroot builds > since those use a temporary $HOME and $BUILDDIR which is deleted between > uses. And regardless of any other factors, it will not be able to work > if the makepkg tool is executed in an environment where the network has > been disabled. Sure, any code downloaded outside of source violates the farily vague PKGBUILD contract. However, if TU candidate starts using `patch` or `git submodule` in either `build` or `check` you are going to raise an eyebrow. And you are most likely going to say they need to go into `prepare`. Source code modification doesn't belong in pkgver, build, nor check, nor package. So why is Go, and it's silly compiler, an exception? > So, we don't get caching and we don't get offline builds. That's beyond > question. One ecosystem gets closer to the goal. That is good enough, isn't it? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Thu, Apr 30, 2020 at 12:56:30AM -0700, Anatol Pomozov via arch-dev-public wrote: > And if we plan to encourage adding the cache warmup to all golang > PKGBUILD (that's gonna be thousands of packages) then this extra > complexity need be justified. Anyone who wants to follow our advise > needs to have clear answers to following questions: Is this feature > solely to avoid the download during the build() step or there is > something else? Why downloading in build() is bad, does it hurt the > users? What use-cases does show an advantage of the cache warmup.. > etc.. There are something like 140 packages using go today in our repositories today, there is no need for some grand justification. The justification, if anything is needed, is this RFC alone and the fact we should strive to follow the packaging guidelines when applicable. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Reproducible builds progress report #2 and package rebuilders
Yo! Most should be familiar with the reproducible builds efforts going on in Arch Linux. The goal is to figure out how to make our packages reproducible, which can let users verify that our packages are a product of the PKGBUILD we upload and the source we claim it uses [1]. Last status update was in November [2]! Allan wrote about our attempts at manually reproducing core packages to find mistakes in them. This went fairly well and we managed to reproduce a great deal of packages [3]. The progress since then has been great. Jelle went to Marrakesh for the annual Reproducible Builds summit [4]. Improvements to the tooling have also been made. Most notably kpcyrd has written rebuilderd which was announced on the reproducible builds mailing list last week [5]. rebuilderd aims to be a general package rebuilder, supporting multiple distros with Arch being the first supported one. Rebuilderd allows anyone to easily create package rebuilders to reproduce distributed packages [6]. It currently utilizes `repro` for the reproduction itself [7]. As of writing this we have managed to reproduce 86%-90% of the `[core]` repository across 2-3 rebuilders! One of the rebuilders currently running is our own rebuilder [8]! The current setup runs with 3 worker boxes: * repro1.pkgbuild.com - Arch * repro2.pkgbuild.com - Arch * repro3.pkgbuild.com - Debian 10 One can also find a list of rebuilders currently running on the wiki [9]. A usecase for these rebuilders is to check the packages on your system is currently verified with one or more rebuilders. kpcyrd wrote ismyarchverifiedyet to check this [10]. It should be noted that everything is very much a work in progress. Just because a package is listed as bad doesn't mean it's unreproducible. It might be tooling bugs or other issues. However, if you want to take a look at it you can do so with `repro`, or `makerepropkg` in devtools[11]. Cheers from the Reproducible Builds Team! Sources: [1]: https://reproducible-builds.org/ [2]: https://lists.archlinux.org/pipermail/arch-dev-public/2019-November/029721.html [3]: https://wiki.archlinux.org/index.php/DeveloperWiki:ReproduciblePackages [4]: https://reproducible-builds.org/events/Marrakesh2019/ [5]: https://lists.reproducible-builds.org/pipermail/rb-general/2020-April/001905.html [6]: https://github.com/kpcyrd/rebuilderd [7]: https://github.com/archlinux/archlinux-repro [8]: https://reproducible.archlinux.org/ [9]: https://wiki.archlinux.org/index.php/Package_rebuilders [10]: https://github.com/kpcyrd/ismyarchverifiedyet [11]: https://git.archlinux.org/devtools.git/tree/makerepropkg.in -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Mon, Apr 20, 2020 at 09:05:27AM +0300, Christoph Gysin wrote:
> On Mon, Apr 20, 2020 at 1:32 AM Morten Linderud via arch-dev-public <
> arch-dev-public@archlinux.org> wrote:
>
> > https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines
> >
>
> In the fist example, you set both:
>
> CGO_LDFLAGS=$LDFLAGS
>
> and pass:
>
> -ldflags "-extldflags ${LDFLAGS}"
>
> Yet in the example PKGBUILD, only the former?
If you read the example:
# *or alternatively* you can define some of these flags from the CLI options"
> Also, maybe it would be nice to have an example how to add additional
> ldflags correctly without overwriting LDFLAGS, e.g. passing:
>
> -ldflags "-X my.package.Version=$pkgver"
The goal of the page is not to teach you how the go compiler works, but I'll
consider it.
Thanks
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
Yo! After being lazy for a few weeks, I got around to writing the new guidelines for Go packages. Currently it's a draft and I'd love if people read through it and ack/nacked https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines The current changes is dropping anything pre-1.11 completely. I don't see the need to detail the GOPATH hacks as new packages should be using go modules, and existing packages is moving to go modules. The other changes is explicitly listing up the needed CGO_* variables needed. Levente pointed out CGO_CFLAGS is still needed for FORTIFY_SOURCE, so for the sake of completeness it's all listed. 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. If anything is confusing or missing, do tell. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Discussion - Increasing our CPU requirements
On Sun, Mar 29, 2020 at 03:39:51PM +0100, Filipe Laíns via arch-dev-public wrote: > > To have a separate architecture would require automated builds, which > > requires being able to sign packages automatically. And we have not > > achieved database signing in 9 years I'm looking for a boost that > > could be achieved now. > > No, it would not. Where is this coming from? I already build split > packages with SIMD instructions, I make the PKGBUILD build for 2 > architectures instead with a minimal patch. > > If pacman is not able to handle parallel architectures, we should fix > that. I think it's a valid use case. Well, how do you think we supported two architectures? Why do you think `extra-x86_64-build` is named the way it is? The "problem" is that we have no intentions of building 1 package 4 times and keep things in sync by hand, it was tedious enough with i686, which was part of why it was dropped in the first place. Thus we want build-servers to do this for us. Allan is going to have a hard time argueing that the minimal improvements is going to justify the absurd time we'll end up building things by hand, it's the crux of the problem essentially. I'm also sure he knows this. Surely we can bikeshed about which architectures to support, what we should discuss is how we should accomplish the task in general. > Furthermore, if you do indeed whish to move this forward please present > us with reasonable data. Take a few packages that would benefit from > this, build them with the proposed architecture and show us benchmarks. > I think it's gonna be very hard for you to find packages with > considerable improvement but I might be wrong, please show me. See last paragraph. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Sun, Mar 15, 2020 at 01:09:19PM -0700, Anatol Pomozov via arch-dev-public
wrote:
> Hello
>
> On Sun, Mar 15, 2020 at 12:24 PM Morten Linderud via arch-dev-public
> wrote:
> >
> > On Sun, Mar 15, 2020 at 12:09:07PM -0700, Anatol Pomozov via
> > arch-dev-public wrote:
> > > > Notice that `-mod=vendor` is also added to `GOFLAGS`.
> > >
> > > Most of the Go projects do not vendorize their dependencies to avoid
> > > polluting the source tree.
> > >
> > > And there is no point to force vendorizing in the PKGBUILD neither. go
> > > modules are doing a great job with pinning dependencies to a specific
> > > version thus eliminating the main reason for vendor'ization existence
> > > (i.e. reproducible builds).
> > >
> > > Thus following YAGNI principle I propose to drop this "-mod=vendor" flag.
> >
> > `-mod=vendor` is implicit as of go 1.14.
>
> -mod=vendor is neither implicit nor required. -mod=vendor flag is
> enabled by default only if upstream project uses vendorized project
> structure so the build scripts do not have to add this flag manually.
I fail to see how this isn't implicit if it's enabled on the fly. This behaviour
has changed before and we really want to ensure we not downloading dependencies
during building.
We can discuss the merits of replacing `go mod vendor` with `go mod download`
and thus drop the vendor flag. However this requires packagers to realize they
don't need `prepare()` if vendor is present in the release tarballs/upstreams.
But I'd rather have this as streamlined as possible across upstreams and having
packagers think about less implicit behaviour from go.
> The decisions whether to use a vendor directory structure or not
> should be up to upstream developers.
Strictly speaking, but this is offtopic, this is up to downstream. And no, we
shouldn't be using vendored dependencies. But this is another discussion and a
issue at large in several ecosystems.
> > We need to fetch the dependencies before over the wire before build() and
> > check().
>
> go modules will fetch the dependencies using the information from
> go.sum. I have go packages with dependencies, and following build()
>
> build() {
> cd $dir
> go build
> }
>
> works great, including chroot environment.
I'm aware that go {list,build,test} fetches dependencies on the fly.
And let me reiterate again; *This shouldn't happen*.
We should be capable of performing complete software builds without internet
connection. If we can't have the sources downloaded in the source array, they
need to be fetched in prepare.
This is why I'm also bringing up the prepare function in the first place.
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
On Sun, Mar 15, 2020 at 12:09:07PM -0700, Anatol Pomozov via arch-dev-public wrote: > > Notice that `-mod=vendor` is also added to `GOFLAGS`. > > Most of the Go projects do not vendorize their dependencies to avoid > polluting the source tree. > > And there is no point to force vendorizing in the PKGBUILD neither. go > modules are doing a great job with pinning dependencies to a specific > version thus eliminating the main reason for vendor'ization existence > (i.e. reproducible builds). > > Thus following YAGNI principle I propose to drop this "-mod=vendor" flag. `-mod=vendor` is implicit as of go 1.14. We are forcing this to ensure we are not running into new implicit behaviour in the future, such as updating pinned versions or what not. They have changed this once before already. What upstream thinks in terms of polluting the source tree is irrelevant in this case. We need to fetch the dependencies before over the wire before build() and check(). -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] RFC: go-pie removal in favour of GOFLAGS
# Introduction
To enable PIE compilation, we have relied on a patched version of the go
compiler which has been distributed as `go-pie` since around 2017. However, full
RELRO support for go binaries has been a bit back and forth the past years. With
some thing working, and other things don't.
With the release of Go 1.11 there was support for a general `GOFLAGS` variable
that lets us pass flags directly to the compiler. This email details what these
flags should be going forward.
# Flags
Expected environment variables in PKGBUILDs:
export CGO_LDFLAGS="$LDFLAGS"
export GOFLAGS="-buildmode=pie -trimpath -mod=vendor -modcacherw"
Explanation:
* `CGO_LDFLAGS` passes the proper `LDFLAGS` to the linker. This should enable
full RELRO when used in conjunction with `GOFLAGS`.
* `-buildmode=pie` is the proper way to enable PIE and replaces the `go-pie`
patch.
* `-trimpath` this is to achieve reproducible builds and remove PWD from the
binary.
* `-modcacherw` modules are downloaded to `$GOPATH/pkg/mod` and by default have
the permissions 444 for god knows why. If we want to run `makepkg -c` or `git
clean` we won't have the correct permissions. This is probably not a big
problem for repository packages, but it's a nice addition so they work as
expected.
Notice that `-mod=vendor` is also added to `GOFLAGS`. This will make sure we are
using the vendored dependencies in the project. If they are not present, please
ensure they are downloaded in the `prepare` function:
prepare(){
cd $pkgname-$pkgver
go mod vendor
}
If the project is *not* using Go 1.11 modules, missing `go.mod` and/or `go.sum`
in the project root, then disable it with `export GO111MODULE=off` and continue
with symlink hacks.
Some upstreams override these values for strange reasons in their `Makefile` and
build systems. You *need* to read over them and ensure this does not happen!
# Pacman
Clearly we shouldn't have to specify this in every PKGBUILD, so I have been
playing with a `pacman` patch that passes all of the variables. However I have
been struggling with debug support and figuring out that part of the flags, so
nothing have been upstreamed yet.
However this is only applicable to around 126 packages, so I guess it's fine?
¯\_(ツ)_/¯
# In conclusion...
If there are no objections to the New Way Of Doing Things™, I'll be updating the
package guidelines within the next week or two and drop the `go-pie` package
containing the patch. For the sake of compatibility, the `go` package will
contain a
`replaces=('go-pie')`. I also expect people packaging go packages to follow the
guidelines!
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-dev-public] FOSDEM Dinner 2020
On Mon, Jan 06, 2020 at 03:41:29PM +0100, Morten Linderud wrote: > To make it managable I'll cap the attendees to around 15 people. Priority for > members of the Arch team (developers, trusted users and support staff). Any > free > spots after this can be taken by anyone interested :). Send an email *offlist* > so I have some ability to keep track and inform you about further booking > details. > > The users requesting spots will get a headsup the week before FOSDEM to give > all > staff a chance to reply. Please ask me if you have any questions :) Currently we have 10 staff and 2 users on the waiting list. The booking has been set to 20:30 on Saturday 1st of February. Please email me if you want to join, the invitations are being sent out this Saturday :) Please don't hesitate to poke me if you have questions! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] [arch-events] FOSDEM Dinner 2020
On Mon, Jan 06, 2020 at 08:24:36PM +, Filipe Laíns wrote: > On Mon, 2020-01-06 at 15:41 +0100, Morten Linderud via arch-events wrote: > > Yo! > > > > Last year at FOSDEM we held a dinner with 15 people, some members from the > > Arch > > team and some users that wanted to join. It was a great event and people > > had a > > nice dinner with some nice chats afterwards on various pubs. > > > > For this year I plan to do the same with some changes. First of all, we are > > going to be holding it on saturday around 18:00 - 19:00 as opposed to > > friday. > ^ > > Is this a typo? Isn't that too early? There will be talks until 19:00. > In fact, I will be giving a talk from 18:30 to 18:55. Right! Probably a tad later then :) Nothing has been booked so I'll just move it an hour or something. Not going to force you to pick between our awesomesauce Arch dinner and your talk, even though I know you'd obviously pick the dinner! The pros and cons of copypasting emails from earlier events :D -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] FOSDEM Dinner 2020
Yo! Last year at FOSDEM we held a dinner with 15 people, some members from the Arch team and some users that wanted to join. It was a great event and people had a nice dinner with some nice chats afterwards on various pubs. For this year I plan to do the same with some changes. First of all, we are going to be holding it on saturday around 18:00 - 19:00 as opposed to friday. This is to ensure people are able to arrive friday evening, AND keep their phones after their dinner. I'm still looking for mine :/ To make it managable I'll cap the attendees to around 15 people. Priority for members of the Arch team (developers, trusted users and support staff). Any free spots after this can be taken by anyone interested :). Send an email *offlist* so I have some ability to keep track and inform you about further booking details. The users requesting spots will get a headsup the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions :) --- I have again CC'ed arch-dev-public since I don't actually know how many people watch arch-events (hinthint subscribe!). Sorry for the noise, and please do tell me if we are better off not cross-posting emails like these :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Restricting ability to post news items
On Sun, Jan 05, 2020 at 11:10:17PM +0100, Bartłomiej Piotrowski via arch-dev-public wrote: > 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. You are writing about non-trivial news items, but Allan is writing explicitly about *all* news items. There is a disconnect here, I'm not sure what has been decided. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Restricting ability to post news items
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? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Missing bugtracker assignment emails
Yo! Andreas Radke has done an impressive amount of bug assignments the past week. But it looks like the assignment emails themselves are not sent correctly and you might not have noticed this. Please look over your bug assignments on the tracker in case you haven't taken a look in a while :) Happy holidays! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Reproducible builds progress and the upcoming rebuild of [core]
Yo! Lets keep the momentum up by sharing more great news :) So all packages in core have now been rebuilt and tested with archlinux-repro. You can find the list at: https://wiki.archlinux.org/index.php/DeveloperWiki:ReproduciblePackages So while most packages are reproducible, 20 packages are not reproducible, and 3(!) packages could not be built. - popt uses the deprecated rpm5.org address - pkgconf has moved to sourcehut (https://git.sr.ht/~kaniini/pkgconf) - iana-etc the sources are not validating Meanwhile we should try to figure out some solutions for rest of the non-reproducible ones so we can have a 100% reproducible core repository. The diffoscope output for all of the 14 packages can be found on my homedir: https://pkgbuild.com/~foxboron/diffoscope-output-non-reproducible/ Currently havent tried rebuilding linux-lts because of lazyness, but the result should be the same as for the linux package. I have also packaged up `archlinux-repro` into community, and Eli has submitted the patches for the `makerepropkg` tool! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Reproducible builds progress and the upcoming rebuild of [core]
On Wed, Nov 13, 2019 at 12:46:03PM +1000, Allan McRae via arch-dev-public wrote: > One by Morton (Foxboron) [2] This is funny because it was the nick of my first WoW character :D But! I have uploaded `archlinux-repro` to community so people can check it out and test the functionality. Obviously going to be some rough edges and some usability issues, so issues and patches are very much welcome :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Using SPDX License list as identifiers
On Tue, Oct 22, 2019 at 09:15:17PM +0200, Morten Linderud via arch-dev-public
wrote:
> Dropping these files into `/usr/share/licenses/common` seems like the easiest
> solution. But our current structure is
> `/usr/share/licenses/$LicenseName/license.txt`,
> with a few exceptions such as CCPL. Is there any reason for this structure?
I have added a suggested PKGBUILD for the SPDX license package with the
assumption that we don't want the current structure. I'd really appreciate some
input as to why we have the current structure.
# Maintainer: Levente Polyak
# Maintainer: Dan McGee
# Contributor: Morten Linderud
pkgname=licenses
pkgver=20191028
_spdx_version=3.7
pkgrel=1
pkgdesc='Standard licenses distribution package, based of SPDX'
arch=('any')
license=('CC0-1.0')
url='https://spdx.org/licenses/'
source=("$pkgname-$pkgver.tar.gz::https://github.com/spdx/license-list-data/archive/v${_spdx_version}.tar.gz;)
sha256sums=('3f3a121ad331261d0997b3c6526d0db030d8b1468afce862921eaea22099f909')
package() {
cd "license-list-data-$_spdx_version/text"
rm deprecated_*
install -dm644 "$pkgdir/usr/share/licenses/common"
mv * "$pkgdir/usr/share/licenses/common"
}
--
Morten Linderud
PGP: 9C02FF419FECBE16
signature.asc
Description: PGP signature
Re: [arch-dev-public] Using SPDX License list as identifiers
On Tue, Oct 22, 2019 at 01:59:48PM +0200, Jerome Leclanche wrote: > Hi > > This just came up on IRC. Thoughts on using the SPDX license list as valid > license identifiers for all packages? > https://spdx.org/licenses/ I like this idea. I started looking into how this would be packaged. The main repository is simply just structured data SPDX, which are processed into different formats. One of them are just plain text files with the license text [1]. Dropping these files into `/usr/share/licenses/common` seems like the easiest solution. But our current structure is `/usr/share/licenses/$LicenseName/license.txt`, with a few exceptions such as CCPL. Is there any reason for this structure? If we want the current structure, it feels like the easiest solution is to take the list and massage it into folders. This can probably be done with SPDX tooling, and I'll gladly take a look at how that can be done. [1]: https://github.com/spdx/license-list-data/tree/master/text -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] A contrib repository
On Wed, Mar 27, 2019 at 11:14:17PM +0100, Morten Linderud via arch-dev-public wrote: > Going to try figure out the packaging bit through the weekend. And one long weekend later and we have "archlinux-contrib" in [community]! There are currently a few scripts available. - checkservices Originally writen by seblu, and commited to contrib by Giancarlo, it checks which services needs to be restarted after packages have been updated. - co-maintainers It queries archweb and helps you figure out which of your packages has how many co-maintainers. It's useful in the case where you are going on vacation and want to produce a list of packages which currently only has you as the maintainer. - review Helps you download PKGBUILDs from an AUR maintainer. This is useful if you want to review TU candidates. - compose-asa Aids security team members composing the advisory email locally. - security-tracker-check Checks stdin for CVEs and cross-checks with our security tracker if they have been added or not. Useful if you are looking over oss-security emails :) svenstaro also wrote a `offline-build` tool that went into contrib. Eli polished it and moved it to devtools after some work. Jelle also has a pull-request working on "repo-sec-checker" checks if there are binaries in a package/repo which does not have the appropriate security hardening applied. It should be noted that all of this is currently being packaged to `/usr/share/archlinux/contrib` as it seems like an better idea to not clutter peoples paths with misc tools. I'll be super happy if people contribute other misc scripts, and everyone that wishes will be added to the github org and can handle pull-requests. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] A contrib repository
Yo! A followup mail that the contrib repository has been created :) It currently located at https://github.com/archlinux/contrib and all scripts welcome! Currently there is a few scripts there currently! `co-maintainers` helps you find packages in repositories that has N maintainers. Super handy if you need to figure out if any packages you have installed is missing a co-maintainer or two. There is also a quick script to help fetch PKGBUILDs from AUR users for review and Sven has uploaded a quick script to build a package on dragon. Going to try figure out the packaging bit through the weekend. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
On Sun, Mar 24, 2019 at 04:39:54PM -0700, Andrew Gregory via arch-dev-public wrote: > I don't consider hoping that libarchive doesn't need a rebuild in the > near future a great strategy. That being said, this is really > a question of how long of a period we need between libarchive v3.3.3 > and us making the switch. I'm not a packager, so I don't have much of > an opinion on that. Well, we pride ourselves with having competent users. I think waiting a year is conservative and safe. However, personally I think we can wait for the next pacman release and write an announcment. Then we give everyone a month to update and we can have a smooth transition. Assuming of course that everyone is on-board with this change. I would like to get some opinions from packaging devs with experiences. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] RFC: (devtools) Changing default compression method to zstd
On Sun, Mar 24, 2019 at 04:22:55PM -0700, Andrew Gregory via arch-dev-public wrote: > On 03/25/19 at 12:15am, Robin Broda via arch-dev-public wrote: > > Thus i don't think we need a hold-off period like this, Allan. > > We still need a hold-off period, we're just waiting to make sure > people have libarchive v3.3.3 instead of pacman v5.2.0. libarchive was released around 7th of September into the repos, so that is at least a shorter timeframe when waiting next pacman release + a full year. Wouldn't it be feasible to issue an Announcement early July and do the transition in September? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] A contrib repository
On Thu, Mar 21, 2019 at 06:58:56PM -0400, Santiago Torres-Arias via arch-dev-public wrote: > Morten, why don't you start a repository on GitHub and we start figuring > things out while things move. Moving github repos between organization and user is a hassle, so would prefer if a dev could create a repo and provide access on github at least. > I'm also more than happy helping with maintenance work, although I don't > think I have enough time for being the only maintainer of this. Yasss! +1 -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Co-maintainers and less time for packaging
Yo! As some might be aware, I'm finishing up a master thesis that is due 1st of June. Because of this my time is going to be limited closer to the delivery date. To try relieve some stress I'm giving a heads up that the time spent on packaging is going to be strained going forward. Since we have been trying to focus on co-maintainers for each package, I have collected a list of packages where I am the sole maintainer. Feel free to adopt any package on the list :) I can probably share nvchecker setup for most of them. acpid bucklespring containerd delve dep git-lfs go-md2man gopass hexedit hy i3-gaps influxdb jgmenu jp2a minicom mopidy mypy neofetch font-awesome pass-otp pdfjs protege python-argparse python-autobahn python-babel python2-docs python2-functools32 python-hidapi python-jsonrpclib-pelix python-keyutils python-ldap python-m2crypto python-nltk python-pew python-pipenv python-psycopg2 python-pyaes python-pydocstyle python-pyserial python-send2trash python-shutilwhich python-sqlobject python-sqlparse python-xlib python-argparse python-autobahn python-babel python-docs python-hidapi python-jsonrpclib-pelix python-keyutils python-ldap python-m2crypto python-mypy_extensions python-nltk python-pew python-pipenv python-psycopg2 python-pyaes python-pydocstyle python-pypeg2 python-pyserial python-pywal python-send2trash python-shutilwhich python-sqlobject python-sqlparse python-typed-ast python-xlib restic udiskie qutebrowser might need an extra hand as well :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] A contrib repository
On Wed, Mar 13, 2019 at 02:05:47PM -1000, Gaetan Bisson via arch-dev-public wrote: > I think it's a great idea but it needs a solid maintainer. Without a > clear leader it's (probably) going to be a free for all and we'll drown > under bikeshedding issues within a month. But of course that doesn't > mean we'd lose anything trying anyhow. > > Among other things, I'd personally like to see the repo maintainer > enforce sensible and consistent naming for the tools, preferring longer, > explicit names over shorter ones. For instance, I'm sure many of us have > one-letter scripts and if we contribute them all there's bound to be > collisions along with the problem of not knowing at first glance what > each tool does. We could maintain a bash alias file containing > everyone's favorite nickname for each tool. If we want someone to a dedicated maintainer, I can probably do so. But I believe that we can give everyone commit access, block commits to master and just enforce a system where two reviews are needed before merge. I really don't think more is needed, but as noted; I can probably take some responsibilities if the devs think that is warranted. When it comes to packaging and naming conflicts, I wonder if it's just easier to drop all the supplied files into `/usr/share/archcontrib` or something. Makes it easier to package and doesn't clutter anyone's PATH with a lot of (sometimes) unneeded tools. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] A contrib repository
On Thu, Mar 14, 2019 at 09:14:22AM +0100, Christian Hesse wrote: > Morten Linderud via arch-dev-public on Thu, > 2019/03/14 01:02: > > This is why we have talked about adding gitolite to host these repositories > > I've wanted to propose this a long time ago... > > In fact you can give every user full access to it own area in every > repository, while important branches are still protected. I have several git > servers that use something like this: > > repo devtools > RW+ = admin > RW+ personal/USER/ general/ = @all > RW master$ develop$ refs/tags/ = @devtools > R = @all > > -> admin can do everything > -> random user 'foo' can do everything in personal/foo/ and general/ > -> random user 'bar' can do everything in personal/bar/ and general/ > -> members of group 'devtools' can push to master and develop and push tags, >but forced push is denied > -> random (authenticated) user can read everything Yep! Here is the proposed patch set compared to an outdated master branch: https://github.com/Foxboron/infrastructure/compare/foxboron/git It was put on hold as there is a cgit vs gitlab dicussion in relation to the svn->git migration. But lets not derail the `contrib` repo discussion :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] A contrib repository
On Thu, Mar 14, 2019 at 09:46:32AM +1000, Allan McRae wrote: > I was fairly sure any user can create a git repo on our server. Look at > "Developer Projects" on https://git.archlinux.org/ . No. Luna isn't setup with the archuser role and all git operations like creating repositories are done by hand. If you have access, I assume you can create repositories under the `/users` directory at will. This is why we have talked about adding gitolite to host these repositories, but that have been somewhat stalled along with the svn->git migration talks along with me not finishing up the role completely :x >Or use github, where some of these scripts are already located. I'm a bit unsure what you are trying to say. Do you want the authors to just publicize it themselves as separate git repositories? On personal accounts or the Arch Linux organization? -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] A contrib repository
There is a *lot* of small tools people have written over the years that resides in bin/ directories which could be useful for more people. We also have several such tools on soyuz, where sogrep was added to devtools this week. I have been thinking it could be great to have a simple `contrib` repository where every team member has commit access. This could work as a staging area for tools we would like to promote to `devtools` later on. We could maybe sort this into directories for its purpose: * packaging * security * devops * testing * bugwrangler * misc Tools that can be added here is the `ch` scripts from Bluewind, and the pkg-* tools eli has created. I also have some tools to look for pkgname in archweb, check them out from svn and check them against a nvchecker file. This would hopefully give us a space where we can experiment with new maintainer tools in a collaborative manner. I'd love to hear some feedback or thoughs on this! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Improving overall experience for contributors follow up
On Wed, Feb 06, 2019 at 04:26:03PM -0500, Eli Schwartz via arch-dev-public wrote: > > I'm quite sure others others have such projects on their mind which > > are not publicly findable yet. (sogrep to devtools for example) > > sogrep as it currently exists on the soyuz build server depends on > private paths to /srv/ftp > > I've reimplemented it here, FWIW: > https://github.com/eli-schwartz/dotfiles/blob/master/bin/sogrep > > To go with: > https://github.com/eli-schwartz/dotfiles/blob/master/bin/pkg-list-linked-libraries > > Problem is I'm not sure either one strictly belongs in devtools. Been meaning to write a proposal about getting a `contrib` repository that would be staging grounds for new devtools additions, or just nice to have in general. I believe such tools would fit in such a project and help us organize tools loosly related to TU/Dev duties that are currently hard to share or find. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] FOSDEM 2019
Yo! The dinner is a week away and we are currently 11 people signed up. We have booked a table for 15 people and would love to fill the 4 remaining seats :D Feel free to email me if there is any questions! -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Proposal: minimal base system
On Mon, Jan 21, 2019 at 06:58:54PM -0500, Eli Schwartz via arch-dev-public wrote: > The most recent version of my PKGBUILD draft for this "base-system" > PKGBUILD (which I shared with Levente during the planning stages of this > proposal) can be found here: https://paste.xinu.at/KZmYqQwIO/ FYI that package is a bit outdated as we removed `diffutils` and `inetutils`. Along with not considering interactive packages while partially rewriting the list today. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Mongodb and SSPL
Someone sent me an off-list reply. I have forwarded it as it provides some additional information. - Forwarded message from Alexander Shpilkin - Date: Thu, 17 Jan 2019 17:09:54 +0300 From: Alexander Shpilkin To: Morten Linderud Subject: Re: [arch-dev-public] Mongodb and SSPL User-Agent: alot/0.7 [I originally wrote this as a message to the list without realizing I can’t post there; feel free to send it wherever.] TL;DR: There’s enough FUD in the SSPL to make it unclear whether Mongo can, in fact, be distributed or not. Quoting Morten Linderud (2019-01-16 15:02:55) > As probably some of you have realized, there is a discussion regarding > mongodb and the relicense from AGPLv3 to SSPLv1. [...] > > Obviously, we don't care about the license being free nor OSI > compliant. We only care if we are allowed to redistribute or not. > > [...] > > There is nothing in the SSPLv1 license text that prohibits us from > distributing mongodb. I feel I should point out here that there’s uncertainty on part of both [debian-legal participants][1] and [Debian FTP masters][2] as to whether the distribution of binaries falls under the service restrictions. If it does, this would mean all software on the mirrors would need to be SSPL-compatible (in particular, non-GPL), which _would_ prohibit us. The SSPL authors [were asked][3] for their stance on this question, but do not appear to have answered. I think this is troubling in itself. > There are however special requirements in the license we have to abide > if we want to distribute modified source code. > > Currently the PKGBUILD does a few sed's in the source to build it. [...] Note that the service restrictions (which are different from distribution restrictions) are applicable to both modified and unmodified versions; in fact, the original authors [declare][4] this to be among the design goals of the SSPL. [1]: https://lists.debian.org/debian-legal/2018/10/msg8.html [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537#50 [3]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003654.html [4]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-October/003603.html -- Alex Shpilkin - End forwarded message - -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Mongodb and SSPL
Yo! As probably some of you have realized, there is a discussion regarding mongodb and the relicense from AGPLv3 to SSPLv1. RedHat has dropped it from their repository[1], and Debian is assumed to follow suit[2]. This is mostly due SSPL not being considered a free-license. It is currently being reviewed by OSI for inclusion, but it is not looking bright currently[3]. The OSI discussion is for SSPLv2, but it's my understanding that they are essentially the same license with some fixups. Obviously, we don't care about the license being free nor OSI compliant. We only care if we are allowed to redistribute or not. Link to the current license text as of mongodb release 4.0.5: https://github.com/mongodb/mongo/blob/r4.0.5/LICENSE-Community.txt There is nothing in the SSPLv1 license text that prohibits us from distributing mongodb. There are however special requirements in the license we have to abide if we want to distribute modified source code. Currently the PKGBUILD does a few sed's in the source to build it. I believe this constitutes as modified source code under "0. Definitions". To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work. Under section "5. Conveying Modified Source Versions" the most relevant part for us is section "a)". a) The work must carry prominent notices stating that you modified it, and giving a relevant date. Which means we need to give some heads-up that the source is changed. The next section is "6. Conveying Non-Source Forms" where I am unsure what applies to us. One way to distribute the modified source is required, where 5 possible options are listed. I think "d)" fits us, where we can host a source package on `source.archlinux.org`. But I'm frankly a bit unsure what the entire paragraph entails for us. Some more input on this section would be great. The bugreport FS#61394 is already submitted requesting a license change from AGPLv3 to SSPLv1, so we should probably figure this out before changing the license appropriately[5]? -- Morten Linderud PGP: 9C02FF419FECBE16 [1]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html/8.0_beta_release_notes/new-features#web_servers_databases_dynamic_languages_2 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537#15 [3]: https://opensource.org/LicenseReview122018 [4]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/mongodb#n46 [5]: https://bugs.archlinux.org/task/61394 signature.asc Description: PGP signature
Re: [arch-dev-public] /r/linux AMA
AMA is live :) No need to rush replies, and feel free to answer questions multiple times :D https://www.reddit.com/r/linux/comments/9emwtu/arch_linux_ama/ -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Improving the package guidelines
Helluw! The rewrites have been up for a few months now and I intend to merge them soon. Feel free to still review them, either with a reply on the ML or on IRC. Whatever you prefer :) Alex Branham has also written up a page detailing some R package guidelines; https://wiki.archlinux.org/index.php/R_package_guidelines. I still have some hopes that other TUs and Devs could help fix up missing information in the guidelines. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] /r/linux AMA
I have set the tentative date to 10th of september, and got an ACK from the subreddit moderator. As noted the AMA will last a few days so there is no need to be available Monday to participate. Please write the mail as noted in the first mail if you want to join. I'll write a introduction post and aquire flairs for the participants the week before. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] /r/linux AMA
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 :) -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
[arch-dev-public] Improving the package guidelines
Yo! In April there was some discussion regarding how to properly do unit testing in Python PKGBUILDs[1]. Felix had some amazing notes that was super useful. But as pointed out we don't really strive to document these things[2]. To try help and spark some interest in improving the current package guidelines, I have spent a some time restructuring and rewriting parts of the Python and Golang package guidelines. I'd appreciate reviews on them! https://wiki.archlinux.org/index.php/User:Foxboron/Python_packaging_guidelines https://wiki.archlinux.org/index.php/User:Foxboron/Go_packaging_guidelines It really doesn't take that much time to note down what you know about packaging and what the current standards are. I think this helps both fellow maintainers and AUR maintainers in writing better PKGBUILDs and sharing knowledge. If people think editing wikis are annoying, maybe we could setup a github repository with example PKGBUILDs we can work on? [1]: https://lists.archlinux.org/pipermail/arch-dev-public/2018-April/029228.html [2]: https://lists.archlinux.org/pipermail/arch-dev-public/2018-April/029233.html -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Unit tests for python packages
On Wed, Apr 18, 2018 at 11:19:33PM +0800, Felix Yan via arch-dev-public wrote: > For testing with not installed python modules, invoking setup.py > commands are often preferable and addresses both PYTHONPATH and 2to3. > > For nosetests: Use "python setup.py nosetests" instead. > > For pytest: Use "python setup.py pytest" instead. Note that > "python-pytest-runner" needs to be in checkdepends. > > There are additional common hacks if the tests need to invoke an entry > points or requires the versioned distribution object. Either: > > 1) Installing it in a temporary place and hack PYTHONPATH/PATH. > 2) Create a sitecustomize.py and add the build dir to site. (See > python2-faulthandler for an example) > > And finally if above still didn't solve it, you may choose to skip the > problematic part of the tests or use "heavier" workarounds like a venv. > I think we should be better at documenting these things. This is super usefull to know about and not something that is obvious to everyone. I'll work on the package guideline pages for Python and Golang whenever I have some spare energy left and will be sure to include this. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
Re: [arch-dev-public] Windows Subsystem Linux - Arch Linux as official container?
On Mon, Jan 29, 2018 at 10:00:28PM +0100, Christian Rebischke via arch-dev-public wrote: > * Signup in the Microsoft Appstore (we would get a free voucher if we > want to participate) as Organization (we need the ok from one of our > trademark holders for this step) https://docs.microsoft.com/en-us/legal/windows/agreements/app-developer-agreement """You grant Microsoft, its agents, contractors, licensees, marketing partners, and Affiliates the right to use, reproduce, display, publicly perform and publish your entity name, App or portion of your App, In-App Product, and the App Assets for each App, [...] (iii) in any marketing, presentations, demonstrations, trade shows, industry events, and press releases, for the App, In-App Product, Windows, Windows Phone, Xbox hardware and accessories, Xbox Live Services, Xbox.com and other Windows, Windows Phone and/or Xbox-related websites and each of their successor platforms, and/or any other Microsoft websites, products and services related to the Store and/or Apps...""" So how many people would be comfortable with Arch Linux appearing on the screen next time Satya Nadella proclaims "Microsoft loves Open Source"? I won't. > - CentOS and Ubuntu are there too I don't really see how this helps anything. Both companies have mony to deal with issues and getting people to work on the support. We don't. -- Morten Linderud PGP: 9C02FF419FECBE16 signature.asc Description: PGP signature
